Routen

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 Google Cloud Virtual Private Cloud-Netzwerks (VPC) befinden, beispielsweise in einer anderen VM oder außerhalb davon.

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

Auf dieser Seite finden Sie 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

In den folgenden Tabellen wird zusammengefasst, wie Google Cloud Routen in VPC-Netzwerken kategorisiert.

Typ und Ziel Nächster Hop Hinweise
Richtlinienbasierte Routen: Richtlinienbasierte Routen werden vor allen anderen Routentypen ausgewertet.
Richtlinienbasierte Route
Richtlinienbasierte Routen können für Pakete basierend auf Quell-IP-Adresse, Ziel-IP-Adresse, Protokoll oder einer Kombination davon gelten.

Richtlinienbasierte Routen können für alle VMs im Netzwerk, für bestimmte durch ein Netzwerk-Tag ausgewählte VMs oder für Traffic gelten, der über VLAN-Anhänge für Cloud Interconnect (in nur einer Region oder in allen Regionen) in das VPC-Netzwerk eintritt.

Richtlinienbasierte Routen werden nie über VPC-Netzwerk-Peering ausgetauscht.
Subnetzrouten: Alle Subnetzroutentypen werden nach richtlinienbasierten Routen, aber vor benutzerdefinierten Routen ausgewertet.
Lokale Subnetzroute
Wird automatisch für jeden Subnetz-IP-Adressbereich erstellt 		VPC-Netzwerk

Wird von Google Cloudwährend Subnetzlebenszyklus-Ereignissen automatisch erstellt, aktualisiert und entfernt.

Lokale Subnetzrouten gelten für das gesamte VPC-Netzwerk.
Peering-Subnetzroute
Stellt einen Subnetz-IP-Adressbereich in einem anderen VPC-Netzwerk dar, das über VPC-Netzwerk-Peering verbunden ist 		Nächster Hop im Peer-VPC-Netzwerk

VPC-Netzwerk-Peering bietet Optionen für den Austausch von Subnetzrouten.

Wird von Google Cloudwährend Subnetzlebenszyklus-Ereignissen automatisch erstellt, aktualisiert und entfernt.

Importierte Peering-Subnetzrouten gelten für das gesamte VPC-Netzwerk.
Network Connectivity Center-Subnetzroute
Stellt einen IP-Adressbereich des Subnetzes in einem VPC-Spoke dar (ein anderes VPC-Netzwerk, das mit dem Network Connectivity Center-Hub verbunden ist) 		Network Connectivity Center-Hub

Network Connectivity Center-Spoke-Administratoren können den Export von Subnetzrouten ausschließen.

Wird von Google Cloudwährend Subnetzlebenszyklus-Ereignissen automatisch erstellt, aktualisiert und entfernt.

Importierte Network Connectivity Center-Subnetzrouten gelten für das gesamte VPC-Netzwerk.
Benutzerdefinierte Routen: Benutzerdefinierte Routen werden nach richtlinienbasierten Routen und nach Subnetzrouten ausgewertet.
Lokale statische Route
Unterstützt verschiedene Ziele 		Leitet Pakete an eine als nächster Hop dienende statische Route weiter Weitere Informationen zu jedem als nächster Hop dienenden statischen Route finden Sie unter:
Lokale dynamische Route
Ziele, die nicht mit Subnetzrouten oder statischen Routen in Konflikt stehen		 Peer einer BGP-Sitzung auf einem Cloud Router Routen werden automatisch basierend auf gelernten Routen von Cloud Routern in Ihrem VPC-Netzwerk hinzugefügt und entfernt.

Routen gelten für VMs entsprechend dem dynamischen Routingmodus des VPC-Netzwerks.
Statische Peering-Route, dynamische Peering-Route
Statische oder dynamische Routen in einem anderen VPC-Netzwerk, das über VPC-Netzwerk-Peering verbunden ist 		Nächster Hop im Peer-VPC-Netzwerk

VPC-Netzwerk-Peering bietet Optionen für den Austausch statischer Routen.

Importierte statische Peering-Routen gelten für das gesamte VPC-Netzwerk.

Das VPC-Netzwerk-Peering bietet Optionen für den Austausch dynamischer Routen.

Dynamische Peering-Routen gelten für eine oder alle Regionen des VPC-Netzwerk, je nach dem Modus für dynamisches Routing des VPC-Netzwerk, das die Routen exportiert.
Dynamische Network Connectivity Center-Route
Dynamische Routen, die aus Network Connectivity Center-Hybrid-Spokes in verschiedenen VPC-Netzwerken importiert werden 		Network Connectivity Center-Hub

Ein Network Connectivity Center-Hub kann sowohl VPC-Spokes als auch Hybrid-Spokes haben.

Dynamische Network Connectivity Center-Routen gelten für eine oder alle Regionen des VPC-Netzwerk, je nach dem Modus für dynamisches Routing des VPC-Netzwerk, das den Hybrid-Spoke enthält.
Vom System generierte Routen
Vom System generierte Standardrouten
0.0.0.0/0 für IPv4
::/0 für IPv6		 default-internet-gateway Gilt für das gesamte VPC-Netzwerk

Kann entfernt oder ersetzt werden

Subnetzrouten

Jedes Subnetz hat mindestens eine Subnetzroute für jeden IP-Adressbereich, der mit dem Subnetz verknüpft ist. Weitere Informationen zu Subnetz-IP-Bereichen finden Sie unter Subnetze.

Subnetzrouten

Ein VPC-Netzwerk kann die folgenden Arten von Subnetzrouten enthalten:

  • Subnetzrouten für Subnetze im selben VPC-Netzwerk, auch lokale Subnetzrouten genannt.
  • Network Connectivity Center-Subnetzrouten, die aus VPC-Spokes eines Network Connectivity Center-Hubs importiert werden.
  • Peering-Subnetzrouten, die aus Netzwerken importiert werden, die über VPC-Netzwerk-Peering verbunden sind.

Zielbereiche für alle Arten von Subnetzrouten müssen eindeutig sein. Weitere Informationen finden Sie hier:

Hybridsubnetzrouten

