Routenübersicht

Google Cloud-Routen definieren die Pfade, die der Netzwerktraffic von einer VM-Instanz zu anderen Zielen zurücklegt. Diese Ziele können sich innerhalb Ihres Virtual Private Cloud-Netzwerks (VPC) von Google Cloud befinden, beispielsweise in einer anderen VM oder außerhalb davon.

In einem VPC-Netzwerk besteht eine Route aus einem einzelnen Ziel (CIDR) und einem einzelnen nächsten Hop. Wenn eine Instanz in einem VPC-Netzwerk ein Paket sendet, liefert Google Cloud das Paket an den nächsten Hop der Route, wenn die Zieladresse des Pakets im Zielbereich der Route liegt.

Diese Seite bietet einen Überblick über die Funktionsweise von Routen in Google Cloud.

Routing in Google Cloud

Jedes VPC-Netzwerk verwendet einen skalierbaren, verteilten virtuellen Routingmechanismus. Dem Netzwerk ist kein physisches Gerät zugewiesen. Einige Routen können selektiv angewendet werden, aber die Routingtabelle für ein VPC-Netzwerk wird auf VPC-Netzwerkebene definiert.

Jede VM-Instanz hat einen Controller, der über alle anwendbaren Routen aus der Routingtabelle des Netzwerks informiert wird. Jedes Paket, das eine VM verlässt, wird auf Basis einer Routingreihenfolge an den entsprechenden nächsten Hop einer anwendbaren Route zugestellt. Wenn Sie eine Route hinzufügen oder löschen, wird der Satz von Änderungen nach dem Eventual Consistency-Modell an die VM-Controller weitergegeben.

Routentypen

VPC-Netzwerke können vom System generierte Routen oder benutzerdefinierte Routen umfassen.

In der folgenden Tabelle sind vom System generierte Routen zusammengefasst. Sie werden automatisch hinzugefügt oder aktualisiert, wenn Sie ein VPC-Netzwerk erstellen, ein Subnetz hinzufügen, den primären IP-Bereich eines Subnetzes erweitern oder den sekundären IP-Bereich eines Subnetzes bearbeiten. Sie gelten für alle Instanzen im VPC-Netzwerk.

Vom System generierte Routen
Typ Ziel Nächster Hop Entfernbar
Standardroute 0.0.0.0/0 default-internet-gateway Ja
Subnetzroute Primäre und sekundäre Subnetz-IP-Bereiche
VPC-Netzwerk, das Pakete an VMs in seinen Subnetzen weiterleitet Nur wenn das Subnetz gelöscht wird oder wenn Sie die sekundären IP-Bereiche des Subnetzes ändern

In der folgenden Tabelle sind benutzerdefinierte Routen zusammengefasst, die Sie direkt oder mithilfe von Cloud Router erstellen und verwalten.

Benutzerdefinierte Routen
Typ Ziel Nächster Hop Entfernbar Gilt für
Statische Route • IP-Bereich, der sich mit keinem Subnetz-IP-Bereich teilweise oder vollständig überschneidet
• IP-Bereich ist breiter als der Subnetz-IP-Bereich
Eine der folgenden Optionen:
• Instanz nach Name
• Instanz nach IP-Adresse
• Cloud VPN-Tunnel
Ja Eine von zwei Möglichkeiten:
• Alle Instanzen im Netzwerk
• Bestimmte Instanzen im Netzwerk, die mit einem Netzwerk-Tag gekennzeichnet sind, falls die Route durch ein Netzwerk-Tag zugewiesen werden kann
Dynamische Route • IP-Bereich, der sich mit keinem Subnetz-IP-Bereich teilweise oder vollständig überschneidet
• IP-Bereich ist breiter als der Subnetz-IP-Bereich
IP-Adresse des BGP-Peers des Cloud Routers Nur von einem Cloud Router, wenn er die Route nicht mehr von seinem BGP-Peer erhält • Instanzen in derselben Region wie der Cloud Router, wenn sich das VPC-Netzwerk im Modus für regionales dynamisches Routing befindet
• Alle Instanzen, wenn sich das VPC-Netzwerk im Modus für globales dynamisches Routing befindet

Standardroute

Wenn Sie ein VPC-Netzwerk anlegen, erstellt Google Cloud eine vom System generierte Standardroute. Diese Route dient zwei Zwecken:

  • Sie definiert den Pfad aus dem VPC-Netzwerk heraus, einschließlich des Pfads zum Internet. Neben dieser Route müssen Instanzen zusätzliche Anforderungen erfüllen, wenn sie Internetzugang benötigen.

  • Sie gibt den Standardpfad für den privaten Google-Zugriff an.

