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 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 Zielpräfix im CIDR-Format 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

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 das VPC-Netzwerk eintritt (in nur einer Region oder in allen Regionen).

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 Cloud während Subnetzlebenszyklus-Ereignissen automatisch erstellt, aktualisiert und entfernt.

Lokale Subnetz-Routen gelten für das gesamte VPC-Netzwerk.
Peering-Subnetzroute
Stellt einen IP-Adressbereich des Subnetzes 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 Cloud wä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 Cloud wä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 einen als nächster Hop dienenden nächsten Hop für statische Routen weiter Weitere Informationen zu jeder 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 basierend auf erkannten Routen von Cloud Routern in Ihrem VPC-Netzwerk automatisch 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.

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.
Network Connectivity Center-dynamische Route
Dynamische Routen, die aus Network Connectivity Center-Hybrid-Spokes importiert wurden, die sich in verschiedenen VPC-Netzwerken befinden 		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.

Arten von 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 Subnetz-Routen müssen eindeutig sein. Weitere Informationen finden Sie hier:

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. In den folgenden Fällen werden Subnetzrouten in Google Cloud erstellt und gelöscht:

  • 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, anhand der empfangenen BGP-Nachrichten (Border Gateway Protocol), der anwendbaren BGP-Routenrichtlinien (Vorabversion) und der benutzerdefinierten erkannten Cloud Router-Routen dynamische Routen zu erstellen, zu aktualisieren und zu entfernen.

Dynamische Routen werden in einer oder in allen Regionen erstellt, je nach dem Modus für dynamisches Routing und 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-Statusä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 erlernt werden, werden als lokale dynamische Routen bezeichnet.
  • Dynamische Peering-Routen, die mit dem Austausch benutzerdefinierter Routen aus Netzwerken importiert werden, die über VPC-Netzwerk-Peering verbunden sind .
  • Dynamic Network Connectivity Center-Routen, die aus Hybrid-Spokes in verschiedenen VPC-Netzwerken eines Network Connectivity Center-Hubs importiert werden.

In Google Cloud werden Konflikte zwischen dynamischen Routen und Subnetzrouten wie unter Interaktionen mit dynamischen Routen beschrieben gelöst.

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 verwendet eine Standardroute nur, 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ügt Google 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. Je nachdem, für welche IPv4-Adressbereiche des Subnetzes das Cloud NAT-Gateway konfiguriert ist, können Paketquellen mit einer der folgenden Optionen übereinstimmen:
    • Eine interne IPv4-Adresse aus einem Alias-IP-Adressbereich der Netzwerkschnittstelle der VM (unabhängig davon, ob der Netzwerkschnittstelle eine externe IPv4-Adresse zugewiesen ist) oder
    • Die primäre interne IPv4-Adresse der Netzwerkschnittstelle der VM, sofern der Netzwerkschnittstelle keine externe IPv4-Adresse zugewiesen ist.

Wenn Sie ein Subnetz mit einem externen IPv6-Adressbereich erstellen, fügt Google 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 besonderen 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.

Routeninteraktionen

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

Interaktionen zwischen Subnetzrouten und statischen Routen

In Google Cloud gelten 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.

  • In Google 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.

  • In Google 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, untersagt Google Cloud 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

Für Google Cloud gelten 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 diese passt. Beispiel:

    • Wenn eine lokale, Peering- oder Subnetzroute des Network Connectivity Centers mit dem Ziel 10.70.1.0/24 vorhanden ist und ein Cloud Router im VPC-Netzwerk, in einem Peering-VPC-Netzwerk oder in einem Netzwerk mit einem Network Connectivity Center-Hybrid-Speichere 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 Subnetzroute des Network Connectivity Centers mit dem Ziel 2001:0db8:0a0b:0c0d::/64 vorhanden ist und ein Cloud Router im VPC-Netzwerk, in einem Peering-VPC-Netzwerk oder in einem Netzwerk mit einem Network Connectivity Center-Hybrid-Speichere 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, erstellt Google Cloud keine lokalen, Peering- oder Network Connectivity Center-dynamischen Routen für die empfangenen in Konflikt stehenden Präfixe.

  • 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, entfernt Google Cloud die dynamische Route, wenn eine neue lokale, Peering- oder Subnetzroute des Network Connectivity Centers 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, entfernt Google Cloud die dynamische Route, wenn eine neue lokale, Peering- oder Subnetzroute des Network Connectivity Centers 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 ein Netzwerktag 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 ein Netzwerk-Tag gekennzeichnet sind

  • 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 (an den Client zurückgesendet) oder ausgehende Pakete sein, die eine neue Verbindung initiieren.
  • 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 Back-End-VMs und senden Pakete aus den folgenden Quellen:

  • 35.191.0.0/16
  • 130.211.0.0/22

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 35.191.0.0/16 und 130.211.0.0/22 senden können.