Lokale Subnetzrouten und Peering-Subnetzrouten können Hybrid-Subnetzrouten sein, wenn das entsprechende Subnetz als Hybrid-Subnetz konfiguriert ist.

Lebenszyklus von Subnetzrouten

Alle IP-Adressbereiche, die zu einem Subnetz gehören – primäre IPv4-Adressbereiche, sekundäre IPv4-Adressbereiche und IPv6-Adressbereiche – haben eine entsprechende Subnetzroute. Google Cloud erstellt und löscht Subnetzrouten in den folgenden Szenarien:

  • Sie nehmen eine Änderung an der Subnetzkonfiguration vor, z. B.:

    • Fügen Sie ein Subnetz hinzu oder löschen Sie es.
    • Primären IPv4-Bereich erweitern
    • Fügen Sie einen sekundären IPv4-Bereich hinzu oder löschen Sie ihn.
    • Fügen Sie einen IPv6-Bereich hinzu oder löschen Sie ihn.

  • Google Cloud fügt eine neue Region hinzu, wodurch automatisch ein neues Subnetz zu VPC-Netzwerken im automatischen Modus hinzugefügt wird. Informationen zu den IPv4-Adressbereichen für jedes Subnetz nach Region finden Sie unter IPv4-Bereiche im automatischen Modus.

Dynamische Routen

Cloud Router weisen das VPC-Netzwerk an, dynamische Routen anhand der empfangenen Border Gateway Protocol-Nachrichten (BGP), der anwendbaren BGP-Routenrichtlinien (Vorschau) und der von Ihnen konfigurierten benutzerdefinierten erkannten Cloud Router-Routen zu erstellen, zu aktualisieren und zu entfernen.

Dynamische Routen werden in einer oder allen Regionen erstellt, je nach dem Modus für dynamisches Routing und dem Modus für die Auswahl des besten Pfads des VPC-Netzwerks, das den Cloud Router enthält. Hier finden Sie weitere Informationen:

Der nächste Hop einer dynamischen Route kann eines der folgenden Elemente sein:

Wenn ein nächster Hop für eine dynamische Route nicht mehr zugänglich ist, weist der Cloud Router, der dessen BGP-Sitzung verwaltet, das VPC-Netzwerk an, die dynamische Route zu entfernen. Weitere Informationen finden Sie unter BGP-Zustandsänderungen.

Arten von dynamischen Routen

Ein VPC-Netzwerk kann die folgenden Arten von dynamischen Routen enthalten:

  • Dynamische Routen, die von Cloud Routern im selben VPC-Netzwerk erkannt werden, werden als lokale dynamische Routen bezeichnet.
  • Dynamische Peering-Routen, die mit benutzerdefiniertem Routenaustausch aus Netzwerken importiert werden, die über VPC-Netzwerk-Peering verbunden sind .
  • Dynamische Network Connectivity Center-Routen, die aus Hybrid-Spokes in verschiedenen VPC-Netzwerken eines Network Connectivity Center-Hubs importiert werden.

Google Cloud behebt Konflikte zwischen dynamischen Routen und Subnetzrouten, wie unter Interaktionen mit dynamischen Routen beschrieben.

Vom System generierte Standardrouten

Eine Standardroute hat das breitestmögliche Ziel: 0.0.0.0/0 für IPv4 und ::/0 für IPv6. Google Cloud only verwendet eine Standardroute, um ein Paket zuzustellen, wenn das Paket nicht mit einer spezifischeren Route in der Routingreihenfolge übereinstimmt.

Das Fehlen einer Standardroute führt nicht unbedingt dazu, dass Ihr Netzwerk vom Internet getrennt wird, da spezielle Routingpfade für externe Passthrough-Network Load Balancer und externe Protokollweiterleitung nicht von einer Standardroute abhängen.

Wenn Sie ein VPC-Netzwerk erstellen, fügtGoogle Cloud dem VPC-Netzwerk eine vom System generierte Standardroute (IPv4) hinzu. Die vom System generierte IPv4-Standardroute ist eine lokale statische Route mit dem Ziel 0.0.0.0/0 und dem nächsten Hop „Standard-Internetgateway“. Eine lokale statische Route mit dem Ziel 0.0.0.0/0 und dem nächsten Hop „Standard-Internetgateway“ bietet einen Pfad zu externen IPv4-Adressen, einschließlich IPv4-Adressen im Internet. In den folgenden Beispielressourcen wird dieser Pfad verwendet:

  • VMs mit externen IPv4-Adressen, die ihren Netzwerkschnittstellen zugewiesen sind, wenn die von ihnen gesendeten Pakete Quellen haben, die mit der primären internen IPv4-Adresse der Netzwerkschnittstelle übereinstimmen.
  • Ein öffentliches Cloud NAT-Gateway, das NAT-Dienste für Subnetze bereitstellt, die von VM-Netzwerkschnittstellen verwendet werden. Sowohl für NAT44 als auch für NAT64 sind öffentliche Cloud NAT-Gateways immer von einer lokalen statischen IPv4-Route abhängig, die den nächsten Hop des Standard-Internetgateways verwendet. Weitere Informationen dazu, welcher Traffic von öffentlichen Cloud NAT-Gateways übersetzt werden kann, finden Sie unter Allgemeine Spezifikationen.

Wenn Sie ein Subnetz mit einem externen IPv6-Adressbereich erstellen, fügtGoogle Cloud dem VPC-Netzwerk eine vom System generierte IPv6-Standardroute hinzu, falls noch keine vorhanden ist. Die vom System generierte IPv6-Standardroute ist eine lokale statische Route mit dem Ziel ::/0 und dem nächsten Hop „Standard-Internetgateway“. Eine lokale statische Route mit dem Ziel ::/0 und dem nächsten Hop „Standard-Internetgateway“ bietet einen Pfad zu externen IPv6-Adressen, einschließlich IPv6-Adressen im Internet. Dieser Pfad kann für Folgendes verwendet werden:

  • VMs mit /96 externen IPv6-Adressbereichen, die ihren Netzwerkschnittstellen zugewiesen sind, wenn die von ihnen gesendeten Pakete Quellen in diesem /96-Adressbereich haben.

