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 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
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
Subnetzroute
Wird automatisch für jeden Subnetz-IP-Adressbereich erstellt
VPC-Netzwerk
Leitet Pakete an VMs und interne Load-Balancer weiter
Gilt für das gesamte VPC-Netzwerk

Wird von Google Cloud automatisch erstellt, aktualisiert und entfernt, wenn Sie ein Subnetz oder einen sekundären IP-Adressbereich eines Subnetzes erstellen, ändern oder löschen.
Benutzerdefinierte Routen
Statische Route
Unterstützt verschiedene Ziele
Gültige statische Route mit nächstem Hop Bei internen TCP/UDP-Load-Balancern mit nächstem Hop: gilt nur für TCP- und UDP-Traffic in derselben Region wie der Load-Balancer, es sei denn, der globale Zugriff ist aktiviert.

Bei anderen statischen Routen mit nächstem Hop: Die Route gilt für bestimmte VMs, wenn Sie Netzwerk-Tags für die Route angeben. Wenn Sie kein Netzwerk-Tag angeben, gilt die Route für alle VMs im VPC-Netzwerk.
Dynamische Route
Ziele, die nicht mit Subnetzrouten oder statischen Routen in Konflikt stehen
Peer einer BGP-Sitzung auf einem Cloud Router Routen werden von Cloud Routern in Ihrem VPC-Netzwerk automatisch hinzugefügt und entfernt.

Routen gelten für VMs entsprechend dem dynamischen Routingmodus des VPC-Netzwerks.
Peering-Routen
Peering-Subnetzroute
Steht für den Subnetz-IP-Adressbereich in einem Netzwerk, das über VPC-Netzwerk-Peering verbunden ist
Peer-VPC-Netzwerk
Leitet Pakete an VMs und interne Load-Balancer im Peer-Netzwerk weiter
Gilt für das gesamte VPC-Netzwerk

Wird von Google Cloud automatisch erstellt, aktualisiert und entfernt, wenn Sie Subnetze im Peer-Netzwerk erstellt, geändert oder gelöscht werden
Benutzerdefinierte Peering-Route
Benutzerdefinierte statische oder benutzerdefinierte dynamische Route in einem Netzwerk, das über VPC-Netzwerk-Peering verbunden ist
Nächster Hop im Peer-VPC-Netzwerk Benutzerdefinierte Peering-Routen, die von statischen Routen im Peer-Netzwerk unterstützt werden, gelten so:
  • Wenn die benutzerdefinierte Peering-Route von einer benutzerdefinierten statischen Route unterstützt wird, deren nächster Hop ein interner TCP/UDP-Load-Balancer ist, gilt die Route für TCP- und UDP-Traffic in derselben Region wie der Load-Balancer, wenn nicht globaler Zugriff in der Weiterleitungsregel des Load-Balancers aktiviert ist.
  • Wenn die benutzerdefinierte Peering-Route von einer benutzerdefinierten statischen Route unterstützt wird, deren nächster Hop kein interner TCP/UDP-Load-Balancer ist und die kein zugehöriges Tag hat: Die Route gilt für alle VMs im VPC-Netzwerk, die die Route importieren.
  • Statische Routen in einem Peer-Netzwerk, das Netzwerk-Tags verwendet oder deren nächste Hops das Standard-Internetgateway sind, werden nie in eine Peering-Beziehung exportiert.
Die benutzerdefinierten Peering-Routen, die von dynamischen Routen im Peer-Netzwerk unterstützt werden, gelten entsprechend dem Modus für dynamisches Routing des VPC-Netzwerks, in dem die Routen importiert werden.

Vom System generierte Standardrouten

Wenn Sie ein VPC-Netzwerk erstellen, enthält es eine vom System generierte IPv4-Standardroute (0.0.0.0/0). Wenn Sie externe IPv6-Adressen in einem Subnetz aktivieren, wird diesem VPC-Netzwerk eine vom System generierte IPv6-Standardroute (::/0) hinzugefügt. Standardrouten dienen folgenden Zwecken:

Google Cloud verwendet eine Standardroute nur, 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:

  • Nur IPv4: 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 eine Proxy-VM ist.

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

    Wenn Sie die Standardroute für IPv6 löschen, können VMs über ihre IPv6-Adressen keine Verbindung zu VMs in anderen Regionen herstellen.

