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.

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.

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.

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.

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.

 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.

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.

 Deploying Required Components

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

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.

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.

LOCAL PEERING

LPG

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

Route Rules

Create or use an existing route table for these rules.

NAT

NAT

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

INTERNET GATEWAY

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

Subnet

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

Load Balancer

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

Route Rules

Create or use an existing route table for these rules.

 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.

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