Der Zugriff auf globale Google APIs hängt manchmal von einer lokalen IPv4- oder IPv6-Standardroute mit dem nächsten Hop des Standard-Internetgateways ab:

  • Wenn Sie über das Senden von Paketen an einen Private Service Connect-Endpunkt für globale Google APIs auf globale Google APIs und ‑Dienste zugreifen, ist für Ihr VPC-Netzwerk keine Standardroute mit dem Standard-Internetgateway als nächstem Hop erforderlich. Google Cloud fügt dem Endpunkt einen speziellen Routingpfad hinzu.

  • Wenn Sie über das Senden von Paketen an IPv4- oder IPv6-Adressen für die Standarddomains, die IPv4- oder IPv6-Adressen für private.googleapis.com oder die IPv4- oder IPv6-Adressen für restricted.googleapis.com auf globale Google APIs und ‑Dienste zugreifen, können Sie entweder Standard-IPv4- und ‑IPv6-Routen mit Standard-Internetgateway als nächster Hop verwenden oder IPv4- und IPv6-statische Routen mit spezifischeren Zielen und Standard-Internetgateway als nächster Hop erstellen und verwenden:

    • Wenn Ihre VMs nur interne IP-Adressen haben, lesen Sie den Hilfeartikel Routingoptionen für den privaten Google-Zugriff.
    • Wenn Ihre VMs externe IP-Adressen haben, lesen Sie den Hilfeartikel Routingoptionen.

Interaktionen mit Routen

In den folgenden Abschnitten werden die Interaktionen zwischen Subnetzrouten und anderen Routentypen beschrieben.

Interaktionen zwischen Subnetzrouten und statischen Routen

Google Cloud erzwingt die folgenden Regeln für lokale Subnetzrouten, Peering-Subnetzrouten und Network Connectivity Center-Subnetzrouten, es sei denn, das entsprechende Subnetz wurde als Hybrid-Subnetz konfiguriert.

  • InGoogle Cloud können Sie keine neue statische Route erstellen, wenn das Ziel der neuen statischen Route genau mit dem Ziel einer vorhandenen lokalen, Peering- oder Network Connectivity Center-Subnetzroute übereinstimmt oder in diese passt. Beispiel:

    • Wenn eine lokale, Peering- oder Network Connectivity Center-Subnetzroute mit dem Ziel 10.70.1.0/24 vorhanden ist, können Sie keine neue statische Route für 10.70.1.0/24, 10.70.1.0/25, 10.70.1.128/25 oder ein anderes Ziel erstellen, das in 10.70.1.0/24 passt.

    • Wenn eine lokale oder Peering-Subnetzroute mit dem Ziel 2001:0db8:0a0b:0c0d::/64 vorhanden ist, können Sie keine neue statische Route für 2001:0db8:0a0b:0c0d::/64, 2001:0db8:0a0b:0c0d::/96 oder ein anderes Ziel erstellen, das in 2001:0db8:0a0b:0c0d::/64 passt.

  • InGoogle Cloud können Sie keine Änderungen an Subnetzen vornehmen, die zu einem Subnetz-IP-Adressbereich führen, der genau mit dem Ziel einer vorhandenen lokalen oder Peering-statischen Route übereinstimmt oder diese enthält. Beispiel:

    • Wenn Ihr VPC-Netzwerk eine statische Route mit dem Ziel 10.70.1.128/25 hat, können Sie kein neues Subnetz mit einem primären oder sekundären IPv4-Adressbereich von 10.70.1.128/25, 10.70.1.0/24 oder einem anderen IP-Adressbereich erstellen, der alle IPv4-Adressen in 10.70.1.128/25 enthält.

    • Wenn Ihr VPC-Netzwerk eine statische Route mit dem Ziel 2001:db8:a0b:c0d:e0f:f0e::/96 hat, Google Cloud untersagt die Erstellung einer neuen lokalen oder Peering-Subnetzroute mit einem IPv6-Adressbereich von 2001:db8:a0b:c0d::/64 oder einem anderen Bereich, der alle IPv6-Adressen in 2001:db8:a0b:c0d:e0f:f0e::/96 enthält.

Interaktionen zwischen Subnetzrouten und dynamischen Routen

Google Cloud erzwingt die folgenden Regeln, es sei denn, ein Subnetz wurde als Hybrid-Subnetz konfiguriert.

  • Google Cloud erstellt keine dynamische Route, wenn ein Cloud Router ein Präfix sendet, das genau mit dem Ziel einer vorhandenen lokalen, Peering- oder Network Connectivity Center-Subnetzroute übereinstimmt oder in dieses Ziel passt. Beispiel:

    • Wenn eine lokale, Peering- oder Network Connectivity Center-Subnetzroute mit dem Ziel 10.70.1.0/24 vorhanden ist und ein Cloud Router im VPC-Netzwerk, einem VPC-Netzwerk mit Peering oder einem Netzwerk mit einem Network Connectivity Center-Hybrid-Spoke 10.70.1.128/25, 10.70.1.0/24 oder ein anderes Präfix empfängt, das in 10.70.1.0/24 passt, erstellt Google Cloud keine lokalen, Peering- oder Network Connectivity Center-dynamischen Routen für die empfangenen in Konflikt stehenden Präfixe.

    • Wenn eine lokale, Peering- oder Network Connectivity Center-Subnetzroute mit dem Ziel 2001:0db8:0a0b:0c0d::/64 vorhanden ist und ein Cloud Router im VPC-Netzwerk, einem Peering-VPC-Netzwerk oder einem Netzwerk mit einem Network Connectivity Center-Hybrid-Spoke 2001:0db8:0a0b:0c0d::/96, 2001:0db8:0a0b:0c0d::/64 oder ein anderes Präfix empfängt, das in 2001:0db8:0a0b:0c0d::/64 passt, Google Cloud werden keine lokalen, Peering- oder Network Connectivity Center-dynamischen Routen für die empfangenen in Konflikt stehenden Präfixe erstellt.

  • Google Cloud entfernt alle vorhandenen dynamischen Routen, wenn eine Änderung an Subnetzen zur Erstellung einer neuen lokalen, Peering- oder Network Connectivity Center-Subnetzroute führt, deren Ziel genau mit dem Ziel der vorhandenen lokalen, Peering- oder Network Connectivity Center-dynamischen Route übereinstimmt oder diese enthält. Beispiel:

    • Wenn Ihr VPC-Netzwerk eine lokale, Peering- oder Network Connectivity Center-dynamische Route mit dem Ziel 10.70.1.128/25 hat, entferntGoogle Cloud die dynamische Route, wenn eine neue lokale, Peering- oder Network Connectivity Center-Subnetzroute für 10.70.1.128/25, 10.70.1.0/24 oder einen anderen IP-Adressbereich erstellt wird, der alle IPv4-Adressen in 10.70.1.128/25 enthält.

    • Wenn Ihr VPC-Netzwerk eine lokale, Peering- oder Network Connectivity Center-dynamische Route mit dem Ziel 2001:db8:a0b:c0d::/96 hat, Google Cloud wird die dynamische Route entfernt, wenn eine neue lokale, Peering- oder Network Connectivity Center-Subnetzroute für 2001:db8:a0b:c0d::/64 erstellt wird.