Subnetzrouten

Subnetzrouten definieren Pfade zu Ressourcen wie VMs und internen Load-Balancern in einem VPC-Netzwerk.

Jedes Subnetz hat mindestens eine Subnetzroute, deren Ziel dem primären IP-Bereich des Subnetzes entspricht. Wenn das Subnetz sekundäre IP-Bereiche hat, gibt es für jeden sekundären IP-Adressbereich eine entsprechende Subnetzroute. 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 identisch oder spezifischer als dieses Ziel ist (also eine längere Subnetzmaske hat).

Subnetzrouten haben immer die spezifischsten Ziele. Sie können selbst dann nicht durch andere Routen überschrieben werden, wenn eine andere Route eine höhere Priorität hat. Das liegt daran, dass Google Cloud bei der Auswahl einer Route die Zielspezifität berücksichtigt. Google Cloud verwendet 0 als Priorität für alle Subnetzrouten.

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

  • Wenn Sie ein Subnetz hinzufügen, erstellt Google Cloud eine entsprechende Subnetzroute für den primären IP-Adressbereich des Subnetzes.

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

Die Anzahl von Subnetzrouten in einem VPC-Netzwerk ist beschränkt durch die maximale Anzahl von (primären und sekundären) Subnetz-IP-Bereichen.

Statische Routen

Statische Routen werden mit Parametern für statische Routen definiert und unterstützen statische Routen mit nächstem Hop. Sie können statische Routen auf zwei Weisen erstellen:

Dynamische Routen

Dynamische Routen werden von Cloud Routern im VPC-Netzwerk verwaltet. Die Ziele stellen immer IP-Adressbereiche außerhalb Ihres VPC-Netzwerks dar, die von einem BGP-Peer empfangen wurden. Dynamische Routen werden verwendet von:

VPC-Netzwerke ignorieren alle Ziele, die Cloud Router erhalten, wenn die Ziele eines der folgenden Kriterien erfüllen:

  • Das Ziel stimmt genau mit einem Subnetz-IP-Adressbereich überein.

  • Das Ziel passt in einen Subnetz-IP-Adressbereich (hat also eine längere Subnetzmaske als dieser).

Das Ziel einer dynamischen Route kann jedoch den IP-Bereich eines Subnetzes enthalten (und eine kleinere Subnetzmaske als dieses haben). Wenn Sie beispielsweise einen Subnetz-IP-Bereich von 10.10.10.0/24 haben, können Sie eine dynamische Route mit dem Ziel 10.10.10.0/23 haben. Wenn die Ziel-IP-Adresse eines Pakets nicht im Ziel der Subnetzroute enthalten ist, wird das Paket an den nächsten Hop der dynamischen Route gesendet. Das breitestmögliche Ziel ist 0.0.0.0/0.

Peering-Subnetzrouten

Mit Peering-Subnetzrouten werden Pfade zu Ressourcen definiert. Dabei werden Subnetze in einem anderen VPC-Netzwerk verwendet, dessen Verbindung per VPC-Netzwerk-Peering hergestellt wurde. Das andere Netzwerk wird als Peer-VPC-Netzwerk bezeichnet.

Peer-Netzwerke teilen Subnetzrouten so:

  • Peer-Netzwerke exportieren ihre Subnetzrouten immer für alle primären und sekundären IP-Adressbereiche.

  • Peer-Netzwerke importieren Subnetzrouten automatisch, solange das Ziel der Route (Subnetz-IP-Adressbereich) keine privat verwendete öffentliche IP-Adresse ist. Sie können einen Peer konfigurieren, um die Subnetzrouten zu importieren, die privat verwendete öffentliche IP-Adressen verwenden.

  • Importierte Peering-Subnetzrouten können nur entfernt werden, wenn Sie das Peering deaktivieren. Dann werden alle importierten Peering-Subnetzrouten automatisch entfernt.

  • Google Cloud verhindert Konflikte in Subnetz-IP-Adressbereichen zwischen Peer-Netzwerken.

