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 in derselben VM-Instanz zugewiesen sind, keine überlappenden IP-Bereiche haben können. 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, die das Betriebssystem Debian verwendet, vorübergehend aktualisieren können. Informationen zum dauerhaften Aktualisieren der VM oder zum Konfigurieren einer VM mit einem anderen Betriebssystem finden Sie in der öffentlichen Dokumentation des Betriebssystems.

`Subnet-a` in einem VPC-Netzwerk des Erstellers überschneidet sich mit `subnet-c` in einem VPC-Netzwerk des Nutzers, 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 richtlinienbasiertes Routing auf die VM Ihrer Schnittstelle an, um den Traffic basierend auf den 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 virtuelles Routing und Weiterleitung (VRF), um überlappende IP-Adressbereiche zu isolieren. Weisen Sie jeder Private Service Connect-Schnittstelle eine VRF-Instanz zu. Konfigurieren Sie Standardrouten für jede VRF-Instanz, damit der Traffic das gewünschte Ziel erreicht.
Verwenden Sie eBPF, um erweiterte Routingregeln anhand von anderen Kriterien, als der IP-Adresse anzupassen. Dieser Ansatz wird empfohlen, wenn 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:

Verbinden Sie sich mit der VM, auf der sich Ihre Private Service Connect-Schnittstelle befindet.
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 mit der IP-Adresse Ihrer Private Service Connect-Schnittstelle verknüpft.
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 Ihre Private Service Connect-Schnittstelle, den Sie in Schritt 2 ermittelt 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 Ihrer Private Service Connect-Schnittstelle:
```
sudo ip netns exec consumer-ns ip a
```
Prüfen Sie, ob der Name des Gastbetriebssystems der 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 Ihre 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
```
Die Routingtabelle muss einen Eintrag vom folgenden Format haben:
```
default via GATEWAY_IP dev OS_INTERFACE_NAME
```
So prüfen Sie, ob Ihre Schnittstelle VMs in jedem Teil des sich überschneidenden IP‑Adressbereichs erreichen kann:
1. Achten Sie darauf, dass die Firewallregeln so konfiguriert sind, dass eingehender ICMP-Traffic zu Ihren 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 ein richtlinienbasiertes Routing einrichten, um Zielüberschneidungen zu verwalten, wählen Sie Zielports für die Verwendung in Endnutzeranwendungen 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.

Verbinden Sie sich mit der VM Ihrer Private Service Connect-Schnittstelle.
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 Ihrer Private Service Connect-Schnittstelle, z. B. ens5.
Fügen Sie dem überlappenden Nutzersubnetzbereich über Ihr Standardgateway eine Route hinzu:
```
sudo ip route add CONSUMER_SUBNET_RANGE via GATEWAY_IP dev OS_INTERFACE_NAME table pscnet
```
Ersetzen Sie dabei Folgendes:
- 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 Routingtabelle 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 an den Zielport Ihrer Clientanwendung gerichtet ist:
```
sudo ip rule add dport CONSUMER_PORT table pscnet
```
Ersetzen Sie CONSUMER_PORT durch den Port, den Sie für den Traffic zu Ihrer Nutzer-VM konfiguriert haben.
So prüfen Sie, ob ein Paket basierend auf seinem Zielport 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 Nutzertest-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 an Ihre Test-VMs zugelassen wird.
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
```
  Ersetzen Sie dabei Folgendes:
  - TEST_IP_ADDRESS: Die IP-Adresse Ihrer Test-VMs.
  - CONSUMER_PORT ist der Port Ihrer Nutzeranwendung.
5. Stellen Sie über den Port, den Sie für Ihre Produktions-Test-VM konfiguriert haben, eine GET-Anfrage an die Test-IP-Adresse und prüfen Sie dann, ob Sie die richtige Instanz erreicht haben:
```
curl IP_ADDRESS:PRODUCER_PORT
```
  Ersetzen Sie dabei Folgendes:
  - IP_ADDRESS: die IP-Adresse Ihrer Test-VMs.
  - PRODUCER_PORT ist der Port, den Sie für Ihre Produktionstest-VM konfiguriert haben