Die vom System generierte Standardroute hat die Priorität 1000. Da ihr Ziel unter den möglichen Zielen das umfassendste ist (0.0.0.0/0), wird sie von Google Cloud nur dann verwendet, wenn für ein Paket keine Route mit einem spezifischeren Ziel gilt. Weitere Informationen dazu, wie mithilfe von Zielspezifität und Routenpriorität eine Route ausgewählt wird, finden Sie unter Routingreihenfolge.

Sie können die Standardroute löschen, wenn Sie Ihr Netzwerk vollständig vom Internet isolieren möchten oder wenn Sie die Standardroute durch eine benutzerdefinierte Route ersetzen müssen:

  • Sie können die Standardroute durch eine benutzerdefinierte statische oder dynamische Route ersetzen, wenn Sie Internettraffic an einen anderen nächsten Hop weiterleiten möchten. Sie lässt sich beispielsweise durch eine benutzerdefinierte statische Route ersetzen, deren nächster Hop ein Cloud VPN-Tunnel oder eine andere Instanz wie ein Proxyserver ist.

  • Wenn Sie die Standardroute entfernen und nicht ersetzen, werden Pakete gelöscht, deren Ziel-IP-Bereiche nicht von anderen Routen abgedeckt werden.

Subnetzrouten

Subnetzrouten sind vom System generierte Routen, die Pfade zu jedem Subnetz im VPC-Netzwerk definieren.

Jedes Subnetz hat mindestens eine Subnetzroute, deren Ziel dem primären IP-Bereich des Subnetzes entspricht. Wenn das Subnetz sekundäre IP-Bereiche hat, erstellt Google Cloud für jeden sekundären Bereich eine Subnetzroute mit einem entsprechenden Ziel. Weitere Informationen zu Subnetz-IP-Bereichen finden Sie unter Netzwerke und Subnetze.

Keine andere Route darf ein Ziel haben, das mit dem Ziel einer Subnetzroute übereinstimmt oder spezifischer als dieses Ziel ist. Sie können aber eine benutzerdefinierte Route mit einem breiteren Zielbereich erstellen, der den Zielbereich der Subnetzroute enthält.

Bei Überlappung des IP-Bereichs gilt Folgendes: Da Google Cloud die Zielspezifität als erstes Kriterium für die Routingreihenfolge verwendet, ist die Subnetzroute immer der bevorzugte nächste Hop für Pakete, deren Ziele in ihren Zielbereich fallen. Dies gilt auch dann, wenn eine andere Route, deren Ziel das Ziel der Subnetzroute enthält, eine höhere Routenpriorität hat.

In den folgenden Punkten wird beschrieben, wie Subnetzrouten erstellt und entfernt werden:

  • Beim Erstellen eines Subnetzes wird auch eine entsprechende Subnetzroute für den primären IP-Bereich des Subnetzes erstellt.

    • Wenn Sie einem Subnetz einen sekundären IP-Bereich hinzufügen, wird eine entsprechende Subnetzroute für diesen sekundären Bereich erstellt.
  • VPC-Netzwerke im automatischen Modus erstellen eine Subnetzroute für die primären IP-Bereiche von jedem automatisch erstellten Subnetz. Sie können diese Subnetze nur dann löschen, wenn Sie den Modus des VPC-Netzwerks von automatisch in benutzerdefiniert ändern.

  • Sie können eine Subnetzroute nur löschen, wenn Sie das Subnetz ändern oder löschen:

    • Wenn Sie einen sekundären Bereich aus einem Subnetz entfernen, wird die Subnetzroute für diesen sekundären Bereich automatisch gelöscht.

    • Wenn Sie ein Subnetz löschen, werden alle Subnetzrouten für primäre und sekundäre Bereiche automatisch gelöscht. Sie können die Subnetzroute für den primären Bereich des Subnetzes nicht auf andere Weise löschen.

  • Wenn Netzwerke über VPC-Netzwerk-Peering verbunden sind, werden Subnetzrouten von einem Netzwerk in das andere Netzwerk importiert und umgekehrt.

    Google Cloud tauscht Subnetzrouten, die privat wiederverwendete öffentliche IP-Adressen verwenden, nicht automatisch aus. Die Subnetzrouten werden exportiert, aber Peer-Netzwerke müssen sie explizit importieren. Alle anderen Subnetz-IP-Bereiche werden automatisch ausgetauscht.

    • Subnetzrouten, die automatisch durch Subnetze in Peering-Netzwerken ausgetauscht werden, können nur entfernt werden, wenn Sie die Peering-Beziehung aufheben. In diesem Fall werden alle importierten Subnetzrouten aus dem anderen Netzwerk automatisch entfernt.