Pfade für Systemdiagnosen

Bei Systemdiagnosen für alle Load Balancer und für die automatische Reparatur von verwalteten Instanzgruppen werden Pakete aus IP-Adressbereichen für Systemdiagnoseprüfungen an Ihre Back-End-VMs gesendet.

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

Pfade für Identity-Aware Proxy (IAP)

Bei der TCP-Weiterleitung mit IAP wird 35.235.240.0/20 als rein interner Bereich mit nächsten Hops verwendet, die sich vollständig im Google-Netzwerk befinden. Google veröffentlicht im Internet keine Routen zu 35.235.240.0/20.

Wenn Sie die IAP-TCP-Weiterleitung verwenden, werden Pakete von 35.235.240.0/20 über Routen im Google-Netzwerk an VMs in Ihrem VPC-Netzwerk weitergeleitet. Jedes VPC-Netzwerk enthält Routingpfade, über die VMs Antwortpakete an 35.235.240.0/20 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ügt Google Cloud Ihrem VPC-Netzwerk eine Route für den Endpunkt 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 zur Auswahl einer Route modelliert.

  1. Spezielle Routingpfade: Einige spezielle Routingpfade von Google Cloud, die nicht in der Routentabelle Ihres VPC-Netzwerk angezeigt werden. 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, überspringt Google 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, ignoriert Google 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, ignoriert Google 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, ignoriert Google Cloud zuerst alle Routen mit niedrigerer Priorität. Wenn noch zwei oder mehr richtlinienbasierte Routen in der Liste verbleiben, wertet Google Cloud jede der verbleibenden richtlinienbasierten Routen mit identischen Prioritäten aus. Alle verbleibenden richtlinienbasierten Routen werden von Google Cloud 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, ignoriert Google Cloud 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, übergibt Google Cloud das Paket an den internen Passthrough-Network Load Balancer des nächsten Hops und ignoriert alle nicht-richtlinienbasierten Routen.

  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.

    • Wenn das Ziel eines Pakets nicht mit dem Zielbereich einer lokalen, Peering- oder Subnetzroute des Network Connectivity Centers übereinstimmt, ignoriert Google Cloud alle Subnetzrouten und fährt mit dem Schritt Spezifischstes Ziel fort.

    • Wenn das Ziel eines Pakets mit dem Zielbereich einer lokalen, Peering- oder Network Connectivity Center-Subnetzroute im VPC-Netzwerk übereinstimmt, hängt das Verhalten davon ab, ob das Subnetz als Hybrid-Subnetz konfiguriert wurde:

      • Für die meisten Subnetze verwendet Google Cloud ausschließlich die Subnetz-Route und versucht, das Paket an eine Ressource im Subnetz zu senden, z. B. an eine VM-Netzwerkschnittstelle oder eine interne Weiterleitungsregel. Alle anderen Routen werden ignoriert und die Bewertung wird in diesem Schritt beendet. Wenn keine Ressource mit dem Ziel des Pakets vorhanden ist oder die Ressource eine angehaltene VM-Instanz ist, wird das Paket verworfen.

      • Wenn die übereinstimmende Subnetzroute jedoch aus einem Hybridsubnetz stammt, versucht Google Cloud, eine übereinstimmende Zielressource im Subnetz zu finden, z. B. eine VM-Netzwerkschnittstelle oder eine interne Weiterleitungsregel:

        • Wenn sich eine Ressource im Subnetz befindet, verwendet Google Cloud ausschließlich die Subnetzroute und versucht, das Paket an die Ressource zu senden. Alle anderen Routen werden ignoriert und die Bewertung wird in diesem Schritt beendet. Wenn am Ziel des Pakets keine Ressource vorhanden ist, wird das Paket verworfen. Wenn die Ressource eine VM ist, die nicht ausgeführt wird, wird das Paket ebenfalls verworfen.

        • Wenn eine Ressource nicht im Subnetz vorhanden ist, ignoriert Google Cloud alle Subnetzrouten, einschließlich der übereinstimmenden Subnetzroute, und fährt mit dem Schritt Spezifischstes Ziel fort.

  4. Spezifischstes Ziel: Zu Beginn dieses Schritts enthält Ihr Routenauswahlmodell keine speziellen Routingpfade, keine richtlinienbasierten Routen und keine lokalen, Peering- oder Network Connectivity Center-Subnetzrouten.

    Google Cloud ermittelt, welche der verbleibenden anwendbaren Routen das spezifischste Ziel hat, das die Ziel-IP-Adresse des Pakets enthält. Alle anderen Routen mit weniger spezifischen Zielen werden von Google Cloud ignoriert. 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 benutzerdefinierte Routen mit identischen Zielen.

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

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

    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, entfernt Google Cloud die folgenden benutzerdefinierten Routentypen, sofern sie im Routenmodell vorhanden sind:

    • Dynamische Network Connectivity Center-Routen von Hybrid-Spokes in verschiedenen VPC-Netzwerken
    • Dynamische Peering-Routen (aus anderen VPC-Netzwerken importiert, die über VPC-Netzwerk-Peering verbunden sind)
    Dynamische Routen von Network Connectivity Center Wenn alle der folgenden Bedingungen erfüllt sind, entfernt Google Cloud alle dynamischen und statischen Peering-Routen aus dem Routenmodell:
    • 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. Next Hops für benutzerdefinierte Peering-Routen aus einem einzelnen VPC-Netzwerk auswählen: Next 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 wurden, die über VPC-Netzwerk-Peering verbunden sind.

    In Google Cloud werden benutzerdefinierte Peering-Routen aus einem einzelnen VPC-Netzwerk mithilfe eines internen Algorithmus importiert. Das von Google Cloud ausgewählte Peer-Netzwerk 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 denen Google 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 auf folgende Weise zugewiesen werden:

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

      Wenn die mit 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 von Google 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 sind. Weitere Informationen finden Sie unter Verhalten beim Anhalten oder Löschen von Instanzen.

    • Ungültige Angabe der IP-Adresse des nächsten Load Balancers: Bei statischen Routen mit einem nächsten Load Balancer, der durch eine 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 von Google 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 klassischen VPNs 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 Cloud eine dynamische Route, wenn ihr Cloud VPN-Tunnel, ihr VLAN-Anhang oder ihre 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 nächsten Hop-VM oder einer Back-End-VM für einen nächsten 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 oder Subnetzrouten sind

  9. Nächste Hops für dynamische Network Connectivity Center-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 Network Connectivity Center-Routen enthält, die aus zwei oder mehr Hybrid-Spokes importiert wurden, die sich in verschiedenen VPC-Netzwerken befinden.

    In Google Cloud werden dynamische Routen des Network Connectivity Center mithilfe eines internen Algorithmus aus Hybrid-Spokes in einem einzelnen VPC-Netzwerk importiert. 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 Next-Hop-Typ
    Erste Präferenz (am meisten 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 Präferenz Eine oder mehrere dynamische Routen eines einzelnen Typs.
    Dritte Wahl Eine einzelne statische Route mit dem internen Passthrough-Network-Load-Balancer als nächstem Hop.
    Vierte Präferenz (am wenigsten bevorzugt) Eine oder mehrere statische Routen mit dem nächsten Hop default-internet-gateway

    Wenn in diesem Schritt zwei oder mehr statische Routen mit dem nächsten Hop als Load Balancer vorhanden sind, wählt Google Cloud mithilfe eines internen Algorithmus eine einzelne statische Route 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 folgende 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 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, sendet Google Cloud das Paket mit der folgenden Ausnahme an den nächsten Hop:

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

    • Wenn Ihr Routenmodell zwei oder mehr Routen enthält, führt Google Cloud ECMP 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, löscht Google Cloud das Paket mit einer ICMP-Nachricht vom Typ 3, Code 0 (Netzwerk nicht erreichbar).

Nächste Schritte