Reihenfolge der Routen

Auf dieser Seite wird beschrieben, wie benutzerdefinierte Routen mit den nächsten Hops von Cloud VPN-Tunneln in Google Cloud funktionieren.

Hintergrundinformationen zu Google Cloud-Routen, einschließlich der Anwendbarkeit und Reihenfolge der Routen und Parameter für statische Routen, finden Sie in der Routenübersicht zu Virtual Private Cloud (VPC).

Routentypen

Ein Cloud VPN-Tunnel kann der nächste Hop für eine benutzerdefinierte Route in Ihrem VPC-Netzwerk sein. Jede benutzerdefinierte Route mit einem Cloud-VPN-Tunnel für den nächsten Hop definiert einen Pfad für ausgehenden Traffic für Pakete, die Ihr VPC-Netzwerk verlassen:

Ein Cloud Router verwaltet immer einen klassischen VPN-Tunnel, der dynamisches Routing oder einen HA VPN-Tunnel verwendet. Dieser Dienst empfängt BGP-Advertising von und sendet BGP-Nachrichten an ein Peer-VPN-Gateway. Cloud Router erstellt und entfernt in Ihrem VPC-Netzwerk automatisch benutzerdefinierte dynamische Routen. Dies sind die Routen mit Zielen in einem Peer-Netzwerk. Außerdem werden Routen zu einem Peer-Netzwerk beworben. Dies sind Routen zu den IP-Bereichen von Subnetzen in Ihrem VPC-Netzwerk oder zu benutzerdefinierten Zielen, die Sie in einer Cloud Router-Konfiguration angeben. Mit dem dynamischen Routingmodus Ihres VPC-Netzwerks wird die Gruppe von Routen gesteuert, die von Cloud Router importiert und exportiert werden.
Ein richtlinienbasierter oder routenbasierter klassischer VPN-Tunnel verwendet das statische Routing. Wenn Sie mit der Google Cloud Console einen dieser Tunnel erstellen, erstellt Google Cloud automatisch benutzerdefinierte statische Routen basierend auf den Remote-IP-Bereichen, die Sie in der Cloud VPN-Konfiguration angeben. Wenn Sie einen dieser Tunnel mit der Google Cloud-CLI erstellen, müssen Sie die statischen Routen, die den Tunnel als nächsten Hop verwenden manuell erstellen.

Beispielszenarien

Google Cloud folgt bei der Auswahl des nächsten Hops, an den ein Paket gesendet werden soll, einer klar definierten Anwendbarkeit und Reihenfolge. Die folgenden Beispiele zeigen gängige Interaktionen zwischen Routen und Cloud VPN.

Interaktion mit Subnetzrouten

Die folgende Tabelle zeigt, wie Subnetzrouten und benutzerdefinierte Routen interagieren. Jede Zeile stellt einen möglichen IP-Bereich eines Subnetzes in einem VPC-Netzwerk dar. Die lokalen Bereiche sind 10.2.0.0/16 für IPv4 und fd20:a:b:c::/64 für IPv6.

IPv6-Traffic wird nur von HA VPN-Gateways unterstützt, die mit den Dual-Stack-Typen IPv4 und IPv6 konfiguriert sind.