Anwendbarkeit und Reihenfolge

Anwendbare Routen

Jede Instanz, jeder Cloud VPN-Tunnel und jeder VLAN-Anhang hat eine Reihe von anwendbaren Routen, also Routen, die für diese bestimmte Ressource gelten. Anwendbare Routen sind eine Teilmenge aller Routen im VPC-Netzwerk.

Die folgenden Routentypen gelten immer für alle VM-Instanzen, VLAN-Anhänge und Cloud VPN-Tunnel:

Die folgenden Routentypen können so konfiguriert werden, dass sie nur auf bestimmte VM-Instanzen, VLAN-Anhänge oder Cloud VPN-Tunnel angewendet werden:

  • Richtlinienbasierte Routen können für Folgendes gelten:

    • Alle VM-Instanzen, VLAN-Anhänge und Cloud VPN-Tunnel
    • Nur VM-Instanzen, die durch Netzwerktags identifiziert werden
    • Nur VLAN-Anhänge in einer bestimmten Region

  • Statische Routen können für Folgendes gelten:

    • Alle VM-Instanzen, VLAN-Anhänge und Cloud VPN-Tunnel
    • Nur VM-Instanzen, die durch Netzwerktags identifiziert werden

  • Dynamische Routen können je nach dem Modus für dynamisches Routing des VPC-Netzwerks entweder für VM-Instanzen, VLAN-Anhänge und Cloud VPN-Tunnel in der Region mit dem nächsten Hop der dynamischen Route oder für alle Regionen gelten.

Spezielle Routingpfade

VPC-Netzwerke haben spezielle Routen für bestimmte Dienste. Diese speziellen Routingpfade werden nicht in der Routentabelle Ihres VPC-Netzwerk angezeigt. Spezielle Routingpfade können nicht entfernt werden. Sie können Pakete jedoch mithilfe von VPC-Firewallregeln oder Firewallrichtlinien zulassen oder ablehnen.

Pfade für externe Passthrough-Network Load Balancer und externe Protokollweiterleitung

Externe Passthrough-Network Load Balancer und externe Protokollweiterleitung verwenden Maglev-Systeme, um Pakete von Clients im Internet zu Backend-VMs und Zielinstanzen in Ihrem VPC-Netzwerk weiterzuleiten. Diese Maglev-Systeme leiten Pakete mit Zielen weiter, die mit dem Ziel der externen Weiterleitungsregel übereinstimmen.

Jede Weiterleitungsregel für einen externen Passthrough-Network Load Balancer oder für die externe Protokollweiterleitung bietet auch einen Routingpfad für die Backend-VMs oder die Zielinstanz, um Pakete an Ziele außerhalb des VPC-Netzwerk zu senden:

  • Von Backend-VMs oder Zielinstanzen gesendete Pakete können entweder ausgehende Antwortpakete (die an den Client zurückgesendet werden) oder ausgehende Pakete sein, mit denen eine neue Verbindung initiiert wird.
  • Die Paketquellen müssen mit der IP-Adresse der Weiterleitungsregel übereinstimmen. Paketprotokoll und Quellport müssen nicht mit der Protokoll- und Portspezifikation der Weiterleitungsregel übereinstimmen.
  • Routingpfade von Weiterleitungsregeln sind nicht von einer Standardroute oder der Verwendung des nächsten Hops des Standard-Internetgateways abhängig.
  • Für Back-End-VMs und Zielinstanzen muss die IP-Weiterleitung nicht aktiviert sein.

Pfade zwischen Google Front Ends und Back-Ends

Externe Application Load Balancer und externe Proxy-Network Load Balancer verwenden Google Front Ends (GFEs). GFEs der zweiten Ebene öffnen TCP-Verbindungen zu Ihren Backend-VMs und senden Pakete aus den folgenden Quellen:

  • 35.191.0.0/16 und 130.211.0.0/22 für IPv4
  • 2600:2d00:1:1::/64 für IPv6

Google Cloud verwendet Routen im Google-Netzwerk, um Pakete aus diesen Quellbereichen an Backend-VMs in Ihrem VPC-Netzwerk zu senden. Jedes VPC-Netzwerk enthält Routingpfade, über die VMs Antwortpakete an die Bereiche senden können.

Pfade für Systemdiagnosen

Systemdiagnosen für alle Load-Balancer und für die automatische Reparatur verwalteter Instanzgruppen senden Pakete von IP-Adressbereichen für Systemdiagnoseprüfungen an Ihre Back-End-VMs.

Google Cloud verwendet Routen im Google-Netzwerk, um Pakete von Systemdiagnose-Prüfsystemen an VMs in Ihrem VPC-Netzwerk zu senden. Jedes VPC-Netzwerk enthält Routingpfade, über die VMs Antwortpakete an die Systeme für Systemdiagnose-Prüfungen senden können.

Pfade für Identity-Aware Proxy (IAP)

Bei der TCP-Weiterleitung mit IAP werden 35.235.240.0/20 für IPv4 und 2600:2d00:1:7::/64 für IPv6 als rein interne Bereiche mit nächsten Hops verwendet, die sich vollständig im Google-Netzwerk befinden. Google veröffentlicht im Internet keine Routen zu diesen Bereichen.

