Überlappende Subnetze in GCP mit Inter-VPC NAT meistern

In der Welt des Cloud Computing ist Netzwerkmanagement entscheidend dafür, dass Ihre Anwendungen und Services reibungslos laufen. Ein grundlegender Baustein dabei ist die Vergabe von IP-Adressen (Internet Protocol) an die einzelnen Ressourcen in Ihrer Cloud-Umgebung. Diese IP-Adressen fungieren als digitale Kennung Ihrer Cloud-Ressourcen und ermöglichen die Kommunikation untereinander sowie mit dem Internet.

Beim Netzwerkdesign – ob klassisch on-premises oder in einer Cloud-Plattform wie Google Cloud Platform (GCP) – begegnet man den Konzepten überlappender und nicht überlappender IP-Adressbereiche.

Überlappende IP-Bereiche liegen vor, wenn zwei oder mehr IP-Adressbereiche gemeinsame IP-Adressen enthalten und sich somit überschneiden.

Nicht überlappende IP-Bereiche sind Mengen von IP-Adressen, in denen jede Adresse eindeutig ist und sich nicht mit Adressen aus einem anderen Bereich überschneidet.

Jedes Virtual Private Cloud (VPC)-Netzwerk in GCP besteht aus einem oder mehreren Subnetzen, deren IP-Adressbereiche sich entweder mit denen anderer VPCs überschneiden oder eben nicht. Für Subnetze sollten Sie unbedingt nicht überlappende IP-Bereiche verwenden, da privater Netzwerkzugriff zwischen überlappenden Subnetzen standardmäßig nicht erlaubt ist.

In meinem vorherigen Artikel habe ich gezeigt, wie sich mit Private Service Connect (PSC) Services in VPC-Netzwerken mit überlappenden IP-Bereichen privat ansprechen lassen.

GCP hat kürzlich Private NAT als Preview veröffentlicht, um die private Kommunikation zwischen überlappenden Netzwerken zu vereinfachen. In diesem Artikel zeigen wir, wie Sie Inter-VPC NAT konfigurieren, um Services in unterschiedlichen VPC-Netzwerken mit überlappenden und nicht überlappenden IP-Bereichen privat zu erreichen.

In GCP ist VPC-Peering zwischen überlappenden Netzwerken nicht zulässig, weil sich einzelne Subnetze nicht gezielt zwischen VPCs teilen lassen. Inter-VPC NAT ist ein Private NAT Gateway, mit dem Ressourcen in überlappenden Subnetzen über ein anderes VPC mit Ressourcen in nicht überlappenden Subnetzen kommunizieren können – auch wenn weitere Subnetze überlappen. Möglich wird das über eine NAT-Konfiguration mit type=PRIVATE.

Inter-VPC NAT arbeitet mit dem Network Connectivity Center zusammen – einem einheitlichen, ganzheitlichen System zur Verwaltung der Netzwerkkonnektivität. Es bündelt die verschiedenen Netzwerkfunktionen von Google Cloud in einer einzigen Oberfläche und vereinfacht so die Anbindung und Verwaltung Ihrer Cloud- und On-Premises-Netzwerke.

Das Network Connectivity Center setzt auf ein Hub-and-Spoke-Modell. Ein Hub ist der zentrale Konnektivitätspunkt zu Ihren Virtual Private Cloud (VPC)-Netzwerken. Sie können ihn sich als virtuellen Router vorstellen, der die Verbindungen verschiedener Spokes bündelt. Spokes können VPNs, Interconnects, Router von Drittanbietern oder andere VPC-Netzwerke sein.

Damit Inter-VPC NAT zwischen VPC-Netzwerken funktioniert, müssen Sie jedes VPC-Netzwerk als VPC-Spoke eines Network Connectivity Center Hubs einrichten. Über VPC-Spokes lassen sich mehrere VPC-Netzwerke verbinden und einzelne IPv4-Subnetz-Routen austauschen – etwas, das beim VPC-Peering nicht möglich ist. So entsteht volle IPv4-Konnektivität zwischen allen workloads in diesen VPC-Netzwerken.

Beim Anlegen des Spokes müssen Sie verhindern, dass die überlappenden IP-Adressbereiche an andere VPC-Spokes weitergegeben werden.

Inter-VPC NAT hat in der Preview aktuell folgende wesentliche Einschränkungen.