Firewallregeln können die Kommunikation zwischen Instanzen blockieren. Weitere Informationen zur Kommunikation zwischen Instanzen finden Sie unter Kommunikation im Netzwerk.

Benutzerdefinierte Routen

Benutzerdefinierte Routen sind entweder statische Routen, die Sie manuell erstellen, oder dynamische Routen, die automatisch von einem oder mehreren Ihrer Cloud Router verwaltet werden.

Ziele für benutzerdefinierte Routen dürfen weder mit einer Subnetzroute im Netzwerk übereinstimmen noch spezifischer als diese sein.

Bei Verwendung eines VPC-Netzwerks im automatischen Modus dürfen Sie keine Ziele verwenden, die in den CIDR-Block 10.128.0.0/9 fallen, da dieser Block den aktuellen und zukünftigen Adressraum für Subnetzrouten definiert. Weitere Informationen finden Sie unter IP-Bereiche im automatischen Modus.

Statische Routen mit Zielen innerhalb von 10.128.0.0/9 können in einem VPC-Netzwerk im automatischen Modus jederzeit deaktiviert werden. Dies kann passieren, wenn eine neue Google Cloud-Region verfügbar und ein neues Subnetz automatisch erstellt wird (zusammen mit seiner Subnetzroute). Weitere Informationen finden Sie unter Überlegungen zu VPC-Netzwerken im automatischen Modus.

Statische Routen

Statische Routen können jeden beliebigen nächsten Hop für statische Routen verwenden. Zum Erstellen statischer Routen gibt es zwei Möglichkeiten:

  • Sie können sie manuell erstellen.

  • Wenn Sie mit der Google Cloud Console einen Cloud VPN-Tunnel erstellen, der richtlinienbasiertes Routing oder ein routenbasiertes VPN verwendet, werden statische Routen für die Remote-Trafficauswahl für Sie erstellt. Weitere Informationen finden Sie unter Cloud-VPN-Netzwerke und Tunnelrouting.

Weitere Informationen finden Sie unter Parameter für statische Routen.

Dynamische Routen

Dynamische Routen werden von einem oder mehreren Cloud Routern verwaltet. Ihre Ziele stellen immer IP-Bereiche außerhalb Ihres VPC-Netzwerks dar und ihre nächsten Hops sind immer BGP-Peer-Adressen. Ein Cloud Router kann dynamische Routen für Folgendes verwalten:

Anwendbarkeit und Reihenfolge

Anwendbare Routen

Jede Instanz hat eine Reihe von anwendbaren Routen, bei denen es sich um eine Teilmenge aller Routen im VPC-Netzwerk handelt. Anwendbare Routen sind die möglichen Pfade für ausgehenden Traffic, die ein Paket verwenden kann, wenn es von der Instanz weitergeleitet wird.

  • Vom System generierte Routen gelten für alle Instanzen in einem VPC-Netzwerk. Der Umfang der Instanzen, für die Subnetzrouten gelten, kann nicht geändert werden. Sie können jedoch die Standardroute ersetzen.

  • Benutzerdefinierte statische Routen gelten für alle Instanzen oder bestimmte Instanzen. Statische Routen mit einem Tag-Attribut gelten für Instanzen, die ein entsprechendes Netzwerk-Tag haben. Wenn die Route kein Netzwerk-Tag hat, gilt die Route für alle Instanzen im Netzwerk.

    • Eine benutzerdefinierte statische Route, deren nächster Hop eine VM-Instanz ist, bleibt immer gültig, auch wenn die VM des nächsten Hop gelöscht oder ausgeschaltet wird oder nicht ordnungsgemäß funktioniert. Weitere Informationen finden Sie unter Instanzen als nächste Hops.

    • Wenn ein Cloud VPN-Tunnel der nächste Hop einer benutzerdefinierten statischen Route ist, ist diese immer gültig, wenn der Tunnel aktiv ist. Weitere Informationen zur Behandlung nicht erreichbarer Tunnel durch Google Cloud finden Sie in der Cloud VPN-Dokumentation unter Wenn Tunnel nicht erreichbar sind.

  • Dynamische Routen gelten für Instanzen, die auf dem Modus für dynamisches Routing des VPC-Netzwerks basieren. Wenn sich das VPC-Netzwerk im Modus für regionales dynamisches Routing befindet, wenden alle Cloud Router Routen an, die sie in ihren jeweiligen Regionen kennen. Befindet sich das Netzwerk im Modus für globales dynamisches Routing, wenden alle Cloud Router Routen an, die sie im gesamten Netzwerk kennen.

    • Cloud Router verwirft automatisch erlernte benutzerdefinierte dynamische Routen, die nicht erreichbaren nächsten Hops zugeordnet sind (Cloud VPN-Tunnel, die dynamisches Routing oder Cloud Interconnect nutzen). Je nach Netzwerk kann das Entfernen einer dynamischen Route, deren nächster Hop nicht erreichbar ist, durch Cloud Router bis zu 40 Sekunden dauern.
  • Bei Traffic mit Load-Balancing können die anwendbaren Routen von außerhalb Ihres VPC-Netzwerks stammen. Weitere Informationen finden Sie unter Load-Balancer-Rückgabepfade.