Die Gesamtzahl von Subnetzrouten in einem VPC-Netzwerk und Peering-Subnetzrouten, die aus allen Peer-Netzwerken importiert wurden, ist beschränkt durch die maximale Anzahl von (primären und sekundären) Subnetz-IP-Bereichen.

Benutzerdefinierte Peering-Routen

Sie können Peer-Netzwerke so konfigurieren, dass benutzerdefinierte Routen exportiert oder importiert werden. In diesem Kontext sind benutzerdefinierte Routen sowohl statische als auch dynamische Routen in einem VPC-Netzwerk.

Auch wenn ein VPC-Netzwerk für den Export seiner benutzerdefinierten Routen konfiguriert ist, werden folgende Routentypen ausgeschlossen:

Die Gesamtzahl von statischen und dynamischen Routen in einem VPC-Netzwerk sowie von benutzerdefinierten Peering-Routen, die aus allen Peer-Netzwerken importiert wurden, ist beschränkt durch:

  • Maximale Anzahl der statischen Routen in einer Peering-Gruppe
  • Maximale Anzahl der dynamischen Routen in einer Peering-Gruppe

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.

  • Subnetz- und Peering-Subnetzrouten gelten für alle Instanzen. Subnetzrouten und Peering-Subnetzrouten entsprechen Subnetzen in Ihrem VPC-Netzwerk sowie denen, die aus Peer-Netzwerken importiert wurden.

  • Die vom System generierte Standardroute gilt für alle Instanzen. Sie können die vom System generierte Standardroute nach Wunsch durch eine benutzerdefinierte statische Route ersetzen.

  • Benutzerdefinierte statische Routen gelten für alle Instanzen oder bestimmte Instanzen. Statische Routen mit einem Tag-Attribut gelten für Instanzen mit demselben Netzwerk-Tag. Wenn die Route kein Netzwerk-Tag hat, gilt sie 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 Hops 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. Mehr 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 ein VPC-Netzwerk den regionalen dynamischen Routingmodus verwendet, erstellen alle seine Cloud Router nur dynamische Routen für gelernte Präfixe in seiner lokalen Region. Wenn ein VPC-Netzwerk den globalen dynamischen Routingmodus verwendet, erstellen alle seine Cloud Router dynamische Routen für gelernte Präfixe in allen Regionen.

    • Cloud Router verwerfen automatisch gelernte Präfixe, die nicht zugänglichen nächsten Hops entsprechen (Cloud VPN-Tunnel oder Cloud Interconnect-Anhänge). 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 und Peering-Subnetzrouten werden zuerst berücksichtigt, da diese Routen die spezifischsten Ziele haben. Google Cloud berücksichtigt Peering-Subnetzrouten genauso wie lokale Subnetzrouten.

    • Wenn die Ziel-IP-Adresse für ein Paket im Ziel eines Subnetzes oder einer Peering-Subnetzroute enthalten ist:

      • Pakete werden an die interne IP-Adresse einer ausgeführten VM-Instanz oder eines konfigurierten internen Load-Balancers gesendet.

      • Pakete, die für eine angehaltene VM-Instanz bestimmt sind, werden gelöscht.

      • Pakete, die für eine interne IP-Adresse bestimmt sind, werden gelöscht, wenn keine Google Cloud-Ressource für die Verwendung der IP-Adresse konfiguriert wurde.

    • In Google Cloud können Sie keine benutzerdefinierte statische Route erstellen, die ein identisches oder spezifischeres Ziel hat als eine Subnetzroute oder eine Peering-Subnetzroute.

    • Cloud Router ignorieren gelernte Präfixe, die genau mit dem Ziel einer Subnetzroute oder einer Peering-Subnetzroute übereinstimmen.

    • Cloud Router ignorieren gelernte Präfixe, die in einer Subnetzroute oder einer Peering-Subnetzroute enthalten sind (also eine längere Subnetzmaske haben).

  2. Wenn das Paket nicht im Ziel einer Subnetzroute enthalten ist, sucht Google Cloud nach der statischen, dynamischen oder benutzerdefinierten Peering-Route mit dem spezifischsten Ziel. Zum Beispiel ist 10.240.1.0/24 ein spezifischeres Ziel als 10.240.0.0/16 für Pakete mit dem Ziel 10.240.1.4.

  3. Wenn mehrere Routen das gleiche spezifischste Ziel haben, nutzt Google Cloud folgendes Verfahren, um aus den Routenkandidaten eine auszuwählen: Routenkandidaten sind die statischen, dynamischen und benutzerdefinierten Peering-Routen, die das gleiche spezifischste Ziel haben.

    1. Wenn Ihr VPC-Netzwerk mit Peer-Netzwerken verbunden ist, löscht Google Cloud alle Routenkandidaten, die nicht aus einem einzelnen VPC-Netzwerk stammen.

      • Wenn in Ihrem lokalen VPC-Netzwerk ein oder mehrere Routenkandidaten vorhanden sind, ignoriert Google Cloud alle Routenkandidaten aus Peer-Netzwerken.

      • Falls keiner der Routenkandidaten in Ihrem lokalen VPC-Netzwerk, aber gleichzeitig in mehreren Peer-Netzwerken vorhanden ist, ignoriert Google Cloud alle Routenkandidaten mit Ausnahme derjenigen, die in einem der Peer-Netzwerke definiert sind. Google Cloud verwendet einen internen Algorithmus, um das einzelne Peer-Netzwerk auszuwählen. Dieser berücksichtigt dabei an dieser Stelle des Prozesses nicht die Routenpriorität. Wenn Sie eine Peering-Verbindung mit einem neuen Netzwerk herstellen oder die Verbindung zu einem vorhandenen Peer-Netzwerk trennen, hat dies möglicherweise Auswirkungen auf das VPC-Netzwerk, das von Google Cloud ausgewählt wird.

    2. In Google Cloud werden alle Routenkandidaten entfernt, mit Ausnahme derer, die die höchste Priorität haben. Wenn dies zu einer einzelnen verbleibenden Route führt, sendet Google Cloud das Paket an den nächsten Hop.

    3. Wenn mehrere Routenkandidaten dieselbe höchste Priorität haben, setzt Google Cloud das Löschen mithilfe des nächsten Hops und des Typs der Route fort. Wenn dies zu einer einzelnen verbleibenden Route führt, sendet Google Cloud das Paket an den nächsten Hop.

      1. Benutzerdefinierte statische Routen mit den nächsten Hops „Nächste Hop-Instanz“, „Nächste Hop-IP-Adresse“ oder „Nächster Hop-VPN-Tunnel“ sind am besten geeignet. Alle anderen Routenkandidaten werden gelöscht, wenn ein Routenkandidat vorhanden ist, der diesen Typ des nächsten Hops verwendet.

      2. Benutzerdefinierte dynamische Routen sind am zweitbesten geeignet.

      3. Benutzerdefinierte statische Routen mit den nächsten Hops „Interner TCP/UDP-Load-Balancer“ sind am drittbesten geeignet.

      4. Benutzerdefinierte statische Routen, die den nächsten Hop „Standard-Internetgateway“ verwenden, sind am wenigsten geeignet.

    4. Wenn mehrere Routen von den Routenkandidaten bleiben, existieren diese alle im selben VPC-Netzwerk, haben die gleiche höchste Priorität und haben denselben Routentyp oder verwenden denselben nächsten Hop-Typ. Google Cloud verteilt den Traffic so:

      • Wenn der nächste Hop kein interner TCP/UDP-Load-Balancer ist, verteilt Google Cloud Pakete auf die nächsten Hops der Routenkandidaten. Dabei wird ein 5-Tupel-Hash für Affinität verwendet und Equal Cost Multi Path (ECMP). Hash-Berechnungen werden für jedes Paket zum Sendezeitpunkt durchgeführt, basierend auf der Anzahl der Routenkandidaten in dieser Phase. Wenn sich die Anzahl von Routenkandidaten ändert, kann der Hash ein Paket mit demselben 5-Tupel-Hash an einen anderen nächsten Hop weiterleiten.

      • Wenn der nächste Hop ein interner TCP/UDP-Load-Balancer ist, verwendet Google Cloud einen internen Algorithmus, um einen einzelnen Load-Balancer als nächsten Hop auszuwählen, und ignoriert die anderen nächsten Hops, obwohl sie mit Routen der gleichen Priorität verknüpft sind. Weitere Informationen zu dieser Situation finden Sie unter Überlegungen speziell zu internen TCP/UDP-Load-Balancern als nächste Hops.

  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. Ziele müssen in CIDR-Notation angegeben werden. Sie können weder genau mit einem Subnetz-IP-Adressbereich übereinstimmen noch in einem Subnetz-IP-Adressbereich enthalten sein (also eine längere Subnetzmaske haben). Das Ziel einer statischen Route kann jedoch den IP-Bereich eines Subnetzes enthalten (und eine kleinere Subnetzmaske als dieses haben). Wenn Sie beispielsweise einen Subnetz-IP-Bereich von 10.10.10.0/24 haben, können Sie eine statische Route mit dem Ziel 10.10.10.0/23 haben. Wenn die Ziel-IP-Adresse eines Pakets nicht im Ziel der Subnetzroute enthalten ist, wird das Paket an den nächsten Hop der statischen Route gesendet. Das breitestmö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. Interne TCP/UDP-Load-Balancer mit nächstem Hop unterstützen keine Netzwerk-Tags.

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, und nur, wenn Sie die Route erstellen. Ob die VM Pakete verarbeiten oder weiterleiten kann, wird nicht geprüft. Wird die VM später gelöscht, aber nicht ersetzt, gilt die Route weiterhin, wodurch Pakete verloren gehen können.

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

  • Nächste Hop-IP-Adresse (next-hop-address): Sie können eine primäre interne IP-Adresse angeben, die einer Google Cloud-VM-Schnittstelle 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 primäre 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 einer beliebigen Quell-IP-Adresse weiterleiten. Wenn Sie die Weiterleitung konfigurieren möchten, aktivieren Sie die IP-Weiterleitung (can-ip-forward) pro VM, wenn Sie die VM erstellen. Aktivieren Sie für VMs, die automatisch als Teil einer verwalteten Instanzgruppe erstellt werden, die IP-Weiterleitung in der von der Instanzgruppe verwendeten Instanzvorlage. 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.

  • Wenn Sie Traffic an eine Instanz in einem freigegebenen VPC-Dienstprojekt weiterleiten möchten, verwenden Sie next-hop-address. Die Verwendung von next-hop-instance wird nicht unterstützt.