• Inter-VPC NAT unterstützt kein Endpoint-Independent Mapping.
• Inter-VPC NAT mit projektübergreifender Unterstützung steht in der Preview nicht zur Verfügung.
• Logging-Unterstützung für Inter-VPC NAT steht in der Preview nicht zur Verfügung.
• In der Preview dürfen Sie ein bestehendes Private NAT Gateway ausschließlich über die gcloud CLI aktualisieren. Aktualisierungen über die Google Cloud Console können zu einer fehlerhaften Konfiguration führen.
• Inter-VPC NAT unterstützt ausschließlich TCP- und UDP-Verbindungen.
• Inter-VPC NAT unterstützt Network Address Translation (NAT) ausschließlich zwischen VPC-Spokes des Network Connectivity Centers, nicht aber zwischen VPC-Netzwerken, die per VPC Network Peering verbunden sind.
• Eine Virtual-Machine (VM)-Instanz in einem VPC-Netzwerk kann nur Ziele in einem nicht überlappenden Subnetz eines gepeerten Netzwerks erreichen, nicht jedoch in einem überlappenden Subnetz.

Möglicherweise hebt GCP einige Einschränkungen vor dem GA-Release auf. Aktuelle Informationen finden Sie in der offiziellen Dokumentation.

In diesem Setup haben vpc-a und vpc-b jeweils ein Subnetz mit einem überlappenden IP-Adressbereich. vpc-b verfügt zusätzlich über ein nicht überlappendes Subnetz, in dem eine Beispielanwendung läuft.

In vpc-a wird ein Private NAT Gateway bereitgestellt, damit Instanzen aus dem überlappenden Subnetz die Beispielanwendung im nicht überlappenden Subnetz erreichen.

https://cloud.google.com/nat/docs/private-nat#pvt-nat-flow-example

Schritt 1: Die nötigen Umgebungsvariablen setzen.

export PROJECT_ID="your-project-id" #ex: chimbu-playground
export VPC_A_SUBNET_REGION="us-east1"
export VPC_A_SUBNET_A_CIDR="192.168.1.0/24"
export VPC_B_SUBNET_REGION="us-west1"
export VPC_B_SUBNET_B_CIDR="192.168.2.0/24" #non-overlapping subnet between vpc-a and vpc-b
export VPC_B_SUBNET_C_CIDR="192.168.1.0/24" #overlapping subnet between vpc-a and vpc-b
export VPC_A_PRIVATE_NAT_GW_CIDR="10.1.2.0/29"

Schritt 2: VPC-Netzwerke und Subnetze anlegen.

#Create vpc-a custom Network and subnet
gcloud beta compute networks create vpc-a \
  --subnet-mode=custom

gcloud beta compute networks subnets create subnet-a \
  --network="vpc-a" \
  --role="ACTIVE" \
  --purpose="PRIVATE" \
  --range=$VPC_A_SUBNET_A_CIDR  \
  --region=$VPC_A_SUBNET_REGION

# Create vpc-b custom Network and subnets
gcloud beta compute networks create vpc-b \
  --subnet-mode=custom

gcloud beta compute networks subnets create subnet-b \
  --network="vpc-b" \
  --role="ACTIVE" \
  --purpose="PRIVATE" \
  --range=$VPC_B_SUBNET_B_CIDR  \
  --region=$VPC_B_SUBNET_REGION

gcloud beta compute networks subnets create subnet-c \
  --network="vpc-b" \
  --role="ACTIVE" \
  --purpose="PRIVATE" \
  --range=$VPC_B_SUBNET_C_CIDR  \
  --region=$VPC_B_SUBNET_REGION

Schritt 3: Firewall-Regeln für Identity-Aware Proxy (IAP) TCP Forwarding anlegen, um SSH-Zugriff auf VM-Instanzen zu ermöglichen.

In den folgenden Schritten erstellen wir VM-Instanzen ohne externe IPs. IAP TCP Forwarding stellt einen verschlüsselten Tunnel bereit, über den sich SSH-, RDP- und weiterer Datenverkehr an VM-Instanzen weiterleiten lässt.

Achten Sie darauf, dass den Nutzern die Rolle roles/iap.tunnelResourceAccessor zugewiesen ist, damit sie TCP Forwarding und zugehörige Aufgaben ausführen können.

gcloud compute firewall-rules create vpc-a-iap \
  --direction=INGRESS \
  --priority=1000 \
  --network=vpc-a \
  --action=ALLOW \
  --rules=tcp:22 \
  --source-ranges=35.235.240.0/20