Routingreihenfolge

Wenn eine Instanz ein Paket sendet, versucht Google Cloud, eine Route aus der Menge der anwendbaren Routen gemäß der folgenden Routingreihenfolge auszuwählen.

  1. Subnetzrouten werden zuerst berücksichtigt, da Google Cloud verlangt, dass Subnetzrouten die spezifischsten Ziele haben, die den IP-Adressbereichen ihrer jeweiligen Subnetze entsprechen. Subnetzrouten sind Routen für die primären und sekundären Subnetz-IP-Adressbereiche der einzelnen Subnetze in Ihrem VPC-Netzwerk und die primären und sekundären Subnetz-IP-Adressbereiche von Subnetzen in Peering-Netzwerken. Wenn das Ziel eines Pakets im Ziel einer Subnetzroute enthalten ist, wird das Paket an dieses Google Cloud-Subnetz gesendet. Subnetzrouten können nicht durch andere Routentypen überschrieben werden.

    • Mit Google Cloud können Sie keine benutzerdefinierte statische Route erstellen, deren Ziel dem einer Subnetzroute entspricht oder spezifischer ist.

    • Wenn eine statische Route dieselbe Präfixlänge wie eine dynamische Route hat, hat die statische Route eine höhere Priorität als die dynamische Route des Cloud Routers. Eine statische Route mit demselben Präfix und Routenmesswert einer dynamischen Route hat immer eine höhere Priorität als die dynamische Route, sodass alle in Konflikt stehenden dynamischen Routen ignoriert werden.

    • Bei benutzerdefinierten dynamischen Routen ignoriert Cloud Router Routen zu anderen Netzwerken, die von einem Cloud Router erhalten wurden, falls das Ziel der erhaltenen Route dem einer Subnetzroute entspricht oder spezifischer ist.

    • Wenn Sie VPC-Netzwerke über VPC-Netzwerk-Peering verbinden, nutzen die Netzwerke alle Subnetzrouten gemeinsam. Google Cloud priorisiert Subnetzrouten in Peering-Netzwerken so wie die eigenen Subnetzrouten des lokalen Netzwerks: Subnetzrouten in Peer-Netzwerken müssen die spezifischsten Ziele haben.

  2. Wenn das Paket nicht im Ziel einer Subnetzroute enthalten ist, sucht Google Cloud nach einer benutzerdefinierten Route mit dem spezifischsten Ziel.

    • Angenommen, das Ziel eines Pakets, das eine VM verlässt, ist 10.240.1.4 und es gibt zwei Routen mit unterschiedlichen Zielen: 10.240.1.0/24 und 10.240.0.0/16. Da 10.240.1.0/24 das spezifischste Ziel für 10.240.1.4 ist, bestimmt die Route mit dem Ziel 10.240.1.0/24 den nächsten Hop für das Paket.
  3. Wenn mehrere benutzerdefinierte Routen das gleiche, spezifischste Ziel haben, nutzt Google Cloud folgendes Verfahren, um aus den Routenkandidaten eine Route auszuwählen: Routenkandidaten sind benutzerdefinierte Routen (statische oder dynamische Routen) mit dem gleichen, spezifischsten Ziel.

    1. Wenn Ihr VPC-Netzwerk über VPC-Netzwerk-Peering mit anderen Netzwerken verbunden ist, werden in Google Cloud zuerst die Routenkandidaten eingeschränkt, die alle aus einem einzigen VPC-Netzwerk stammen:

      • Wenn in ihrem lokalen VPC-Netzwerk mindestens ein Routenkandidat definiert ist, nutzt Google Cloud den lokalen Routenkandidaten und ignoriert alle Kandidaten aus Peer-Netzwerken.

      • Wenn die Routenkandidaten aus mehreren Peer-Netzwerken stammen, wählt Google Cloud ein Peer-Netzwerk aus, in denen mindestens eine Kandidatenroute definiert ist, und ignoriert Kandidatenrouten aus anderen Peer-Netzwerken. Google Cloud verwendet eine nicht deterministische Methode, um das Peer-Netzwerk unabhängig von der Priorität der jeweiligen Route auszuwählen. Wenn Sie Netzwerke zur Peering-Gruppe hinzufügen oder daraus entfernen, wählt Google Cloud möglicherweise Kandidatenrouten aus einem anderen Peering-Netzwerk aus.

      Anschließend wählt Google Cloud eine Route aus den Kandidatenrouten eines einzigen Netzwerks aus.

    2. Wenn eine Route mit der höchsten Priorität verfügbar ist, sendet Google Cloud das Paket an den nächsten Hop.

    3. Wenn mehrere Routen die höchste Priorität haben, wählt Google Cloud eine Route nach dem Kriterium aus, ob es sich um eine statische oder eine dynamische Route handelt, sowie anhand des Werts des nächsten Hops. Google Cloud verwendet die folgende Reihenfolge (Präferenz in absteigender Reihenfolge):

      1. Google Cloud wählt eine benutzerdefinierte statische Route aus, deren nächster Hop "Nächste Hop-Instanz", "Nächste Hop-IP-Adresse" oder "Nächster Hop-VPN-Tunnel" ist.

      2. Google Cloud wählt eine benutzerdefinierte dynamische Route aus, die von einem Cloud Router beworben wird.

      3. Google Cloud wählt eine benutzerdefinierte statische Route aus, deren nächster Hop "Interner TCP/UDP-Load-Balancer als nächster Hop" ist.

      4. Google Cloud wählt eine benutzerdefinierte statische Route mithilfe von "Standard-Internetgateway als nächster Hop" aus.

    4. Wenn keine einzelne Route ausgewählt werden kann, verteilt Google Cloud den Traffic auf die nächsten Hops der Routenkandidaten. Dabei wird ein 5-Tupel-Hash für Affinität verwendet und ein ECMP-Routingdesign implementiert. Der Hash wird aus dem Protokoll, den Quell- und Ziel-IP-Adressen sowie den Quell- und Zielports des gesendeten Pakets berechnet. Diese Berechnung wird für jedes gesendete Paket basierend auf der Anzahl der verfügbaren Routenkandidaten durchgeführt. Wenn sich die Anzahl der verfügbaren Routenkandidaten ändert, kann das Paket aufgrund des Hashs an einen anderen nächsten Hop weitergeleitet werden.

  4. Wenn kein anwendbares Ziel gefunden wird, löscht Google Cloud das Paket und meldet, dass ein Problem mit dem ICMP-Ziel vorliegt oder das Netzwerk nicht erreichbar ist.