Wenn Sie die IAP-TCP-Weiterleitung verwenden, werden Pakete von 35.235.240.0/20 oder 2600:2d00:1:7::/64 über Routen im Google-Netzwerk an VMs in Ihrem VPC-Netzwerk weitergeleitet. Jedes VPC-Netzwerk enthält Routingpfade, über die VMs Antwortpakete an diese Bereiche senden können.

Pfade für Cloud DNS und Service Directory

Die folgenden Cloud DNS- und Service Directory-Features verwenden 35.199.192.0/19 als rein internen Bereich mit nächsten Hops, die sich vollständig im Google-Netzwerk befinden. Google veröffentlicht im Internet keine Routen zu 35.199.192.0/19.

Wenn Sie diese Cloud DNS- und Service Directory-Funktionen verwenden, werden Pakete von 35.199.192.0/19 über Routen im Google-Netzwerk an VMs in Ihrem VPC-Netzwerk weitergeleitet. Jedes VPC-Netzwerk enthält Routingpfade, über die VMs Antwortpakete an 35.199.192.0/19 senden können.

Pfade für den Serverloser VPC-Zugriff

Der serverlose VPC-Zugriff verwendet 35.199.224.0/19 als rein internen Bereich mit nächsten Hops, die sich vollständig im Google-Netzwerk befinden. Google veröffentlicht im Internet keine Routen zu 35.199.224.0/19.

Über Routen im Google-Netzwerk werden Pakete von 35.199.224.0/19 an Connector-Instanzen für den serverlosen VPC-Zugriff gesendet. Jedes VPC-Netzwerk enthält Routingpfade, über die Connector-Instanzen Antwortpakete an 35.199.224.0/19 senden können.

Pfade für Private Service Connect-Endpunkte für globale Google APIs

Wenn Sie einen Private Service Connect-Endpunkt für globale Google APIs erstellen, fügtGoogle Cloud eine Route für den Endpunkt zu Ihrem VPC-Netzwerk hinzu. Das Ziel dieser Route ist die globale interne IP-Adresse des Endpunkts.

Routingreihenfolge