VPC-Netzwerk	Cloud VPN-Tunnelrouting
IP-Bereich des Google Cloud-Subnetzes	Nur statisches (richtlinienbasiertes, routenbasiertes) klassisches VPN	Dynamisches (BGP) klassisches VPN oder HA VPN
`10.2.0.0/16` Entspricht dem lokalen IP-Bereich	In Google Cloud können Sie keine benutzerdefinierte statische Route erstellen, deren Ziel `10.2.0.0/16` ist und deren nächster Hop ein Cloud VPN-Tunnel ist.	Der mit dem Tunnel verknüpfte Cloud Router ignoriert alle beworbenen Routen mit dem Zielort `10.2.0.0/16`. Traffic für `10.2.0.0/16` verbleibt in Ihrem VPC-Netzwerk.
`fd20:a:b:c::/64` Entspricht dem lokalen IP-Bereich	Klassisches VPN unterstützt IPv6 nicht.	Der mit dem Tunnel verknüpfte Cloud Router ignoriert alle beworbenen Routen mit dem Zielort `fd20:a:b:c::/64`. Traffic für `fd20:a:b:c::/64` verbleibt in Ihrem VPC-Netzwerk.
`10.0.0.0/8` Größer als der lokale IP-Bereich (kleinere Subnetzmaske)	In Google Cloud können Sie keine benutzerdefinierte statische Route erstellen, deren Ziel `10.2.0.0/16` ist und deren nächster Hop ein Cloud VPN-Tunnel ist.	Der mit dem Tunnel verknüpfte Cloud Router ignoriert alle beworbenen Routen, deren Zieladressen mit `10.0.0.0/8`übereinstimmen oder dort hineinpasst, einschließlich `10.2.0.0/16`. Traffic für `10.0.0.0/8` verbleibt in Ihrem VPC-Netzwerk.
`fd20:a:b::/48` Größer als der lokale IP-Bereich (kleinere Subnetzmaske)	Klassisches VPN unterstützt IPv6 nicht.	Der mit dem Tunnel verknüpfte Cloud Router ignoriert alle beworbenen Routen, deren Zieladressen mit `fd20:a:b::/48`übereinstimmen oder dort hineinpasst, einschließlich `fd20:a:b:c::/64`. Traffic für `fd20:a:b::/48` verbleibt in Ihrem VPC-Netzwerk.
`10.2.99.0/24` Kleiner als der lokale IP-Bereich (längere Subnetzmaske)	Mit Google Cloud können Sie eine benutzerdefinierte statische Route mit dem Ziel `10.2.0.0/16` und einen Cloud VPN-Tunnel für den nächsten Hop erstellen. Der Traffic zu IP-Adressen in `10.2.99.0/24` verbleibt jedoch in Ihrem VPC-Netzwerk.	Der mit dem Tunnel verknüpfte Cloud Router akzeptiert eine beworbene Route mit dem Ziel `10.2.0.0/16`. Der Traffic zu IP-Adressen in `10.2.99.0/24` verbleibt jedoch in Ihrem VPC-Netzwerk.
`fd20:a:b:c::/80` Kleiner als der lokale IP-Bereich (längere Subnetzmaske)	Klassisches VPN unterstützt IPv6 nicht.	Der mit dem Tunnel verknüpfte Cloud Router akzeptiert eine beworbene Route mit dem Ziel `fd20:a:b:c::/64`. Der Traffic zu IP-Adressen in `fd20:a:b:c::/80` verbleibt jedoch in Ihrem VPC-Netzwerk.

Wenn Tunnel nicht erreichbar sind

Dynamisches Routing (mit BGP)

Wenn ein klassischer VPN-Tunnel mit dynamischem Routing oder ein HA VPN-Tunnel ausfällt, entfernt der Cloud Router die erkannten Routen automatisch. Wie lange es dauert, die Fehler zu erkennen, hängt davon ab, ob Bidirectional Forwarding Detection (BFD) aktiviert ist. Wenn BFD aktiviert ist, erfolgt die Erkennung, wenn der BGP-Holddown-Timer abläuft. Andernfalls erfolgt die Erkennung in weniger als 60 Sekunden. Die erkannten Routen können bei der Wiederherstellung des Tunnels wieder hinzugefügt werden.

Dieser Vorgang läuft vollautomatisch ab, kann aber dennoch zu Paketverlusten führen, während der Cloud Router die betroffenen Routen entfernt.

Statisches Routing

Google Cloud betrachtet einen Cloud VPN-Tunnel als gültigen nächsten Hop, der keine IKE-Sicherheitsverknüpfung (SA) eingerichtet hat. Wenn ein Cloud-VPN-Tunnel eine IKE SA eingerichtet hat, betrachtet Google Cloud diese als betriebsbereit. Ein funktionierender Cloud VPN-Tunnel leitet nur Traffic weiter, wenn er gemäß der Routingreihenfolge als nächster Hop ausgewählt ist. Stattdessen wird der nächste Hop für eine andere Route mit einem spezifischeren Ziel oder mit einer höheren Priorität verwendet.

Die folgenden Szenarien veranschaulichen das erwartete Verhalten:

Wenn Sie mehrere benutzerdefinierte statische Routen mit jeweils einem anderen Cloud-VPN-Tunnel für denselben Zielort haben, berücksichtigt Google Cloud nur die Tunnel, die über IKE-SAs verfügen (Phase 1). Nicht verfügbare Tunnel, d. h. die keine gültigen IKE-SAs haben, werden ignoriert, bevor die Routenpriorität berücksichtigt wird.

Angenommen, Sie haben drei benutzerdefinierte statische Routen für das Ziel 192.168.168.0/24: eine mit Priorität 10, deren Cloud VPN-Tunnel für den nächsten Hop ausgefallen ist, eine zweite mit Priorität 20, deren Tunnel für den nächsten Hop aktiv ist, und eine dritte mit Priorität 30, deren Tunnel für den nächsten Hop ebenfalls aktiv ist. Google Cloud sendet Traffic an den zweiten nächsten Hop, obwohl seine Route eine niedrigere Priorität hat als die Route, deren nächster Hop ausgefallen ist. Wenn der erste Tunnel wiederhergestellt wird, betrachtet Google Cloud ihn als gültigen nächsten Hop und verwendet stattdessen diese Route.
Traffic wird verworfen, wenn alle Cloud VPN-Tunnel ausgefallen sind, die als nächste Hops für benutzerdefinierte statische Routen mit demselben Ziel dienen. Der Traffic wird verworfen, selbst wenn eine benutzerdefinierte statische Route für einen breiteren Zielbereich mit einem betriebsbereiten Tunnel für den nächsten Hop existiert.

Angenommen, Sie haben eine benutzerdefinierte statische Route für 192.168.168.0/24, deren Cloud VPN-Tunnel für den nächsten Hop ausgefallen ist (keine gültige IKE-SA hat). Selbst wenn Sie eine Route für 192.168.0.0/16 haben, deren nächster Hop ein einsatzfähiger Cloud-VPN-Tunnel ist, wird der Traffic auf 192.168.168.0/24 verworfen. Dies liegt daran, dass Google Cloud immer Routen mit den spezifischsten Zielen auswählt.

Wenn der Traffic von einem Cloud-VPN-Tunnel mit dem nächsten Hop zu einem anderen Switch wechselt, sollten Sie dennoch Paketverluste erwarten. Inaktive Pakete werden möglicherweise entfernt und müssen noch einmal gesendet werden.

ECMP über Tunnel

Wenn sowohl für dynamisches als auch für statisches Routing mehr als eine benutzerdefinierte Route für dasselbe Ziel vorhanden ist und dieselbe Priorität und einen aktiven (von IKE SA eingerichteten) Next-Hop-Tunnel hat, verwendet Google Cloud ECMP-Routing (equal-cost multi-path), um Pakete auf die Tunnel zu verteilen.

Diese Methode des Lastenausgleichs basiert auf einem Hash. Dadurch verwenden alle Pakete aus demselben Datenfluss denselben Tunnel, solange dieser aktiv ist.

Sie können das ECMP-Verhalten testen. Verwenden Sie dazu iperf3, um mehrere gleichzeitige TCP-Streams, idealerweise von mehreren Google Cloud-VM-Instanzen, über Cloud VPN-Tunnel zu senden. Wenn Sie das ECMP-Verhalten prüfen müssen, verwenden Sie ICMP (ping) nicht für Tests. Ein ping-Test von einer VM-Instanz reicht nicht aus, um ECMP-basierten ausgehenden Traffic über Cloud VPN-Tunnel zu testen, da nur ein Tunnel ausgewählt wird, wenn Sie eine feste Quelle und ein festes Ziel haben. ICMP hat kein Konzept für Ports und ist ein festes Protokoll, daher wird der Hash nur aus zwei Informationen berechnet: der Quell- und der Zieladresse (ein Zwei-Tupel-Hash).

Nächste Schritte

Weitere Informationen zu den grundlegenden Konzepten von Cloud VPN finden Sie unter Cloud VPN – Übersicht.
Informationen zur Behebung häufiger Probleme bei der Verwendung von Cloud VPN finden Sie unter Fehlerbehebung.