gcloud compute firewall-rules create vpc-b-iap \
  --direction=INGRESS \
  --priority=1000 \
  --network=vpc-b \
  --action=ALLOW \
  --rules=tcp:22 \
  --source-ranges=35.235.240.0/20

Schritt 4: Eine Cloud-NAT-Instanz für den Internetzugriff anlegen. Diese Cloud-NAT-Instanz erlaubt keine private Kommunikation zwischen VPCs – das richten wir separat ein.

#vpc-a Cloud router and NAT
gcloud compute routers create vpc-a-internet-nat-router \
  --network=vpc-a \
  --region=$VPC_A_SUBNET_REGION

gcloud beta compute routers nats create vpc-a-internet-nat \
  --router=vpc-a-internet-nat-router \
  --nat-all-subnet-ip-ranges \
  --region=$VPC_A_SUBNET_REGION \
  --auto-allocate-nat-external-ips

#vpc-b Cloud router and NAT
gcloud compute routers create vpc-b-internet-nat-router \
  --network=vpc-b \
  --region=$VPC_B_SUBNET_REGION

gcloud beta compute routers nats create vpc-b-internet-nat \
  --router=vpc-b-internet-nat-router \
  --nat-all-subnet-ip-ranges \
  --region=$VPC_B_SUBNET_REGION \
  --auto-allocate-nat-external-ips

Cloud NAT für den Internetzugriff der Compute-Engine-Instanzen im Netzwerk

Schritt 5: Test-Compute-Engine-Instanzen ohne externe IP anlegen.

#Test instance in vpc-a network and subnet-a
gcloud compute instances create vpc-a-subnet-a-test \
  --project=$PROJECT_ID \
  --zone="us-east1-b" \
  --machine-type=e2-medium \
  --network-interface=stack-type=IPV4_ONLY,subnet=subnet-a,no-address \
  --tags=http-server \
  --create-disk=auto-delete=yes,boot=yes,device-name=vpc-a-subnet-a-test,image=projects/debian-cloud/global/images/debian-11-bullseye-v20230814,mode=rw,size=10,type=projects/$PROJECT_ID/zones/us-east1-b/diskTypes/pd-balanced

#Test instance in vpc-b network and subnet-b, Also deployed nginx service.Cloud NAT to download the required ngninx packages.
gcloud compute instances create vpc-b-subnet-b-test \
  --project=$PROJECT_ID \
  --zone="us-west1-a" \
  --machine-type=e2-medium \
  --network-interface=stack-type=IPV4_ONLY,subnet=subnet-b,no-address \
  --metadata=startup-script=\#/bin/sh$'\n'sudo\ \
apt\ update$'\n'sudo\ apt\ install\ nginx\ -y\ \
  --tags=http-server \
  --create-disk=auto-delete=yes,boot=yes,device-name=vpc-b-subnet-b-test,image=projects/debian-cloud/global/images/debian-11-bullseye-v20230814,mode=rw,size=10,type=projects/$PROJECT_ID/zones/us-west1-a/diskTypes/pd-balanced

#Test instance deployed in vpc-b network and subnet-c
gcloud compute instances create vpc-b-subnet-c-test \
  --project=$PROJECT_ID \
  --zone="us-west1-a" \
  --machine-type=e2-medium \
  --network-interface=stack-type=IPV4_ONLY,subnet=subnet-c,no-address \
  --tags=http-server \
  --create-disk=auto-delete=yes,boot=yes,device-name=vpc-b-subnet-c-test,image=projects/debian-cloud/global/images/debian-11-bullseye-v20230814,mode=rw,size=10,type=projects/$PROJECT_ID/zones/us-west1-a/diskTypes/pd-balanced

Compute-Engine-Instanzen

An dieser Stelle kann die Instanz vpc-a-subnet-a-test in vpc-a noch nicht auf den Service in vpc-b-subnet-b-test zugreifen, da keine Netzwerkverbindung besteht. Wegen des überlappenden Subnetzes lässt sich auch kein VPC-Peering zwischen den Netzwerken einrichten.

Damit zwei VPC-Netzwerke mit überlappenden Subnetz-IP-Bereichen miteinander kommunizieren können, müssen Sie sie als VPC-Spokes konfigurieren, die mit demselben Network Connectivity Center Hub verbunden sind.

Schritt 6: Einen Network Connectivity Center Hub anlegen.

gcloud network-connectivity hubs create private-nat-demo-vpc-hub