Für ein bestimmtes Paket kann es mehr als eine anwendbare Route geben. In den folgenden Schritten wird der Prozess modelliert, mit dem Google Cloud eine Route auswählt.

  1. Spezielle Routingpfade: EinigeGoogle Cloud spezielle Routingpfade werden nicht in VPC-Netzwerk-Routentabellen angezeigt. Weitere Informationen finden Sie unter Spezielle Routingpfade.

    Wenn ein spezieller Routingpfad gilt, enthält das Routenauswahlmodell nur den speziellen Pfad. Alle anderen Routen werden ignoriert und die Bewertung wird in diesem Schritt beendet.

  2. Richtlinienbasierte Routen: Richtlinienbasierte Routen werden nach speziellen Routingpfaden aber vor anderen Routentypen ausgewertet. Wenn im VPC-Netzwerk keine richtlinienbasierten Routen vorhanden sind, überspringtGoogle Cloud diesen Schritt und fährt mit dem Schritt Subnetzrouten fort.

    Google Cloud wertet richtlinienbasierte Routen ausschließlich nach ihrer Priorität aus. Google Cloud wertet die Quelle und das Ziel eines Pakets für jede richtlinienbasierte Route aus, beginnend mit der richtlinienbasierten Route mit der höchsten Priorität. Wenn die Eigenschaften eines Pakets nicht mit einer richtlinienbasierten Route übereinstimmen, ignoriertGoogle Cloud diese richtlinienbasierte Route und wertet die nächste richtlinienbasierte Route in der sortierten Liste aus. Die nächste auszuwertende richtlinienbasierte Route hat möglicherweise dieselbe oder eine niedrigere Priorität wie die ignorierte richtlinienbasierte Route.

    • Wenn die Eigenschaften eines Pakets keiner richtlinienbasierten Route entsprechen, nachdem alle richtlinienbasierten Routen in Ihrem Routenauswahlmodell ausgewertet wurden, ignoriertGoogle Cloud alle richtlinienbasierten Routen und fährt mit dem Schritt Subnetzrouten fort.

    • Wenn die Eigenschaften eines Pakets mit einer richtlinienbasierten Route mit der höchsten Priorität übereinstimmen, Google Cloud werden zuerst alle Routen mit niedrigerer Priorität ignoriert. Wenn noch zwei oder mehr richtlinienbasierte Routen in der Liste verbleiben, Google Cloud wertet jede der verbleibenden richtlinienbasierten Routen mit identischen Prioritäten aus. Google Cloud Alle verbleibenden richtlinienbasierten Routen werden ignoriert, wenn die Eigenschaften eines Pakets nicht mit ihnen übereinstimmen. Nach diesem Schritt kann Ihr Routenauswahlmodell eine oder mehrere richtlinienbasierte Routen enthalten.

    • Wenn Ihr Routenauswahlmodell zwei oder mehr übereinstimmende Routen mit der höchsten Priorität enthält,wählt Google Cloud mithilfe eines internen Algorithmus eine einzelne richtlinienbasierte Route aus. Die ausgewählte richtlinienbasierte Route ist möglicherweise nicht die spezifischste Übereinstimmung für die Quelle oder das Ziel des Pakets. Zur Vermeidung dieser Mehrdeutigkeit empfehlen wir Ihnen, richtlinienbasierte Routen mit eindeutigen Prioritäten zu erstellen.

    • Wenn Ihr Routenauswahlmodell nur eine einzige richtlinienbasierte Route mit der höchsten Priorität enthält, die so konfiguriert ist, dass andere richtlinienbasierte Routen übersprungen werden, Google Cloud ignoriert alle richtlinienbasierten Routen und fährt mit dem Schritt Subnetzrouten fort.

    • Wenn Ihr Routenauswahlmodell nur eine einzige richtlinienbasierte Route mit der höchsten Priorität enthält, die nicht so konfiguriert ist, dass andere richtlinienbasierte Routen übersprungen werden, Google Cloud wird das Paket an den internen Passthrough-Network Load Balancer des nächsten Hops übergeben und alle nicht-richtlinienbasierten Routen werden ignoriert.

  3. Subnetzrouten: Google Cloud bestimmt, ob das Ziel des Pakets in den Zielbereich einer lokalen, Peering- oder Network Connectivity Center-Subnetzroute im VPC-Netzwerk fällt.

    • Keine passende Subnetzroute: Wenn das Ziel eines Pakets nicht mit dem Zielbereich einer Subnetzroute übereinstimmt,ignoriert Google Cloud alle Subnetzrouten. Entfernen Sie alle Subnetzrouten aus Ihrem Routenauswahlmodell und fahren Sie mit dem Schritt Spezifischstes Ziel fort, um statische und dynamische Routen auszuwerten.

    • Übereinstimmende reguläre Subnetzroute: Wenn das Ziel eines Pakets mit dem Zielbereich einer regulären Subnetzroute übereinstimmt, verwendetGoogle Cloud ausschließlich die Subnetzroute Google Cloud.Alle anderen Routen werden ignoriert und die Auswertung wird an diesem Schritt beendet. Wenn das Ziel des Pakets nicht mit einer Ressource verknüpft ist oder zu einer angehaltenen VM-Instanz gehört, wird das Paket verworfen.

    • Übereinstimmende Hybrid-Subnetzroute: Wenn das Ziel eines Pakets mit dem Zielbereich einer Hybrid-Subnetzroute übereinstimmt und das Ziel mit einer IP-Adresse übereinstimmt, die einer laufenden VM-Instanz oder einer internen Weiterleitungsregel zugeordnet ist, Google Cloudwird das Paket über die Hybrid-Subnetzroute weitergeleitet. Google CloudAlle anderen Routen werden ignoriert und die Auswertung wird an diesem Schritt beendet.

      Wenn das Ziel nicht mit einer laufenden VM oder einer internen Weiterleitungsregel übereinstimmt, lesen Sie den Abschnitt Nicht übereinstimmende Ressourcen in Hybrid-Subnetzen.

  4. Spezifischstes Ziel: Zu Beginn dieses Schritts hat Google Cloud alle speziellen Routingpfade, richtlinienbasierten Routen und Subnetzrouten ignoriert.

    Google Cloud ermittelt, welche anwendbaren statischen oder dynamischen Routen das spezifischste Ziel haben, das die Ziel-IP-Adresse des Pakets enthält. Google Cloud ignoriert alle Routen mit Ausnahme der Routen mit dem spezifischsten Ziel. Beispielsweise ist 10.240.1.0/24 ein spezifischeres Ziel als 10.240.0.0/16.

    Am Ende dieses Schritts enthält Ihr Routenauswahlmodell nur statische oder dynamische Routen mit identischen Zielen.

  5. Nur den bevorzugten benutzerdefinierten Routentyp auswählen: In diesem Schritt werden alle benutzerdefinierten Routen mit Ausnahme des bevorzugten benutzerdefinierten Routentyps entfernt. Google CloudLokale benutzerdefinierte Routen werden gegenüber dynamischen Network Connectivity Center-Routen bevorzugt und dynamische Network Connectivity Center-Routen werden gegenüber benutzerdefinierten Peering-Routen bevorzugt.

    In der folgenden Tabelle wird die Logik zusammengefasst, die Google Cloud in diesem Schritt verwendet.

    Kategorie für benutzerdefinierte Routen Was passiert dann?
    Lokale dynamische und lokale statische Routen

    Wenn Ihr Routenmodell mindestens eine lokale dynamische oder lokale statische Route für das Ziel enthält, Google Cloud werden die folgenden benutzerdefinierten Routentypen entfernt, sofern sie im Routenmodell vorhanden sind:

    • Dynamische Routen von Network Connectivity Center von Hybrid-Spokes in verschiedenen VPC-Netzwerken
    • Dynamische Peering-Routen (aus anderen VPC-Netzwerken importiert, die über VPC-Netzwerk-Peering verbunden sind)
    Dynamische Routen für Network Connectivity Center Wenn alle der folgenden Bedingungen erfüllt sind, werden mit Google Cloud alle dynamischen und statischen Peering-Routen aus dem Routenmodell entfernt:
    • Ihr Routenmodell enthält keine lokalen benutzerdefinierten Routen für das Ziel.
    • Ihr Routenmodus enthält mindestens eine dynamische Network Connectivity Center-Route für das Ziel.
    • Die dynamische Route des Network Connectivity Centers stammt von einem Hybrid-Spoke in einem anderen VPC-Netzwerk.
    Dynamische und statische Peering-Routen Der am wenigsten bevorzugte benutzerdefinierte Routentyp enthält benutzerdefinierte Peering-Routen. Benutzerdefinierte Peering-Routen für das Ziel werden nur verwendet, wenn das Routenmodell keine lokalen benutzerdefinierten Routen oder dynamischen Network Connectivity Center-Routen für das Ziel enthält.

  6. Nächste Hops für benutzerdefinierte Peering-Routen aus einem einzelnen VPC-Netzwerk auswählen: Die nächsten Hops für dasselbe Ziel müssen sich im selben VPC-Netzwerk befinden. Dieser Schritt gilt nur, wenn Ihr Routenmodell dynamische oder statische Peering-Routen enthält, die aus zwei oder mehr verschiedenen VPC-Netzwerken importiert werden, die über VPC-Netzwerk-Peering verbunden sind.

    Google Cloud verwendet einen internen Algorithmus, um benutzerdefinierte Peering-Routen aus einem einzelnen VPC-Netzwerk zu importieren. Das Peer-Netzwerk, das vonGoogle Cloud ausgewählt wird, kann sich ändern, wenn Ihr VPC-Netzwerk mit einem neuen VPC-Netzwerk verbunden wird oder die Verbindung zu einem vorhandenen Peer-VPC-Netzwerk getrennt wird.

  7. Statische und dynamische Routen mit nicht verwendbaren nächsten Hops ignorieren: Mit diesem Schritt werden Situationen modelliert, in denenGoogle Cloud nächste Hops ignoriert, die ausgefallen oder ungültig sind.

    • Ungültige Angabe der IP-Adresse der nächsten Hop-VM: Die next-hop-address einer statischen Route muss mit einer IP-Adresse übereinstimmen, die einer VM im VPC-Netzwerk der Route zugewiesen ist. Die IP-Adresse muss der Netzwerkschnittstelle der VM als eine der folgenden Adressen zugewiesen sein:

      • Eine primäre interne IPv4-Adresse
      • Eine interne IPv6-Adresse
      • Eine externe IPv6-Adresse

      Wenn die von next-hop-address angegebene IP-Adresse mit einem anderen Ressourcentyp (z. B. einem Alias-IP-Bereich) übereinstimmt oder mit keiner Ressource übereinstimmt, wird die Route vonGoogle Cloud ignoriert.

    • Nächster Hop ist keine VM: Google Cloud ignoriert jede statische Route, deren nächste Hop-VM-Instanz angehalten oder gelöscht wurde. Dieses Verhalten gilt für Routen, deren nächste Hops entweder mit next-hop-instance oder next-hop-address angegeben werden. Weitere Informationen finden Sie unter Verhalten beim Anhalten oder Löschen von Instanzen.

    • Ungültige Angabe der IP-Adresse des Load Balancers für den nächsten Hop: Bei statischen Routen, für die ein Load Balancer für den nächsten Hop anhand der IP-Adresse angegeben wird, muss die IP-Adresse mit einer Weiterleitungsregel eines internen Passthrough-Network Load Balancers übereinstimmen, der sich im VPC-Netzwerk der Route oder in einem Peering-VPC-Netzwerk befindet. Wenn die IP-Adresse des nächsten Hops mit der Weiterleitungsregel eines anderen Load Balancer-Typs übereinstimmt oder mit keiner Weiterleitungsregel übereinstimmt, wird die Route vonGoogle Cloud ignoriert.

    • Nicht eingerichteter Klassisches VPN-Tunnel als nächster Hop:Google Cloud ignoriert jede statische Route mit einem Klassisches VPN-Tunnel als nächster Hop, der keine aktive IKE-Sicherheitsverknüpfung (SA) der Phase 1 hat. Weitere Informationen finden Sie in der Dokumentation zu Klassisches VPN unter Reihenfolge der Routen.

    • Dynamische Route mit nicht funktionsfähigem nächsten Hop: Noch bevor die BGP-Sitzung, die für die Programmierung einer dynamischen Route verantwortlich ist, ausfällt, ignoriert Google Cloudeine dynamische Route, wenn der zugehörige Cloud VPN-Tunnel, VLAN-Anhang oder die Router-Appliance-VM als nächster Hop nicht funktioniert. Diese Situation tritt in der Regel nur für wenige Sekunden auf, bevor die dynamische Route entfernt wird, wenn die entsprechende BGP-Sitzung des Cloud Routers ausfällt.

    Google Cloud prüft nicht, ob das Gastbetriebssystem einer Next-Hop-VM oder einer Back-End-VM für einen Next-Hop-Load-Balancer Pakete verarbeitet. Weitere Informationen finden Sie unter Überlegungen zu Instanzen und internen Passthrough Network Load Balancern, die als nächste Hops dienen.

  8. Routen mit niedriger Priorität ignorieren: In diesem Schritt wird modelliert, wie Google Cloud alle Routen mit Ausnahme der Routen mit der höchsten Priorität verwirft.

    Nach diesem Schritt ist Ihr Routenmodell möglicherweise leer oder enthält eine oder mehrere Routen. Wenn Ihr Modell nicht leer ist, haben alle Routen in Ihrem Modell die folgenden Merkmale:

    • Identische Prioritäten
    • Nächste Hops, die nicht ignoriert wurden
    • Identische Ziele
    • Routentypen, die keine richtlinienbasierten Routen oder Subnetzrouten sind

  9. Nächste Hops für dynamische Network Connectivity Center-Routen aus einem einzelnen VPC-Netzwerk auswählen: Nächste Hops für dasselbe Ziel müssen sich im selben VPC-Netzwerk befinden. Dieser Schritt ist nur anwendbar, wenn Ihr Routenmodell dynamische Network Connectivity Center-Routen enthält, die aus zwei oder mehr Hybrid-Spokes in verschiedenen VPC-Netzwerken importiert wurden.

    Google Cloud verwendet einen internen Algorithmus, um dynamische Network Connectivity Center-Routen aus Hybrid-Spokes zu importieren, die sich in einem einzelnen VPC-Netzwerk befinden. Die ausgewählten Hybrid-Spokes können sich ändern, wenn Sie dem Network Connectivity Center-Hub Hybrid-Spokes hinzufügen oder daraus entfernen. Um diese Mehrdeutigkeit zu vermeiden, müssen dynamische Network Connectivity Center-Routen eindeutige Prioritäten haben, wenn Folgendes zutrifft:

    • Die Routen haben identische Ziele.
    • Die Routen werden aus zwei oder mehr Hybrid-Spokes in verschiedenen VPC-Netzwerken importiert.

  10. Nur die bevorzugte Präferenzkategorie auswählen: Google Cloud führt kein ECMP-Routing (Equal-Cost Multipath) zwischen Routen durch, die zu verschiedenen Präferenzkategorien gehören, wie in diesem Schritt definiert.

    Präferenzkategorie Routentyp und Typ des nächsten Hops
    Erste Wahl (bevorzugt) Eine oder mehrere statische Routen mit nächsten Hop-Instanzen (next-hop-instance oder next-hop-address) oder Klassisches VPN-Tunneln als nächster Hop
    Zweite Wahl Eine oder mehrere dynamische Routen eines einzelnen Typs.
    Dritte Wahl Eine einzelne statische Route mit einem internen Passthrough-Network-Load-Balancer als nächstem Hop.
    Vierte Präferenz (sagt mir am wenigsten zu) Eine oder mehrere statische Routen mit dem nächsten Hop default-internet-gateway

    Wenn in diesem Schritt zwei oder mehr statische Routen mit Load-Balancer als nächstem Hop vorhanden sind, wählt Google Cloud eine einzelne statische Route mit einem internen Algorithmus aus.Google Cloud führt kein ECMP zwischen mehreren Load-Balancern aus. Weitere Informationen finden Sie unter Überlegungen zu internen Passthrough Network Load Balancern, die als nächster Hop dienen.

    Nach diesem Schritt ist Ihr Routenmodell möglicherweise leer oder enthält eine oder mehrere Routen. Wenn Ihr Modell nicht leer ist, haben alle Routen in Ihrem Modell die folgenden Merkmale:

    • Identische Präferenzkategorie
    • Identische Prioritäten
    • Nächste Hops, die nicht ignoriert wurden
    • Nächste Hops in einem VPC-Netzwerk
    • Identische Ziele
    • Routentypen, die keine richtlinienbasierten Routen oder Subnetzrouten sind

  11. Paket senden oder verwerfen: Je nach Anzahl der verbleibenden Routen im Routenmodell sendet oder verwirft Google Cloud das Paket:

    • Wenn Ihr Routenmodell eine einzelne Route enthält, Google Cloud wird das Paket an den nächsten Hop gesendet. Es gibt jedoch eine Ausnahme:

      Interne Passthrough Network Load Balancer, die als nächster Hop dienen und für die der globale Zugriff nicht aktiviert ist, sind nicht aus Regionen außerhalb der Region des Load Balancers erreichbar. Wenn für einen Next-Hop-Load-Balancer der globale Zugriff nicht aktiviert ist, werden alle Pakete,die von VM-Instanzen, VLAN-Anhängen und Cloud VPN-Tunneln in anderen Regionen als der Region des Load Balancers gesendet werden, von Google Cloud verworfen. Wenn Sie dieses Verhalten ändern möchten, aktivieren Sie den globalen Zugriff.

    • Wenn Ihr Routenmodell zwei oder mehr Routen enthält, führt Google CloudECMP aus und verteilt Pakete auf die nächsten Hops. Die Auswahl des nächsten Hops hängt von einer Hash-Berechnung und der Anzahl der nächsten Hops ab.Google Cloud verwendet einen 5-Tupel-Hash, wenn das Paket Portinformationen enthält. Andernfalls wird ein 3-Tupel-Hash verwendet. Wenn sich das Routenmodell beim Senden nachfolgender Pakete ändert, leitet Google Cloud diese Pakete möglicherweise an einen anderen nächsten Hop weiter, auch wenn der Hash identisch ist.

    • Wenn Ihr Routenmodell leer ist,verwirft Google Cloud das Paket mit einer ICMP-Meldung vom Typ 3, Code 0 (Netzwerk nicht erreichbar).