Spezielle Rückgabepfade

VPC-Netzwerke haben spezielle Routen für bestimmte Dienste. Diese Routen werden außerhalb Ihres VPC-Netzwerks im Produktionsnetzwerk von Google definiert. Sie tauchen nicht in der Routingtabelle Ihres VPC-Netzwerks auf. Sie können sie nicht entfernen oder überschreiben, auch wenn Sie eine Standardroute in Ihrem VPC-Netzwerk löschen oder ersetzen. Sie können jedoch den Traffic zu und von diesen Diensten mithilfe von Firewallregeln steuern.

Load-Balancer-Rückgabepfade

Wenn Sie einen der folgenden Google Cloud-Load-Balancer verwenden, setzt Google Cloud spezielle Routen für die Load-Balancer und die dazugehörigen Systemdiagnosen ein. Diese werden in den folgenden Abschnitten ausführlicher beschrieben.

Rückgabepfade für HTTP(S)-, SSL-Proxy- und TCP-Proxy-Load-Balancer

Bei diesen Load-Balancer-Typen dienen Google Front End-Systeme (GFE) als Proxys. Wenn ein Client eine Anfrage an den Load-Balancer sendet, beendet ein Proxy die TCP-Sitzung und öffnet eine neue TCP-Sitzung mit Ihrer Back-End-VM. Außerhalb Ihres VPC-Netzwerks definierte Routen erleichtern die Kommunikation von GFE-Proxys zu Ihren Back-End-VMs und von Ihren Back-End-VMs zu GFE-Proxys.

Weitere Informationen finden Sie auf den folgenden Seiten:

Rückgabepfade für Netzwerk-Load-Balancer

Wenn ein Client im Internet eine TCP- oder UDP-Anfrage über einen Netzwerk-Load-Balancer an eine Back-End-VM sendet, verwendet Google Cloud Routen außerhalb Ihres VPC-Netzwerks, um die Kommunikation vom Client zur Back-End-VM und von Ihrer Back-End-VM zum Client zu erleichtern.