Schritt 7: Die VPC-Netzwerke als Spokes zum Hub hinzufügen. Achten Sie darauf, die überlappenden Netzwerke vom Export auszuschließen.

#Add vpc-a to the hub and exclue VPC_A_SUBNET_A_CIDR from export.
gcloud network-connectivity spokes linked-vpc-network create vpc-a \
  --hub="https://www.googleapis.com/networkconnectivity/v1/projects/$PROJECT_ID/locations/global/hubs/private-nat-demo-vpc-hub" --global \
  --vpc-network="https://www.googleapis.com/compute/v1/projects/$PROJECT_ID/global/networks/vpc-a" \
  --exclude-export-ranges=$VPC_A_SUBNET_A_CIDR

#Add vpc-b to the hub and exclue VPC_B_SUBNET_C_CIDR from export.VPC_B_SUBNET_B_CIDR will be exported between the VPCs.
gcloud network-connectivity spokes linked-vpc-network create vpc-b \
  --hub="https://www.googleapis.com/networkconnectivity/v1/projects/$PROJECT_ID/locations/global/hubs/private-nat-demo-vpc-hub" --global \
  --vpc-network="https://www.googleapis.com/compute/v1/projects/$PROJECT_ID/global/networks/vpc-b" \
  --exclude-export-ranges=$VPC_B_SUBNET_C_CIDR

VPC-Spokes

Zwischen den VPCs ausgetauschte Route

Inter-VPC NAT setzt ein dediziertes Subnetz mit dem Zweck PRIVATE_NAT voraus. Das Private NAT Gateway nutzt IP-Adressbereiche aus diesem Subnetz, um NAT durchzuführen. Dieses Subnetz darf sich mit keinem bestehenden Subnetz in einem der VPC-Spokes überschneiden, die mit demselben Network Connectivity Center Hub verbunden sind. Es wird ausschließlich für Private NAT verwendet.

Schritt 8: Ein Subnetz für Private NAT anlegen. Es entsteht in vpc-a, da von dort aus auf den Service in vpc-b zugegriffen werden soll. Private NAT führt NAT ausschließlich für ausgehende Anfragen aus.

gcloud beta compute networks subnets create private-nat-gateway \
  --network=vpc-a \
  --region=$VPC_A_SUBNET_REGION \
  --range=$VPC_A_PRIVATE_NAT_GW_CIDR \
  --purpose=PRIVATE_NAT

Schritt 9: Cloud Router und Private NAT Gateway anlegen.

gcloud compute routers create vpc-a-private-nat-gw-router \
  --network="vpc-a" \
  --region=$VPC_A_SUBNET_REGION

gcloud beta compute routers nats create vpc-a-private-nat-gw \
  --router=vpc-a-private-nat-gw-router \
  --type=PRIVATE \
  --nat-all-subnet-ip-ranges \
  --region=$VPC_A_SUBNET_REGION

Schritt 10: Eine NAT-Regel im Private NAT Gateway anlegen, damit NAT auf den Datenverkehr angewendet wird, der vom Quell-VPC-Spoke zu einem der Peer-VPC-Spokes desselben Network Connectivity Center Hubs ausgeht. Anhand der NAT-Regel weist das Private NAT Gateway IP-Adressen aus dem Private-NAT-Subnetz zu, um NAT auf den Datenverkehr anzuwenden.

gcloud beta compute routers nats rules create 1000 \
  --router=vpc-a-private-nat-gw-router \
  --nat=vpc-a-private-nat-gw \
  --match='nexthop.hub == "//networkconnectivity.googleapis.com/projects/chimbuc-playground/locations/global/hubs/private-nat-demo-vpc-hub"' \
  --source-nat-active-ranges=private-nat-gateway \
  --region=$VPC_A_SUBNET_REGION

Private NAT Gateway

Schritt 11: Eine Firewall-Regel in vpc-b anlegen, die Verbindungen vom Private NAT Gateway zulässt.

gcloud compute firewall-rules create vpc-b-allow-ingress-private-nat-gw \
  --direction=INGRESS \
  --priority=1000 \
  --network=vpc-b \
  --action=ALLOW \
  --rules=tcp \
  --source-ranges=$VPC_A_PRIVATE_NAT_GW_CIDR

Schritt 12: Die Konnektivität zwischen den Netzwerken vpc-a und vpc-b testen.

Der Screenshot bestätigt: Die Instanz in vpc-a erreicht den Service im nicht überlappenden Subnetz von vpc-b über Inter-VPC NAT.