Überlegungen speziell zu internen TCP/UDP-Load-Balancern als nächste Hops

  • Auswirkungen des globalen Zugriffs. Benutzerdefinierte statische Routen, die die nächsten Hops eines internen TCP/UDP-Load-Balancers verwenden, werden in allen Regionen programmiert. Ob der nächste Hop verwendet werden kann, hängt von der globalen Zugriffseinstellung für den Load-Balancer ab. Wenn der globale Zugriff aktiviert ist, ist der nächste Hop des Load-Balancers in allen Regionen des VPC-Netzwerks zugänglich. Wenn der globale Zugriff deaktiviert ist, ist der nächste Hop des Load-Balancers nur in der Region des Load-Balancers zugänglich. Wenn der globale Zugriff deaktiviert ist, werden Pakete verworfen, die über den nächsten Hop eines internen TCP/UDP-Load-Balancers von einer anderen Region an eine Route gesendet werden.
  • Wenn alle Back-Ends fehlerhaft sind. Wenn alle Back-Ends eines internen TCP/UDP-Load-Balancers bei Systemdiagnosen fehlschlagen, sind die Routen, die diesen nächsten Hop verwenden, noch aktiv. Von der Route verarbeitete Pakete werden gemäß der Trafficverteilung an eines der Back-Ends des nächsten Hop-Load-Balancers gesendet.

  • Weiterleitungsregeln, die eine gemeinsame interne IP-Adresse verwenden (--purpose=SHARED_LOADBALANCER_VIP), werden nicht unterstützt. Ein interner TCP/UDP-Load-Balancer mit nächstem Hop und interne Weiterleitungsregeln des TCP/UDP-Load-Balancers mit einer gemeinsamen IP-Adresse schließen sich gegenseitig aus. Der interne TCP/UDP-Load-Balancer mit nächstem Hop muss eine IP-Adresse verwenden, die für die Weiterleitungsregel des Load-Balancers eindeutig ist, damit nur ein Back-End-Dienst (ein Load-Balancer) eindeutig referenziert wird. Es ist möglich, dass Weiterleitungsregeln, die eine gemeinsame interne IP-Adresse verwenden, auf verschiedene Back-End-Dienste verweisen (verschiedene interne TCP/UDP-Load-Balancer).

  • Gleiches Ziel und mehrere interne TCP/UDP-Load-Balancer als nächsten Hop Wenn Sie zwei oder mehr benutzerdefinierte statische Routen mit demselben Ziel und unterschiedlichen internen TCP/UDP-Load-Balancern als nächste Hops erstellen, verteilt Google Cloud den Traffic nie unter den Load-Balancern als nächste Hops mit ECMP. Wenn die Routen eindeutige Prioritäten haben, verwendet Google Cloud den internen TCP/UDP-Load-Balancer als nächsten Hop aus der Route mit der höchsten Priorität. Wenn die Routen dieselben Prioritäten haben, wählt Google Cloud trotzdem nur einen internen TCP/UDP-Load-Balancer als nächsten Hop aus. Wie in der folgenden Abbildung dargestellt, verwendet Google Cloud einen deterministischen internen Algorithmus, um eine Weiterleitungsregel als nächsten Hop (forwarding-rule-a) auszuwählen und andere Routen mit derselben Priorität zu ignorieren.

    Gleiches Ziel, unterschiedliche interne TCP/UDP-Load-Balancer als nächste Hops
    Gleiches Ziel, unterschiedliche interne TCP/UDP-Load-Balancer als nächste Hops
  • Mehrere Ziele und derselbe TCP-UDP-Load-Balancer für den nächsten Hop:

    Mit Instanz-Tags:

    Wenn Sie Instanz-Tags (auch Netzwerk-Tags genannt) verwenden, können Sie denselben internen TCP/UDP-Load-Balancer als nächsten Hop für mehrere benutzerdefinierte statische Routen mit demselben Ziel und derselben Priorität verwenden.

    Ohne Instanz-Tags: Ohne Instanz-Tags können Sie nicht mehrere benutzerdefinierte statische Routen mit derselben Kombination aus Ziel, Priorität und internem TCP/UDP-Load-Balancer als nächsten Hop erstellen. Beispielsweise können route-x, route-y und route-z erstellt werden, route-x-copy jedoch nicht.

    Beispielrouten mit einem gemeinsamen internen TCP/UDP-Load-Balancer als nächsten Hop
    Beispielrouten mit einem gemeinsamen internen TCP/UDP-Load-Balancer als nächsten Hop
  • Instanz-Tags.

    Sie können Instanz-Tags angeben (auch als Netzwerk-Tags bezeichnet), sodass die Route für den nächsten Hop nur für Clientinstanzen gilt, die mit dem Tag konfiguriert wurden. Dadurch können Sie auswählen, welche Clientinstanzen mit welcher getaggten Route für den nächsten Hop gefüllt werden und an welche Gruppe von Appliances der Traffic weitergeleitet werden soll.

    Sie müssen die verschiedenen Clientinstanzen nicht in separate VPC-Netzwerke unterteilen, die jeweils auf ihre bevorzugten internen TCP/UDP-Load-Balancer mit dem Front-End einer Reihe von Appliances verweisen.

  • Mehrere Routen für dasselbe Zielpräfix: Mit Instanz-Tags können Sie mehrere Routen zum selben Ziel mit unterschiedlichen internen Load-Balancern als nächste Hops angeben. Sie können für diese Zielrouten unterschiedliche Instanz-Tags oder unterschiedliche Prioritäten verwenden.

Überlegungen zu klassischen VPN-Tunneln mit nächstem Hop

Google Cloud berücksichtigt keine regionalen Entfernungen für Routen, die einen klassischen VPN-Tunnel mit nächstem Hop verwenden. Das Senden von Traffic an einen klassischen VPN-Tunnel mit nächstem Hop in einer anderen Region erhöht die Kosten für ausgehenden Traffic und führt zu Netzwerklatenz. Als Best Practice hat es sich bewährt, HA VPN-Tunnel oder klassische VPN-Tunnel mit dynamischem Routing zu verwenden.

Weitere Informationen

  • Mehr zum Erstellen und Verwalten von Routen erfahren 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.