Weitere Informationen finden Sie unter Netzwerk-Load-Balancing.

Systemdiagnosen für alle Load-Balancer-Typen

Pakete, die von Prüfsystemen der Google Cloud-Systemdiagnose gesendet werden, verfügen über Quellen gemäß den Prüfungs-IP-Bereichen und Firewallregeln. Routen, die die Kommunikation zwischen den Prüfsystemen der Google Cloud-Systemdiagnose und Ihren Back-End-VMs erleichtern, befinden sich außerhalb Ihres VPC-Netzwerks und können nicht entfernt werden. Ihr VPC-Netzwerk muss jedoch Firewall-Zulassungsregeln für eingehenden Traffic haben, um Traffic von diesen Systemen freizugeben.

IAP

Eine Route für 35.235.240.0/20 ist enthalten, um die TCP-Weiterleitung mit IAP zu unterstützen. Das Produktionsnetzwerk von Google akzeptiert keine Routen für 35.235.240.0/20 aus anderen Quellen im Internet.

Cloud DNS

Eine Route nach 35.199.192.0/19 unterstützt Verbindungen zu Weiterleitungszielen mit privatem Routing oder alternativen Nameservern mit privatem Routing. Das Produktionsnetzwerk von Google akzeptiert keine Routen für 35.199.192.0/19 aus anderen Quellen im Internet.

Parameter für statische Routen

Jede statische Route besteht aus folgenden Komponenten:

  • Name und Beschreibung. Diese Felder identifizieren die Route. Ein Name ist erforderlich, eine Beschreibung jedoch optional. Der Name jeder Route darf in Ihrem Projekt nur einmal vorkommen.

  • Netzwerk: Jede Route muss genau einem VPC-Netzwerk zugeordnet sein.

  • Zielbereich: Der Zielbereich ist ein einzelner IPv4-CIDR-Block, der die IP-Adressen von Systemen enthält, die eingehende Pakete empfangen. IPv6-Zielbereiche werden von Google Cloud nicht unterstützt. Ziele müssen in CIDR-Notation angegeben werden und das breiteste mögliche Ziel ist 0.0.0.0/0.

  • Priorität: Mit der Priorität wird festgelegt, welche Route verwendet werden soll, wenn mehrere Routen identische Ziele haben. Niedrigere Zahlen zeigen höhere Prioritäten an. Beispielsweise hat eine Route mit einem Prioritätswert von 100 eine höhere Priorität als eine Route mit einem Prioritätswert von 200. Höchste Routenpriorität hat die kleinste mögliche nichtnegative Ganzzahl. Da Null die kleinste mögliche nichtnegative Ganzzahl ist, hat sie die höchste Priorität.

  • Nächster Hop: Statische Routen können nächste Hops haben, die auf das Standard-Internetgateway, eine Google Cloud-Instanz oder einen Cloud VPN-Tunnel verweisen. Weitere Informationen finden Sie unter Nächste Hops für statische Routen.

  • Tags: Sie können eine Liste von Netzwerk-Tags angeben, sodass die Route nur für Instanzen gilt, die mindestens eines der aufgelisteten Tags haben. Wenn Sie keine Tags angeben, wendet Google Cloud die Route auf alle Instanzen im Netzwerk an.

Nächste Hops für statische Routen

