X

Best Practices from Oracle Development's A‑Team

Preparing Network Gateways for Private Oracle Analytics Cloud Data Sources

Validated December 18, 2020 with OAC 5.8

Introduction

Oracle Analytics Cloud (OAC) may now be provisioned within a Virtual Cloud network (VCN) on Oracle Cloud Infrastructure (OCI) with a private endpoint IP address.

This post is a step-by-step guide for preparing network gateways for private OAC access to private data sources and DNS servers.

This is one of the post listed in the OAC Private Endpoint Parent Post

Validations

December 18, 2020 with OAC 5.8

Topics

Before You Begin

Determining Gateway Scenarios

Deploying Required Components

Validating Gateway Connectivity

 Before You Begin and Assumptions

All names and addresses used in this post are for examples only. In this post data sources and DNS resolvers are both referred to as resources. Although not required, resources are in separate subnets to demonstrate security and routing rules.

Note: Resource definitions existing outside of OCI are shown in the diagrams and tables as existing in VCN 2.

 

Privileges

User accounts in OCI tenancies granted compartment privileges for managing networking components.

OAC / RDG 

OAC and/or RDG are provisioned. Refer here for provisioning a private OAC. Refer here for provisioning a private RDG.

Note: If RDG is used, it is in the same subnet as OAC. OAC in the examples apply to both OAC and RDG

 

DNS

The steps in this post have set up the necessary DNS components for your scenarios.

Initial State

OAC is provisioned with a private endpoint.

Private Sources

The set of resource and resource definition locations requiring network access.

About Resource Locations

In this post resource locations are the location of a resource's translated IP address. The address may either be the exact location of the resource or the location of a Web Application Firewall or Load Balancer set in front of the resource. Examples locations are on-premise, other-cloud, OCI region etc.

This is important as networking gateways may be required to facilitate traffic to the location.

 

About Resource Definition Locations

A resource definition location is the location of the first DNS resolver that finds a resource's definition and successfully provides the resource's location. Examples locations are on-premise, other-cloud, OCI VCN, etc.

This is important as networking gateways may also be required to facilitate traffic to the resource definition location.

 

About Regions and Realms

OCI is hosted in regions. Regions are localized geographic areas, independent of other regions and can be separated by vast distances—across countries or even continents.

Regions are grouped into realms . Your tenancy exists in a single realm and can directly access all regions that belong to that realm. Currently, OCI has multiple realms. There is one commercial realm and multiple realms for Government Cloud.

This is important as you cannot directly access regions that are not in your realm. Indirect access is described in sections below.

 

 Determining Gateway Scenarios

The set of defined resource locations and resource definition locations determine the scenarios required. You may have one or more of the following scenarios depicted below.

SAME VCN

A gateway is not required for resources existing in the same VCN as OAC.

DYNAMIC ROUTING

A Dynamic Routing Gateway (DRG) provides a path for private traffic between your VCN and networks outside the VCN's region. These includes your on-premise network or other cloud networks connected to OCI via VPN and/or FastConnect private peering. Other VCNs in your tenancy located in different regions may be peered using Remote Peering Connections.

Note: DRGs cannot be used without VPN/FastConnect for traffic between different OCI realms.

 

LOCAL PEERING

A Local Peering Gateway provides a path for private traffic between your VCN and other VCNs in the same region. The VCNs may be in separate tenancies.

NAT

A Network Address Translation (NAT) gateway provides a path for traffic to public resources without exposing OAC to incoming internet connections. The NAT gateway's public IP address becomes the source IP address for the outbound traffic. This gateway is used when a public resource such as a load balancer is positioned in front of a private resource.

Note: A public load balancer is required for a resource existing in a different OCI realm when VPN and/or FastConnect is not available.

 

 

 Deploying Required Components

The following table lists the scenario components that may be deployed with links for reference. 

COMPONENT USE REFERENCE Scenarios
DYNAMIC ROUTING GATEWAY Facilitates VPN, FastConnect, and Remote Peering link DRG
CUSTOMER-PREMISES EQUIPMENT (CPE)  Facilitates site-to-site IPSec VPN link DRG
VIRTUAL CIRCUIT Facilitates FastConnect Private Peering link DRG
REMOTE PEERING CONNECTION Facilitates Inter-Region Peering of your VCNs link DRG
LOCAL PEERING GATEWAY Facilitates Intra-Region Peering of your VCNs link LPG
ROUTE RULE Routes a subnet's traffic out of a VCN link All except SAME VCN
SUBNET Hosts DNS endpoints link NAT
NAT GATEWAY Facilitates traffic to a public fronting resource link NAT
INTERNET GATEWAY Facilitates response from the public fronting resource link NAT
LOAD BALANCER Accepting and routing traffic to the resource link NAT

 