Nicht übereinstimmende Ressourcen in Hybridsubnetzen

Wenn Ihr Routenmodell eine hybride Subnetzroute enthält und das Ziel des Pakets mit einer IP-Adresse übereinstimmt, die einer angehaltenen VM zugeordnet ist oder keiner Ressource im Hybrid-Subnetz zugeordnet ist, verwendetGoogle Cloud einen anderen Prozess, um das Paket weiterzuleiten. Die folgenden Schritte beschreiben den Prozess, den Google Cloud zum Weiterleiten dieser Pakete verwendet:

  1. Ermitteln Sie das VPC-Netzwerk, das das Hybridsubnetz enthält:

    • Das Hybridsubnetz und die Ressource, die Pakete an das Hybridsubnetz sendet, verwenden möglicherweise dasselbe VPC-Netzwerk. In diesem Fall wird im VPC-Netzwerk eine entsprechende lokale Subnetzroute für das Hybridsubnetz erstellt.

    • Das Hybridsubnetz und die Ressource, die Pakete an das Hybridsubnetz sendet, können sich in verschiedenen VPC-Netzwerken befinden, die über VPC-Netzwerk-Peering verbunden sind. In diesem Fall wird durch das Hybrid-Subnetz eine entsprechende Peering-Subnetzroute im VPC-Netzwerk erstellt, das von der Ressource verwendet wird, die Pakete sendet.

  2. Beginnen Sie mit allen Routen des VPC-Netzwerk, das das hybride Subnetz enthält, und entfernen Sie dann die folgenden Routen:

    • Alle richtlinienbasierten Routen
    • Alle Subnetzrouten
    • Alle statischen Routen mit Netzwerk-Tags
    • Alle Routen, deren Ziele breiter sind als die Hybridsubnetzroute, die im ersten Routenmodell gefunden wurde, und diese enthalten

  3. Führen Sie die Schritte Spezifischstes Ziel bis Nur die bevorzugte Präferenzkategorie auswählen in der Routingreihenfolge aus.

  4. Anhand der folgenden Regeln können Sie ermitteln, ob Google Cloud das Paket sendet oder verwirft:

    • Wenn das Routenmodell eine einzelne Route enthält und der nächste Hop der Route sich in derselben Region wie das hybride Subnetz befindet, Google Cloud wird das Paket an den nächsten Hop gesendet.

    • Wenn das Routenmodell zwei oder mehr Routen enthält,führt Google CloudECMP zwischen diesen Routen aus. Wenn sich der nächste Hop in derselben Region wie das hybride Subnetz befindet, Google Cloud wird das Paket an den nächsten Hop gesendet.

    • Google Cloud verwirft das Paket mit einer ICMP-Meldung vom Typ 3, Code 0 (Netzwerk nicht erreichbar), wenn das Routenmodell leer ist oder sich ein Next Hop in einer anderen Region als die Region des Hybrid-Subnetzes befindet.

    Die folgenden Routen haben nächste Hops in Regionen, die sich von der Region des hybriden Subnetzes unterscheiden. Daher führen sie immer zu Paketverlusten:

    • Dynamische Routen, die von Cloud Routern in anderen Regionen als der Region des hybriden Subnetzes erkannt werden, auch wenn der dynamische Routingmodus des VPC-Netzwerk, das die Cloud Router enthält, global ist.
    • Statische Routen mit nächsten Hops in Regionen, die sich von der Region des hybriden Subnetzes unterscheiden, einschließlich aller internen Passthrough-Network-Load-Balancer in anderen Regionen, auch wenn der globale Zugriff aktiviert ist

Nächste Schritte