Google Cloud Hybrid Networking Patterns — Part 2

Introduction

In Part 1 of this series, we explored the foundational elements of hybrid networking on Google Cloud. As you expand your cloud infrastructure, managing connectivity across multiple VPC networks, including Shared VPCs, becomes essential. In this blog, we'll dive into advanced configurations, such as DNS forwarding, Private Service Connect (PSC) for Google APIs, and VPC Service Control, to help you ensure seamless communication between your on-premises systems and Google Cloud environment.

Hybrid connectivity to multiple VPC networks (or shared VPC networks)

1. Interconnect and HA-VPN to on-premises

The same principles that apply to Interconnect and HA-VPN for hybrid connectivity to a single VPC (or shared VPC) also apply when connecting multiple VPC networks (or shared VPC networks) to on-premises environments. These foundational concepts were covered in detail in Part 1 of this series.

2. Hybrid DNS option 1 (Cloud DNS forwarding and peering)

Overview

Let’s consider a hybrid DNS use case where on-premises DNS servers are authoritative for on-premises DNS zones, and Cloud DNS is authoritative for Google Cloud zones. DNS queries from Google Cloud to on-premises originate from the IP range 35.199.192.0/19, used consistently across all VPC networks. In an architecture with multiple shared VPC networks, only one shared VPC can forward and receive DNS queries to and from the on-premises environment. In this example, the Prod shared VPC is designated as the network used to send and receive DNS queries between Google Cloud and on-premises.

On-premises DNS

Configure your on-premises DNS servers to be authoritative for on-premises DNS zones. Set up DNS forwarding (for Google Cloud DNS names) targeting the Cloud DNS inbound forwarding IP address, created via the inbound server policy in the Prod shared VPC. This allows the on-premises network to resolve Google Cloud DNS names via the Prod shared VPC.

Prod shared VPC — DNS egress proxy

Advertise the Google DNS egress proxy range 35.199.192.0/19 to the on-premises network via the cloud routers. Outbound DNS requests from Google Cloud to on-premises are sourced from this IP address range.

Prod host project — Cloud DNS

a. Configure an inbound server policy for inbound DNS requests from on-premises.

b. Set up a Cloud DNS forwarding zone (for on-premises DNS names) targeting on-premises DNS resolvers.

c. Configure Prod DNS private zones in the Prod host project and attach the Prod shared VPC and Non-Prod shared VPC to the zone. This allows hosts (on-premises and all service projects) to resolve the Prod DNS names.

Non-Prod host project — Cloud DNS

a. Configure a DNS peering zone for on-premises DNS names targeting the Prod shared VPC as the peer network. This allows Non-Prod resources to resolve on-premises DNS names.

b. Set up Non-Prod DNS private zones in the Non-Prod host project and attach the Non-Prod shared VPC and Prod shared VPC to the zone. This allows hosts (on-premises and all service projects) to resolve the Non-Prod DNS names.

3. Hybrid DNS option 2 (custom DNS forwarding)

In a hybrid environment, DNS resolution can be done either in Google Cloud or on-premises. Let’s consider a use case where on-premises DNS servers are authoritative for on-premises DNS zones, and Cloud DNS is authoritative for Google Cloud zones. This scenario assumes that the organization has a requirement to deploy custom DNS servers in Google Cloud, which are synchronized with their on-premises DNS servers. In Google Cloud, the custom DNS servers can be deployed on VM instances behind an internal load balancer for high availability.

DNS queries from Google Cloud to on-premises are sourced from the IP addresses of the custom DNS servers in the shared VPC networks.

On-premises DNS

Configure your on-premises DNS servers to be authoritative for on-premises DNS zones. Set up DNS forwarding (for Google Cloud DNS names) by targeting the custom DNS servers in the shared VPC. This allows the on-premises network to resolve Google Cloud DNS names.

Host project — Cloud DNS

Configure a Cloud DNS forwarding zone (for on-premises DNS names) targeting the custom DNS server in the Prod shared VPC. Set up an ingress firewall rule to allow DNS traffic from Cloud DNS egress proxies (35.199.192.0/19) into the custom DNS server instances. This allows DNS resolution for on-premises DNS names to be forwarded from Cloud DNS (via the egress proxies) to the custom DNS servers and then forwarded by the custom DNS servers onward to the on-premises DNS servers.

• Configure the Cloud DNS private zones for the host projects.
• Repeat the above configuration for the Non-Prod shared VPC.

Custom DNS servers — DNS forwarding

Within the custom DNS server, configure DNS forwarding for on-premises DNS names, targeting the on-premises DNS resolvers. This allows DNS queries for on-premises DNS names (received from the Cloud DNS egress proxies) to be forwarded to the on-premises DNS servers.