Im Folgenden sind die gültigen nächsten Hops für statische Routen aufgeführt. Weitere Informationen zu den einzelnen Typen finden Sie in der Referenzdokumentation zu gcloud.

  • Nächstes Hop-Gateway (next-hop-gateway): Sie können ein Standard-Internetgateway angeben, um einen Pfad zu externen IP-Adressen zu definieren.

  • Nächste Hop-Instanz (next-hop-instance): Sie können Traffic zu einer vorhandenen Instanz in Google Cloud leiten, indem Sie ihren Namen und die Zone angeben. Der Traffic wird an die primäre interne IP-Adresse der Netzwerkschnittstelle der VM im VPC-Netzwerk geleitet, in dem Sie die Route definieren.

    • Wenn sich die primäre interne IP-Adresse der Netzwerkschnittstelle der Instanz im VPC-Netzwerk ändert, werden Routingtabellen in Google Cloud automatisch aktualisiert, sodass der Traffic weiterhin an diese VM unter ihrer neuen IP-Adresse gesendet wird.

    • Wenn die VM durch eine neue VM mit demselben Namen in derselben Zone ersetzt wird, wird die Routingtabelle des VPC-Netzwerks in Google Cloud automatisch aktualisiert, sodass der Traffic an die Ersatz-VM weitergeleitet wird.

    • Google Cloud prüft nur, dass eine nächste Hop-VM vorhanden ist, wenn Sie die Route erstellen. Ob die VM Pakete verarbeiten oder weiterleiten kann, wird nicht geprüft. Wird die VM gelöscht, aber nicht ersetzt, gilt die Route weiterhin, wodurch Pakete verloren gehen können. Weitere Informationen finden Sie unter Instanzen als nächste Hops.

  • Interner TCP/UDP-Load-Balancer als nächster Hop (next-hop-ilb): Beim internen TCP/UDP-Load-Balancing können Sie die IP-Adresse eines Load-Balancers als nächsten Hop verwenden, der den Traffic auf fehlerfreie Back-End-Instanzen verteilt. Sie können beispielsweise eine benutzerdefinierte statische Route mit internem TCP/UDP-Load-Balancer als nächsten Hop verwenden, um Traffic auf Back-End-VMs zu verteilen. Benutzerdefinierte statische Routen, die diesen nächsten Hop verwenden, lassen sich nicht durch Netzwerk-Tags bestimmten Instanzen zuweisen.

  • Nächste Hop-IP-Adresse (next-hop-address). Sie können eine interne IP-Adresse angeben, die einer Google Cloud-VM als nächster Hop zugewiesen ist.

    • Wenn Sie next-hop-address verwenden, leitet Google Cloud den Traffic an jede VM-Instanz weiter, die dieser IP-Adresse zugewiesen ist. Wird eine VM-Instanz durch eine andere Instanz ersetzt, die dieselbe IP-Adresse verwendet, wird der Traffic an die Ersatzinstanz geleitet, auch wenn diese einen anderen Namen hat. Wenn Sie einen nächsten Hop anhand des VM-Namens definieren möchten, verwenden Sie stattdessen die nächste Hop-Instanz.

    • Google Cloud prüft beim Erstellen der Route nur, ob die IP-Adresse ein gültiges Mitglied des primären oder sekundären IP-Bereichs eines Subnetzes ist. Es wird nicht bestätigt, dass eine Instanz für die IP-Adresse des nächsten Hops vorhanden ist. Wenn die nächste Hop-IP-Adresse keiner Instanz im Netzwerk zugewiesen ist, gilt die Route weiterhin, wodurch Pakete verloren gehen können. Weitere Informationen finden Sie unter Überlegungen zu Instanzen und Load-Balancern als nächste Hops.

    • Sie können keine beliebige IP-Adresse eines nächsten Hops angeben: Adressen außerhalb des IP-Adressbereichs eines Subnetzes in Ihrem VPC-Netzwerk sind nicht zulässig.

  • Nächster Hop-VPN-Tunnel (next-hop-vpn-tunnel). Bei Cloud VPN-Tunneln, die richtlinienbasiertes Routing und routenbasierte VPNs verwenden, können Sie Traffic an den VPN-Tunnel weiterleiten. Dazu erstellen Sie Routen, deren nächste Hops auf den Tunnel anhand seines Namens und seiner Region verweisen. Routen mit nächsten Hops, die auf nicht erreichbare Cloud VPN-Tunnel verweisen, werden von Google Cloud ignoriert. Weitere Beispiele zur Interaktion von Routen und Cloud VPN-Tunneln finden Sie auf der Seite Routingbeispiele für Cloud VPN.

Überlegungen zu Instanzen und Load-Balancern als nächste Hops

Instanzbasiertes Routing bezieht sich auf eine statische Route mit einer VM-Instanz als nächsten Hop (next-hop-instance oder next-hop-address).

Interner TCP/UDP-Load-Balancer als nächster Hop bezieht sich auf eine statische Route mit einem internen TCP/UDP-Load-Balancer als nächsten Hop (next-hop-ilb).