The following tables provide component details for the scenarios with example values.

Ensure to update any route rules created in the DNS post with the proper gateway.

SAME VCN

                      No additional components required.

DYNAMIC ROUTING

DRG

Create or use an existing DRG for the OAC and resource's VCNs. Ensure the DRGs are attached to the respective VCNs.

NAME  ATTACHED VCN
Region1-DRG VCN1
Region2-DRG VCN2

 

DRG Peering Connections

For each DRG, create or use one or more of the following components:

Customer Premises Equipment
Virtual Circuit
Remote Peering Connection

 

Route Rules

Create or use an existing route table for these rules.

ROUTE TABLE VCN DESTINATION CIDR TARGET ATTACHED TO NOTE
VCN1-OAC-RT VCN1 10.20.10.0/23 Region1-DRG VCN1-OAC-SN Query to the resource
VCN2-RESOURCE-RT VCN2 10.10.10.0/23 Region2-DRG VCN2-RESOURCE-SN Query response

 

LOCAL PEERING

LPG

Create or use an existing LPG for the OAC and resource's VCNs.

NAME  VCN
VCN1-LPG VCN1
VCN2-LPG VCN2

 

Route Rules

Create or use an existing route table for these rules.

ROUTE TABLE VCN DESTINATION CIDR TARGET ATTACHED TO NOTE
VCN1-OAC-RT VCN1 10.20.10.0/23 VCN1-LPG VCN1-OAC-SN Query to the resource
VCN2-RESOURCE-RT VCN2 10.10.10.0/23 VCN2-LPG VCN2-RESOURCE-SN Query response

                                   

NAT

NAT

Create or use an existing NAT gateway for the OAC VCN.

NAME  VCN
VCN1-NAT VCN1

 

INTERNET GATEWAY

Create or use an existing internet gateway for the resource's VCN.

NAME  VCN
VCN2-IG VCN2

 

Subnet

Create or use an existing public subnet for the public load balancer.

VCN NAME CIDR ROUTE TABLE SECURITY LIST
VCN2 VCN2-LB-SN 10.20.10.32/27 Default Default

 

Load Balancer

Create or use an existing load balancer to listen and forward traffic to resource

NAME VCN SUBNET PROTOCOL TARGET IP TARGET PORT
VCN2-LB VCN2 VCN2-LB-SN TCP 10.20.10.4 1521

 

Route Rules

Create or use an existing route table for these rules.

ROUTE TABLE VCN DESTINATION CIDR TARGET ATTACHED TO NOTE
VCN1-OAC-RT VCN1 10.20.10.0/23 VCN1-NAT VCN1-OAC-SN Query to the resource
VCN2-LB-RT VCN2 10.10.10.0/23 VCN2-IG VCN2-LB-SN Query response

                                   

 Validating Gateway Connectivity

Validate the gateway scenarios by deploying minimal compute instances to act as resources.

Create or use a linux instance in the OAC subnet for sending TCP traffic and DNS queries over UDP. Create or use an instance in the remote network to receive and respond to the TCP traffic. The existing DNS components deployed previously receive and respond to the UDP traffic. 

Terminate all test instances after validations. 

Required Instances for Validation

A default FQDN for a compute instance has this format: <prefix>.<subnet>.<vcn>.oraclevcn.com. For each scenario to be validated create an instance in the appropriate location. The following table lists the required instances with example FQDNs.

SCENARIO LOCATION FQDN
All OAC subnet n/a
All Resource subnet <prefix>.<resource-subnet>.<resource-vcn>.oraclevcn.com

 

Connect to the OAC Subnet Instance

If your client is not in the OAC VCN use a public bastion instance.

Validating the Scenarios

For each scenario use a networking utility such as nc. It may be installed using yum install nc -y

Use nc to test both DNS and TCP connectivity through the appropriate gateway(s).

nc -v -i 2 <resource FQDN> <resource port e.g. 1521>

The result is below.

Ncat: Version 7.50 ( https://nmap.org/ncat )
Ncat: Connected to <resource-IP>:<resource-port>.
Ncat: Idle timeout expired (2000 ms).

 Summary

This post provided a step-by-step guide for preparing network gateways for private OAC access to private data sources and DNS servers.

For other posts relating to analytics and data integration visit http://www.ateam-oracle.com/dayne-carley

 

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.Captcha