Inside the custom DNS server, configure a root forwarding zone (".”) targeting the instance metadata server (169.254.169.254). This allows DNS queries for Google Cloud DNS names (received from on-premises) to be resolved by the custom DNS servers via their instance metadata server

4. Private Service Connect (PSC) for Google APIs (access to all supported APIs and services)

Overview

You can use Private Service Connect (PSC) to access all supported Google APIs and services from Google Compute Engine (GCE) hosts and on-premises hosts using the internal IP address of a PSC endpoint in a shared VPC. In a hybrid connectivity scenario with multiple VPC (or shared VPC) networks, on-premises hosts can access Google APIs and services through PSC endpoints via any of the VPC (or shared VPC) networks.

The following steps focus on API access via the PSC endpoint in the Prod shared VPC (10.2.2.2). The same applies to API access via the PSC endpoint in the Non-Prod shared VPC (10.1.1.1).

Create a PSC endpoint

a. Choose a PSC endpoint address (e.g., 10.2.2.2) and create a PSC endpoint in the Prod shared VPC with a target of “all-apis,” which gives access to all supported Google APIs and services. Service Directory automatically creates a DNS record (with the DNS name of p.googleapis.com) linked to the PSC endpoint IP address.

Access from Google Compute Engine (GCE) hosts

GCE hosts can access all supported Google APIs and services via the PSC endpoint in the Prod shared VPC.

b. Enable Private Google Access on all subnets with compute instances that require access to Google APIs via PSC.

c. If your GCE clients can use custom DNS names (e.g., storage-xyz.p.googleapis.com), you can use the auto-created p.googleapis.com DNS name.

d. If your GCE clients cannot use custom DNS names, you can create Cloud DNS records using the default DNS names (e.g., storage.googleapis.com).

Access from on-premises hosts

On-premises hosts can access all supported Google APIs and services via the PSC endpoint in the Prod shared VPC. On the cloud router, advertise the PSC endpoint address to the on-premises network.

It is important to highlight here that on-prem hosts can only access Google APIs and services through the PSC endpoint in the same shared VPC, not in any other VPC networks.

e. If your on-premises clients can use custom DNS names (e.g., storage-xyz.p.googleapis.com), you can create A records mapping the custom DNS names to the PSC endpoint address.

f. If your on-premises clients cannot use custom DNS names, you can create A records mapping the default DNS names (e.g., storage.googleapis.com) to the PSC endpoint address.

 

5. Private Service Connect (PSC) for Google APIs (access to APIs and services supported under VPC Service Control)

Overview

You can use Private Service Connect (PSC) to access all supported secure Google APIs and services from Google Compute Engine (GCE) hosts and on-premises hosts using the internal IP address of a PSC endpoint in a shared VPC. In a hybrid connectivity scenario with multiple VPC (or shared VPC) networks, on-premises hosts can access Google APIs and services through PSC endpoints via any of the VPC (or shared VPC) networks.

The following steps focus on API access via the PSC endpoint in the Prod shared VPC (10.2.2.2). The same applies to API access via the PSC endpoint in the Non-Prod shared VPC (10.1.1.1).

Create a PSC endpoint

a. Choose a PSC endpoint address (e.g., 10.2.2.2) and create a PSC endpoint in the Prod shared VPC with a target of “vpc-sc,” which gives access to Google APIs and services that are supported under VPC Service Control. Service Directory automatically creates a DNS record (with the DNS name of p.googleapis.com) linked to the PSC endpoint IP address.

Access from Google Compute Engine (GCE) hosts

GCE hosts can access VPC Service Control-supported Google APIs and services via the PSC endpoint in the Prod shared VPC.

b. Enable Private Google Access on all subnets with compute instances that require access to Google APIs via PSC.

c. If your GCE clients can use custom DNS names (e.g., storage-xyz.p.googleapis.com), you can use the auto-created p.googleapis.com DNS name.

d. If your GCE clients cannot use custom DNS names, you can create Cloud DNS records using the default DNS names (e.g., storage.googleapis.com).

Access from on-premises hosts

On-premises hosts can access all secure Google APIs and services via the PSC endpoint in the Prod shared VPC.

e. On the cloud router, advertise the PSC endpoint IP address to the on-premises network.

f. If your on-premises clients can use custom DNS names (e.g., storage-xyz.p.googleapis.com), you can create A records mapping the custom DNS names to the PSC endpoint address.

g. If your on-premises clients cannot use custom DNS names, you can create A records mapping the default DNS names (e.g., storage.googleapis.com) to the PSC endpoint address.

6. VPC Service Control

Overview

VPC Service Control uses ingress and egress rules to control access to and from a perimeter. The rules specify the direction of allowed access to and from different identities and resources.

Let’s consider a specific use case where access is required to a protected service in Service Project 4 via the Prod shared VPC. Below is a description of VPC Service Control actions for this scenario.

Perimeter around service projects

In this example, there is a perimeter around Service Project 4, which includes the Google APIs and services that need protection.

API access from GCE hosts

A GCE instance can access secured APIs through a PSC endpoint in the shared VPC. Considering the perimeter around Service Project 4, the network interface of the compute instance GCE-4 is in the Prod shared VPC of the Prod host project. API calls from the GCE-4 instance to a service (e.g., storage.googleapis.com) in Service Project 4 appear to originate from the Prod host project, where the instance interface and PSC endpoint are located.

Ingress rule — Prod host project into the perimeter

Configure an ingress rule that allows Google API calls from the Prod host project to the protected services within the Service Project 4 perimeter. This rule permits API calls from the GCE instances (e.g., GCE-4) into the perimeter.

API access for on-premises hosts
On-premises hosts can access secured APIs in Service Project 4 via the PSC endpoint in the Prod shared VPC. API calls from on-premises to services in Service Project 4 appear to originate from the Prod host project, where the Interconnect (or VPN) and the PSC endpoint are located. The ingress rule (mentioned in step 3) allows API calls from on-premises to the Service Project 4 perimeter via the Prod host project.

As you continue to build and refine your hybrid cloud strategy, understanding these networking patterns is crucial for ensuring seamless connectivity across multiple VPC networks. In our next and final blog post of this series, we’ll explore advanced networking design patterns for hybrid connectivity using appliances within shared VPC networks on Google Cloud. Stay tuned as we dive into the specifics of how these configurations can further optimize your cloud infrastructure.

Read Part 3 of this series!