Überlappende Subnetze in Google Cloud mit Inter-VPC NAT lösen

In der weiten Welt des Cloud Computing ist ein sauberes Netzwerkmanagement entscheidend für den reibungslosen Betrieb Ihrer Anwendungen und Dienste.

Overcoming-Overlapping-Subnet-Challenges-with-Inter-VPC-NAT-in-GCP

Foto von Ar_TH auf Shutterstock

Einleitung

In der weiten Welt des Cloud Computing ist ein sauberes Netzwerkmanagement entscheidend für den reibungslosen Betrieb Ihrer Anwendungen und Dienste. Ein grundlegender Bestandteil davon ist die Vergabe von IP-Adressen (Internet Protocol) an die einzelnen Ressourcen Ihrer Cloud-Umgebung. Diese IP-Adressen dienen als digitale Kennung Ihrer Cloud-Ressourcen und ermöglichen die Kommunikation untereinander sowie mit dem Internet.

Beim Entwurf eines Netzwerks – ob klassisch on-premises oder auf einer Cloud-Plattform wie der Google Cloud Platform (GCP) – stoßen Sie unweigerlich auf die Konzepte überlappender und nicht überlappender IP-Adressbereiche.

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

Nicht überlappende IP-Bereiche sind dagegen 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 nicht. Für Subnetze sollten Sie unbedingt nicht überlappende IP-Bereiche verwenden, da privater Netzwerkzugriff zwischen überlappenden Subnetzen standardmäßig nicht möglich ist.

In meinem vorherigen Artikel habe ich gezeigt, wie sich mit Private Service Connect (PSC) privat auf Dienste in VPC-Netzwerken mit überlappenden IP-Bereichen zugreifen lässt.

Vor Kurzem hat GCP Private NAT als Preview-Release vorgestellt. Ziel ist es, die private Kommunikation zwischen überlappenden Netzwerken zu erleichtern. In diesem Artikel sehen wir uns an, wie Sie Inter-VPC NAT konfigurieren, um privat auf Dienste zuzugreifen, die in verschiedenen VPC-Netzwerken mit überlappenden und nicht überlappenden IP-Bereichen laufen.

Was ist Inter-VPC NAT?

In GCP ist VPC-Peering zwischen überlappenden Netzwerken nicht zulässig, da sich darüber keine spezifischen Subnetze zwischen VPCs teilen lassen. Inter-VPC NAT ist ein Private-NAT-Gateway-Angebot, mit dem VPC-Netzwerkressourcen in überlappenden Subnetzen über eine andere VPC mit Ressourcen in nicht überlappenden Subnetzen kommunizieren können – auch dann, wenn sich weitere Subnetze überschneiden. Möglich wird das durch eine NAT-Konfiguration vom Typ type=PRIVATE.

Inter-VPC NAT arbeitet dabei mit dem Network Connectivity Center zusammen, einem einheitlichen, ganzheitlichen und vereinfachten System zur Verwaltung von Netzwerkverbindungen. Es bringt die verschiedenen Netzwerkfunktionen von Google Cloud in einer einzigen Oberfläche zusammen und erleichtert Ihnen so die Anbindung und Verwaltung Ihrer Cloud- und On-Premises-Netzwerke.

Das Network Connectivity Center setzt dabei auf ein Hub-and-Spoke-Modell. Ein Hub ist der zentrale Knotenpunkt, an dem Ihre Virtual Private Cloud (VPC)-Netzwerke angebunden sind – Sie können sich ihn wie einen virtuellen Router vorstellen, der die Konnektivität verschiedener Spokes bündelt. Spokes können VPNs, Interconnects, Router von Drittanbietern oder weitere 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 konfigurieren. Über VPC Spokes lassen sich mehrere VPC-Netzwerke verbinden und gezielt IPv4-Subnetzrouten austauschen – etwas, das mit 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.

Einschränkungen

In der Preview gelten für Inter-VPC NAT derzeit folgende wesentliche Einschränkungen:

Inter-VPC NAT unterstützt kein Endpoint-Independent Mapping.
Inter-VPC NAT mit Cross-Project-Unterstützung steht in der Preview nicht zur Verfügung.
Logging-Unterstützung für Inter-VPC NAT ist in der Preview nicht verfügbar.
In der Preview dürfen Sie ein bestehendes Private-NAT-Gateway ausschließlich über die gcloud CLI aktualisieren. Eine Aktualisierung über die Google Cloud Console kann 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 Virtual Private Cloud (VPC) Spokes des Network Connectivity Center, nicht jedoch mit VPC-Netzwerken, die per VPC Network Peering verbunden sind.
Eine virtuelle Maschine (VM) in einem VPC-Netzwerk kann in einem gepeerten Netzwerk nur Ziele in einem nicht überlappenden Subnetz erreichen, nicht aber in einem überlappenden Subnetz.

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

