Zielüberschneidung verwalten

Auf dieser Seite wird beschrieben, wie Administratoren eines Erstellernetzwerks Zielüberschneidungen in einem VPC-Netzwerk (Virtual Private Cloud) verwalten können, das eine Private Service Connect-Schnittstelle verwendet.

Google Cloud stellt sicher, dass die IP-Adressbereiche von Subnetzen, die Netzwerkschnittstellen auf derselben VM-Instanz zugewiesen sind, keine sich überschneidenden IP-Adressbereiche haben dürfen. Die Subnetze in den Nutzer- und Ersteller-VPC-Netzwerken können sich jedoch überschneiden, wie in Abbildung 1 dargestellt. Wenn Sie eine Private Service Connect-Schnittstelle mit sich überschneidenden Ziel-IP-Adressbereichen verwenden, ist eine zusätzliche Konfiguration erforderlich, damit der Traffic das richtige Ziel im gewünschten Netzwerk erreicht.

Die auf dieser Seite beschriebenen Befehle zeigen, wie Sie das Routing für eine VM mit dem Betriebssystem Debian vorübergehend aktualisieren. Informationen zum dauerhaften Aktualisieren der VM oder zum Konfigurieren einer VM mit einem anderen Betriebssystem finden Sie in der öffentlichen Dokumentation des Betriebssystems.

**Abbildung 1.** `Subnet-a` in einem Ersteller-VPC-Netzwerk überschneidet sich mit `subnet-c` in einem Nutzer-VPC-Netzwerk, da beide Subnetze denselben IP-Adressbereich verwenden. Ersteller-VMs müssen `10.0.1.5` in beiden Netzwerken erreichen können.

Sie können sich überschneidende Ziel-IP-Adressbereiche auf folgende Weisen verwalten, die auf dieser Seite ausführlich beschrieben werden:

Verwenden Sie Netzwerk-Namespaces, um separate Routingtabellen für die einzelnen Anwendung zu erstellen.
Wenden Sie das richtlinienbasierte Routing auf die VM Ihrer Schnittstelle an, um Traffic anhand von Zielports weiterzuleiten.

Folgende Ansätze können auch zum Verwalten von Zielüberschneidungen verwendet werden. Sie werden jedoch auf dieser Seite nicht beschrieben:

Verwenden Sie eine Socket-Bibliothek und bind(), um das Routing zu steuern.
Verwenden Sie einen sich vollständig nicht überschneidenden IP-Adressbereich für das Erstellernetzwerk.
Wenn die erstellerseitigen überlappenden IP-Adressen nur für eigene API-Endpunkte relevant sind, können Sie privaten Google-Zugriff für lokale Hosts konfigurieren.
Verwenden Sie eBPF, um erweiterte Routingregeln anhand von anderen Kriterien, als der IP-Adresse anzupassen. Dieser Ansatz wird für Fälle empfohlen, in denen die vorherigen Optionen nicht möglich sind.

Zieladressenüberschneidung über Netzwerk-Namespaces verwalten

Sie können die Überschneidung von Zieladressen übern Netzwerk-Namespaces verwalten. Dieser Ansatz eignet sich gut, wenn einige Anwendungen auf einer Produzenten-VM nur auf Nutzerarbeitslasten und andere Anwendungen auf der Ersteller-VM nur auf Erstellerarbeitslasten zugreifen müssen.

So verwalten Sie die Überschneidung von Zieladressen mithilfe von Netzwerk-Namespaces:

Stellen Sie eine Verbindung zur VM her, die Ihre Private Service Connect-Schnittstelle hat.
Führen Sie dazu diesen Befehl aus:
```
ip address
```
Suchen Sie in der Liste der Netzwerkschnittstellen den Namen des Gastbetriebssystems für Ihre Private Service Connect-Schnittstelle, z. B. ens5. Dieser Name ist der IP-Adresse Ihrer Private Service Connect-Schnittstelle zugeordnet.
Erstellen Sie einen Netzwerk-Namespace für nutzergebundenen Traffic:
```
sudo ip netns add consumer-ns
```
Verschieben Sie die Private Service Connect-Schnittstelle in den Namespace des Nutzernetzwerks. Führen Sie folgende Befehle einzeln aus:
```
sudo ip link set OS_INTERFACE_NAME netns consumer-ns
```
```
sudo ip netns exec consumer-ns ip link set OS_INTERFACE_NAME up
```
Ersetzen Sie OS_INTERFACE_NAME durch den Namen des Gastbetriebssystems für die Private Service Connect-Schnittstelle, den Sie in Schritt 2 gefunden haben, z. B. ens5.
Stellen Sie die IP-Adresse der Private Service Connect-Schnittstelle wieder her:
```
sudo ip netns exec consumer-ns ip addr add INTERFACE_IP/32 dev OS_INTERFACE_NAME
```
Ersetzen Sie INTERFACE_IP durch die IP-Adresse Ihrer Private Service Connect-Schnittstelle.
Prüfen Sie die Änderungen an der Private Service Connect-Schnittstelle:
```
sudo ip netns exec consumer-ns ip a
```
Achten Sie darauf, dass der Name des Gastbetriebssystems Ihrer Private Service Connect-Schnittstelle in der Ausgabe des Befehls aufgeführt ist. Prüfen Sie, ob die Schnittstelle die richtige IP-Adresse hat.
Fügen Sie der Gateway-IP-Adresse eine Route hinzu:
```
sudo ip netns exec consumer-ns ip route add GATEWAY_IP dev OS_INTERFACE_NAME scope link
```
Ersetzen Sie GATEWAY_IP durch die IP-Adresse des Standardgateways für das Subnetz Ihrer Private Service Connect-Schnittstelle.

Fügen Sie eine Standardroute für die Private Service Connect-Schnittstelle hinzu:

sudo ip netns exec consumer-ns ip route add default via GATEWAY_IP dev OS_INTERFACE_NAME

Prüfen Sie die Routingtabelle für den consumer-ns-Namespace:
```
sudo ip netns exec consumer-ns ip route
```
Achten Sie darauf, dass die Routingtabelle einen Eintrag im folgenden Format hat:
```
default via GATEWAY_IP dev OS_INTERFACE_NAME
```
So prüfen Sie, ob Ihre Schnittstelle VMs in jedem Teil des überlappenden IP-Adressbereichs erreichen kann:
1. Achten Sie darauf, dass Firewallregeln so konfiguriert sind, dass eingehender ICMP-Traffic an Ihre Ziel-VMs zugelassen wird.
2. Senden Sie einen ICMP-Ping von der VM Ihrer Schnittstelle an eine Nutzer-VM, die sich im überlappenden IP-Adressbereich befindet. Verwenden Sie Ihren Nutzer-Namespace:
```
sudo ip netns exec consumer-ns ping CONSUMER_IP_ADDRESS
```
  Ersetzen Sie CONSUMER_IP_ADDRESS durch die IP-Adresse einer Nutzer-VM aus dem überlappenden IP-Adressbereich.
3. Senden Sie einen ICMP-Ping von der VM Ihrer Schnittstelle an eine Ersteller-VM, die sich im überlappenden IP-Adressbereich befindet. Verwenden Sie den Standard-Namespace:
```
ping PRODUCER_IP_ADDRESS
```
  Ersetzen Sie PRODUCER_IP_ADDRESS durch die IP-Adresse einer Produzenten-VM aus dem überlappenden IP-Adressbereich.

Zieladressenüberschneidung mit richtlinienbasiertem Routing verwalten

Um die Überschneidung von Zieladressen zu verwalten, können Sie das richtlinienbasierte Routing auf dem Betriebssystem der VM Ihrer Schnittstelle konfigurieren. Dieser Ansatz funktioniert gut, wenn dieselbe Anwendung auf Arbeitslasten zugreifen muss, die sich sowohl in den Nutzer- als auch in den VPC-Netzwerken des Erstellers befinden. Sie müssen den Vorgang jedoch für jeden Port wiederholen, den Sie im überlappenden IP-Bereich erreichen möchten.

Wenn Sie das richtlinienbasierte Routing zum Verwalten der Zielüberschneidung einrichten, wählen Sie Zielports für Nutzeranwendungen aus. Traffic, der an einen dieser Ports gebunden ist, wird über die Private Service Connect-Schnittstelle an das Nutzer-Subnetz geleitet, während der andere Traffic über die Standardschnittstelle an das Ersteller-Subnetz geleitet wird.