Wenn Sie das instanzbasierte Routing oder einen internen TCP/UDP-Load-Balancer als nächsten Hop konfigurieren, beachten Sie die folgenden Richtlinien:

  • Sie müssen die Back-End-VMs oder die nächste Hop-Instanz so konfigurieren, dass sie Pakete von anderen Quellen weiterleiten (can-ip-forward). Sie können die IP-Weiterleitung für einzelne VMs aktivieren, wenn Sie die jeweilige VM erstellen. Wenn die IP-Weiterleitung für VMs aktiviert werden soll, die automatisch im Rahmen einer verwalteten Instanzgruppe erstellt werden, müssen Sie die IP-Weiterleitung in der von der Instanzgruppe verwendeten Instanzvorlage aktivieren. Sie müssen diese Konfiguration zusätzlich zu jeder Betriebssystemkonfiguration vornehmen, die zum Weiterleiten von Paketen erforderlich ist.

  • Software, die auf der Back-End-VM oder der nächsten Hop-Instanz ausgeführt wird, muss entsprechend konfiguriert werden. Beispielsweise müssen VM-Appliances von Drittanbietern, die als Router oder Firewalls dienen, gemäß den Anweisungen des Herstellers konfiguriert werden.

  • Back-End-VMs oder die nächste Hop-Instanz müssen die erforderlichen Firewallregeln haben. Sie müssen Firewallregeln konfigurieren, die für die Pakete gelten, die weitergeleitet werden. Beachten Sie Folgendes:

    • Firewallregeln für eingehenden Traffic, die auf Instanzen mit Routingfunktionen angewendet werden, müssen die IP-Adressen der Quellen von weitergeleiteten Paketen enthalten. Die implizierte Regel zum Ablehnen von eingehendem Traffic blockiert alle eingehenden Pakete. Sie müssen also mindestens benutzerdefinierte Firewall-Zulassungsregeln für eingehenden Traffic erstellen.
    • Firewallregeln für ausgehenden Traffic, die auf Instanzen mit Routingfunktionen angewendet werden, müssen die IP-Adressen der Ziele von weitergeleiteten Paketen enthalten. Die implizierte Regel zum Zulassen von ausgehendem Traffic erlaubt dies, sofern sie nicht durch eine bestimmte von Ihnen erstellte Regel zum Ablehnen von ausgehendem Traffic überschrieben wird.
    • Berücksichtigen Sie beim Erstellen Ihrer Firewallregeln, ob die Back-End-VM oder die nächste Hop-Instanz Network Address Translation (NAT) ausführt.

    Weitere Informationen finden Sie unter Implizierte Firewallregeln.

Überlegungen speziell für nächste Hop-Instanzen

  • Wenn Sie eine Instanz als nächsten Hop verwenden (next-hop-instance oder next-hop-address), denken Sie daran, dass die Instanz eine zonale Ressource ist. Die Auswahl einer Zone impliziert, dass Sie eine Region ausgewählt haben. Entfernungen zwischen Regionen werden von Google Cloud nicht für Routen berücksichtigt, die eine nächste Hop-Instanz verwenden. Daher kann auch eine Route erstellt werden, die Traffic an einen nächsten Hop in einer anderen Region sendet. Dies erhöht die Kosten für ausgehenden Traffic und führt zu Netzwerklatenz.

  • Google Cloud führt nur beim Erstellen der Route eine der folgenden grundlegenden Validierungen durch:

    • Wenn Sie die next-hop-instance angeben, muss diese bereits vorhanden sein.
    • Wenn Sie die next-hop-address angeben, muss sich die IP-Adresse im primären oder sekundären IP-Bereich eines vorhandenen Subnetzes befinden.
  • Falls Sie beispielsweise eine Instanz entfernen oder ein Subnetz später löschen, betrachtet Google Cloud bei der Auswertung der entsprechenden Routen weiterhin jede Route, die diese Instanz verwendet, als möglichen nächsten Hop. Dadurch können abhängig von den anderen Routen in Ihrem Netzwerk einige oder alle Pakete für ein bestimmtes Ziel verworfen werden.

  • Wenn die Software einer VM-Instanz ausfällt (z. B. das VM-Betriebssystem oder der Prozess der VM zum Weiterleiten von Paketen), werden die an diese Instanz gerichteten Pakete verworfen. Für eine erhöhte Zuverlässigkeit sollten Sie stattdessen einen internen TCP/UDP-Load-Balancer als nächsten Hop verwenden. Für einen internen TCP/UDP-Load-Balancer ist eine konfigurierte Systemdiagnose erforderlich und diese Systemdiagnose bestimmt, wie neue Verbindungen weitergeleitet werden.

  • Das Deaktivieren einer Netzwerkschnittstelle durch Konfigurieren des Gastbetriebssystems der Instanz bewirkt nicht, dass Google Cloud diese Schnittstelle als nächsten Hop einer Route betrachtet.

Weitere Informationen

  • Informationen zum Erstellen und Verwalten von Routen finden Sie unter Routen verwenden.
  • Einen Überblick über Google Cloud VPC-Netzwerke erhalten Sie unter VPC-Netzwerke.
  • Anleitungen zum Erstellen, Ändern oder Löschen von VPC-Netzwerken finden Sie unter VPC-Netzwerke verwenden.