Referenzarchitektur

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 im überlappenden Subnetz die Beispielanwendung im nicht überlappenden Subnetz erreichen können.

alttext

Private Nat Flow Example

Netzwerk einrichten und Beispielanwendung bereitstellen

Schritt 1: Legen Sie die erforderlichen Umgebungsvariablen fest.

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: Legen Sie die VPC-Netzwerke und Subnetze an.

#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: Erstellen Sie Firewall-Regeln für Identity-Aware Proxy (IAP) TCP Forwarding, um SSH-Zugriff auf VM-Instanzen zu ermöglichen.

In den folgenden Schritten erstellen wir VM-Instanzen ohne externe IPs. IAP TCP Forwarding ermöglicht einen verschlüsselten Tunnel, über den Sie SSH, RDP und weiteren Datenverkehr an die VM-Instanzen weiterleiten können.

Stellen Sie sicher, dass den Benutzern 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: Erstellen Sie eine Cloud-NAT-Instanz für den Internetzugang. 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

Schritt 5: Erstellen Sie Test-Instanzen in Compute Engine ohne externe IP.

#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

Compute

An diesem Punkt kann die Instanz vpc-a-subnet-a-test in vpc-a den Dienst auf der Instanz vpc-b-subnet-b-test noch nicht erreichen, weil keine Netzwerkverbindung besteht – und wegen des überlappenden Subnetzes lässt sich auch kein VPC-Peering zwischen den Netzwerken einrichten.

Hub und VPC Spokes im Network Connectivity Center einrichten

Damit zwei VPC-Netzwerke mit überlappenden Subnetz-IP-Bereichen miteinander kommunizieren können, müssen Sie sie als VPC Spokes konfigurieren, die am selben Network Connectivity Center Hub hängen.

Schritt 6: Erstellen Sie einen Network Connectivity Center Hub.

Schritt 7: Binden Sie die VPC-Netzwerke als Spokes an den Hub an. Achten Sie darauf, dass die überlappenden Netzwerke vom Export ausgeschlossen werden.

VPC

VPC Spokes

Exchanged

Zwischen den VPCs ausgetauschte Route

Inter-VPC NAT einrichten

Inter-VPC NAT benötigt ein dediziertes Subnetz mit dem Zweck PRIVATE_NAT. Das Private-NAT-Gateway nutzt IP-Adressbereiche aus diesem Subnetz, um NAT durchzuführen. Dieses Subnetz darf sich nicht mit einem bestehenden Subnetz in einem der VPC Spokes überschneiden, die am selben Network Connectivity Center Hub hängen, und wird ausschließlich für Private NAT verwendet.

Schritt 8: Erstellen Sie ein Subnetz für Private NAT. Es wird in vpc-a angelegt, da von dort aus auf den Dienst in vpc-b zugegriffen werden soll. Private NAT führt NAT ausschließlich für ausgehende Anfragen durch.

Create

Schritt 9: Erstellen Sie einen Cloud Router und ein Private-NAT-Gateway.

Schritt 10: Legen Sie im Private-NAT-Gateway eine NAT-Regel an, die NAT auf den Datenverkehr anwendet, der vom Quell-VPC-Spoke an einen der Peer-VPC-Spokes desselben Network Connectivity Center Hubs ausgeht. Auf Basis dieser Regel weist das Private-NAT-Gateway dem Datenverkehr NAT-IP-Adressen aus dem Private-NAT-Subnetz zu.

Private

Schritt 11: Legen Sie in vpc-b eine Firewall-Regel an, die Verbindungen vom Private-NAT-Gateway zulässt.

Schritt 12: Testen Sie die Konnektivität zwischen den Netzwerken vpc-a und vpc-b.

non-overlapping

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

Inter-VPC NAT ist ein leistungsstarkes Werkzeug, das die private Kommunikation zwischen überlappenden Netzwerken deutlich vereinfacht. Damit stellen Sie sicher, dass eine Ressource privat mit Ressourcen in nicht überlappenden Subnetzen einer anderen VPC kommunizieren kann – selbst wenn sie selbst in einem Subnetz liegt, das sich mit anderen Subnetzen überschneidet.

Für die private Kommunikation zwischen überlappenden Subnetzen können Sie außerdem Private Service Connect nutzen. Ich hoffe, dieser Beitrag war hilfreich – bei Fragen können Sie sich gerne an mich wenden.