Stellen Sie eine Verbindung zur VM Ihrer Private Service Connect-Schnittstelle her.
Wenn der Befehl iproute2 nicht verfügbar ist, installieren Sie ihn.
Achten Sie darauf, dass Sie in folgende Datei schreiben können: /etc/iproute2/rt_tables
Erstellen Sie eine Routingtabelle. Fügen Sie eine Standardroute für Ihre Private Service Connect-Schnittstelle hinzu:
```
echo "200 pscnet" >> /etc/iproute2/rt_tables \
sudo ip route add default dev OS_INTERFACE_NAME table pscnet
```
Ersetzen Sie OS_INTERFACE_NAME durch den Namen des Gastbetriebssystems der Private Service Connect-Schnittstelle, z. B. ens5.
Fügen Sie dem überlappenden Nutzer-Subnetzbereich eine Route über Ihr Standardgateway hinzu:
```
sudo ip route add CONSUMER_SUBNET_RANGE via GATEWAY_IP dev OS_INTERFACE_NAME table pscnet
```
Dabei gilt:
- CONSUMER_SUBNET_RANGE ist der IP-Adressbereich Ihres Nutzersubnetzes.
- GATEWAY_IP ist die IP-Adresse des Standardgateways für das Subnetz Ihrer Private Service Connect-Schnittstelle.
Aktualisieren Sie die Routentabelle so, dass ausgehende Pakete von dieser VM die IP-Adresse Ihrer Schnittstelle als Quell-IP-Adresse verwenden:
```
sudo ip route add GATEWAY_IP src INTERFACE_IP dev OS_INTERFACE_NAME table pscnet
```
Ersetzen Sie INTERFACE_IP durch die IP-Adresse Ihrer Private Service Connect-Schnittstelle.
Fügen Sie eine IP-Regel hinzu, die für den gesamten Traffic gilt, der für den Zielport Ihrer Nutzeranwendung bestimmt ist:
```
sudo ip rule add dport CONSUMER_PORT table pscnet
```
Ersetzen Sie CONSUMER_PORT durch den Port, den Sie für Traffic zu Ihrer Nutzer-VM konfiguriert haben.
So prüfen Sie, ob ein Paket anhand seines Zielports an die richtige VM weitergeleitet wird:
1. Erstellen Sie in den Ersteller- und Nutzernetzwerken Test-VMs, die dieselbe IP-Adresse aus dem überlappenden Bereich verwenden.
2. Richten Sie auf jeder Test-VM einen HTTP-Server ein. Konfigurieren Sie die Nutzer-Test-VM so, dass sie den Port überwacht, den Sie für die Nutzeranwendung eingerichtet haben. Konfigurieren Sie die Test-VM des Erstellers, um einen anderen Port zu überwachen, als Sie für die Nutzeranwendung eingerichtet haben.
3. Achten Sie darauf, dass Firewallregeln so konfiguriert sind, dass HTTP-Traffic zu Ihren Test-VMs zugelassen ist.
4. Stellen Sie über den Port, den Sie für Ihre Nutzeranwendung konfiguriert haben, eine GET-Anfrage an die Test-IP-Adresse und prüfen Sie dann, ob Sie die richtige Instanz erreicht haben:
```
curl TEST_IP_ADDRESS:CONSUMER_PORT
```
  Dabei gilt:
  - TEST_IP_ADDRESS ist die IP-Adresse Ihrer Test-VMs.
  - CONSUMER_PORT ist der Port Ihrer Nutzeranwendung.
5. Stellen Sie mithilfe des Ports, den Sie für Ihre Produktionstest-VM konfiguriert haben, eine GET-Anfrage an die Test-IP-Adresse und prüfen Sie, ob Sie die richtige Instanz erreicht haben:
```
curl IP_ADDRESS:PRODUCER_PORT
```
  Dabei gilt:
  - IP_ADDRESS: die IP-Adresse Ihrer Test-VMs.
  - PRODUCER_PORT ist der Port, den Sie für Ihre Produktionstest-VM konfiguriert haben