Übersicht über Endpunkte für ausgehenden Traffic

Dieses Dokument bietet eine Übersicht über Cloud DNS-Endpunkte für ausgehenden Traffic. Endpunkte für ausgehenden Traffic können an Weiterleitungszonen oder Serverrichtlinien angehängt werden, um die direkte DNS-Abfrageweiterleitung von VPC-Netzwerken an externe und lokale DNS-Resolver über private IP-Adressen zu ermöglichen. Durch die Verwendung von Endpunkten für ausgehenden Traffic haben Sie eine detaillierte Kontrolle über den ausgehenden DNS-Traffic und können DNS-Auflösungsszenarien für Hybrid- und Multi-Cloud-Umgebungen besser umsetzen.

Informationen zum Erstellen, Aktualisieren und Verknüpfen von Endpunkten für ausgehenden Traffic mit Weiterleitungs zonen oder Serverrichtlinien finden Sie unter Endpunkte für ausgehenden Traffic erstellen und aktualisieren.

Funktionen von Endpunkten für ausgehenden Traffic

Mit Endpunkten für ausgehenden Traffic können Sie die Quell-IP-Adressen für ausgehenden DNS-Traffic steuern. So können Sie VPC-Netzwerk-spezifisches Verhalten ermöglichen, indem Sie jedem Netzwerk einen eindeutigen Bereich für ausgehenden Traffic zuweisen. Der eindeutige Bereich für ausgehenden Traffic überwindet die Routing-Einschränkungen des vorhandenen festen Weiterleitungs-Proxy-Bereichs.

GKE-Cluster übernehmen Endpunkte für ausgehenden Traffic automatisch, wenn sie externe Ziele mit dem Host-VPC-Netzwerk abfragen. Wenn das Host-VPC-Netzwerk für eine globale Cloud DNS-Standardweiterleitungszone oder eine Serverrichtlinie autorisiert ist, die mit Endpunkten für ausgehenden Traffic konfiguriert wurde, leiten Pods, die die VPC-DNS-Auflösung verwenden, ausgehende Abfragen automatisch über regionale Endpunkte für ausgehenden Traffic weiter. Es sind keine Änderungen auf Clusterebene oder zonale Weiterleitungszonen erforderlich.

Weitere Informationen zum Migrieren Ihrer vorhandenen DNS-Weiterleitungseinrichtung zu Endpunkten für ausgehenden Traffic finden Sie unter Vorhandene Cloud DNS-Weiterleitungseinrichtung zu Endpunkten für ausgehenden Traffic migrieren.

Architektur und Abfragerouting von Endpunkten für ausgehenden Traffic

Ein Endpunkt für ausgehenden Traffic wird in einem bestimmten VPC-Netzwerk erstellt und verwendet das Nur-Proxy-Subnetz dieses Netzwerks für seine Quell-IP-Adresse.

Wenn Sie Endpunkte für ausgehenden Traffic an Ihre Weiterleitungszonen oder Serverrichtlinien anhängen, versucht Cloud DNS zuerst, DNS-Abfragen über den Endpunkt für ausgehenden Traffic mit dem höchsten Rang weiterzuleiten. Dazu wird der vorhandene Algorithmus zur Zielrangfolge verwendet. Wenn dieser Endpunkt fehlerhaft ist, versucht Cloud DNS den Endpunkt mit dem nächsthöheren Rang. Der geografisch nächstgelegene Endpunkt für ausgehenden Traffic wird bevorzugt, aber nicht garantiert.

Der Ranking-Algorithmus für Zielserver wird automatisch ausgeführt und basiert auf dem vorhandenen Failover-Muster für Weiterleitungszonen: Auswahl der IP-Adresse mit der niedrigsten Latenz und Fehlerrate. Die folgenden Faktoren erhöhen den Rang eines Weiterleitungsziels:

  • Höhere Anzahl erfolgreicher DNS-Antworten, die vom Weiterleitungsziel verarbeitet wurden. Erfolgreiche DNS-Antworten umfassen auch NXDOMAIN-Antworten.
  • Niedrigere Latenz bei der Kommunikation mit dem Weiterleitungsziel.
  • Kürzere geografische Entfernung zum Endpunkt für ausgehenden Traffic. Wenn keine Daten zu Erfolg und Latenz verfügbar sind, wird das nächstgelegene Ziel bevorzugt.

Zum Schutz vor regionalen Ausfällen können Sie Endpunkte für ausgehenden Traffic in mindestens zwei Regionen konfigurieren, in denen Sie Compute-Arbeitslasten ausführen. Dieser Ansatz bietet Cloud DNS ein regionales Failover-Ziel und sorgt für eine minimale Abfragelatenz. Wenn Ihre Hybridverbindung nur in ausgewählten Regionen bereitgestellt wird, können Endpunkte in anderen Compute-Regionen trotzdem über diese Verbindungen Ihre lokalen Resolver erreichen.

Auch wenn sich der Endpunkt mit dem höchsten Rang in einer anderen Region befindet, leitet Cloud DNS Abfragen weiterhin an diesen Endpunkt weiter. Wenn beispielsweise ein Endpunkt in Region A nicht mehr verfügbar ist, wird der Traffic automatisch an einen fehlerfreien Endpunkt in Region B weitergeleitet. Wenn der Endpunkt in Region A wieder fehlerfrei ist, erkennt der Ranking-Algorithmus die verbesserte Leistung und bevorzugt ihn wieder für zukünftige Abfragen.

Sie können bis zu 10 Endpunkte für ausgehenden Traffic pro Projekt und Region haben. Bei Bedarf können Sie in der Google Cloud Konsole eine Kontingenterhöhung beantragen. An eine Weiterleitungszone oder Serverrichtlinie können bis zu 100 Endpunkte für ausgehenden Traffic angehängt werden.

Abfragen an regionale lokale Resolver weiterleiten

Cloud DNS garantiert nicht, dass der Traffic an den Endpunkt in derselben Region wie die ursprüngliche VM gesendet wird. Sie können jedoch Routingrichtlinien zur Standortbestimmung verwenden, um den Traffic an den nächstgelegenen Ziel-Nameserver weiterzuleiten. Obwohl Cloud DNS den Traffic bevorzugt an den Endpunkt für ausgehenden Traffic in der Region weiterleitet, die der ursprünglichen Abfrage und dem Ziel-Nameserver am nächsten ist, sind die Region des Ziel-Nameservers und die Region des Endpunkts für ausgehenden Traffic nicht eng miteinander verbunden. Unabhängig vom Standort wählt Cloud DNS den Endpunkt aus, der in der Vergangenheit die niedrigste Latenz aufwies.

Im Folgenden finden Sie eine allgemeine Übersicht über die Schritte, die Sie ausführen müssen, um Abfragen an regionale lokale Resolver weiterzuleiten:

  • Zone mit einer Richtlinie zur Standortbestimmung erstellen: Erstellen Sie eine neue Cloud DNS private Zone für einen FQDN, den Sie kontrollieren (z. B. onprem-resolvers.example.com) autorisiert für Ihr VPC-Netzwerk. Erstellen Sie in dieser Zone A-Einträge für die IP-Adressen Ihres lokalen DNS-Servers und wenden Sie eine Routingrichtlinie zur Standortbestimmung an. Konfigurieren Sie die Richtlinie so, dass Resolver-IPs für Abfragen zurückgegeben werden, die aus dieser bestimmten Region stammen. Geben Sie beispielsweise europäische Resolver-IPs für Abfragen zurück, die aus europäischen Google Cloud Regionen stammen.
  • FQDN als Weiterleitungsziel verwenden: Verwenden Sie in Ihrer Weiterleitungszone den FQDN den Sie gerade erstellt haben (onprem-resolvers.example.com) als Ziel-DNS Server.
  • Endpunkte für ausgehenden Traffic konfigurieren: Verknüpfen Sie Ihre regionalen Endpunkte für ausgehenden Traffic (z. B. einen in einer US-Region und einen in einer europäischen Region) mit dieser Weiterleitungs zone.

Wenn eine VM in einer Region eine Abfrage sendet, wird ein zweistufiger Routingprozess ausgeführt:

  • Endpunktauswahl: Cloud DNS wertet die Liste der Endpunkte für ausgehenden Traffic aus, die mit der Weiterleitungszone verknüpft sind, und wählt den besten Endpunkt aus. Für eine Abfrage von einer VM in Europa wird beispielsweise wahrscheinlich ein Endpunkt in Europa ausgewählt.
  • Zielauflösung: Der ausgewählte Endpunkt für ausgehenden Traffic löst den Ziel-FQDN (onprem-resolvers.example.com) auf. Da der Endpunkt für ausgehenden Traffic eine regionale Ressource ist, die sich in der angegebenen Region befindet, identifiziert die Richtlinie zur Standortbestimmung die Quelle der Abfrage als diese Region und gibt die spezifische IP Adresse zurück, die Sie für diese Region konfiguriert haben. Der Endpunkt für ausgehenden Traffic leitet die ursprüngliche Abfrage dann an die IP-Adresse des Ziel-DNS-Servers weiter.

Weitere Informationen finden Sie in der Anleitung Ausgehende DNS-Weiterleitung für Cloud DNS-FQDN.

Weiterleitung aus einer Region ohne lokalen Endpunkt in einem einzelnen VPC-Netzwerk

Ein Google Cloud VPC-Netzwerk ist eine globale Ressource, die Subnetze in mehreren Regionen enthalten kann. Wenn eine VM eine Abfrage aus einer Region sendet, in der Sie keinen Endpunkt für ausgehenden Traffic konfiguriert haben, ist die Weiterleitung trotzdem erfolgreich. Die Abfrage wird regionsübergreifend an den Endpunkt für ausgehenden Traffic mit dem höchsten Rang weitergeleitet, der sich im selben VPC-Netzwerk befindet und in der Weiterleitungszone oder Serverrichtlinie konfiguriert ist.

Weiterleitung aus mehreren VPC-Netzwerken in derselben Region mit Quell-IP-Isolation

Wenn Sie Abfragen aus mehreren VPC-Netzwerken in derselben Region weiterleiten müssen und der lokale Resolver für jedes VPC-Netzwerk eine eigene Quell-IP-Adresse sehen soll, gehen Sie so vor:

  1. Endpunkt für ausgehenden Traffic in jedem VPC-Netzwerk erstellen: Weitere Informationen finden Sie unter Endpunkt für ausgehenden Traffic erstellen.
  2. Weiterleitungszone oder Serverrichtlinie in jedem VPC-Netzwerk erstellen: Autorisieren Sie die Weiterleitungszone oder Serverrichtlinie nur für dieses VPC Netzwerk und verwenden Sie nur den Endpunkt für ausgehenden Traffic dieses VPC-Netzwerks.

Dadurch senden VMs in jedem VPC-Netzwerk Abfragen über den Endpunkt für ausgehenden Traffic in ihrem VPC-Netzwerk. Jeder Endpunkt leitet die Abfrage an den lokalen Resolver weiter. Das lokale Netzwerk sieht die Quell-IP-Adresse des Nur-Proxy-Subnetzes jedes VPC-Netzwerk und kann so unterschiedliche Konfigurationen für den Traffic der einzelnen Netzwerke anwenden.

Einheitliche Weiterleitung über verschiedene VPC-Netzwerke (Hub-and-Spoke)

Sie können eine Weiterleitungszone oder Serverrichtlinie so konfigurieren, dass ein Endpunkt für ausgehenden Traffic in einem anderen, zentralisierten VPC-Netzwerk (dem Hub) verwendet wird. Eine Netzwerkverbindung zwischen dem Hub-Netzwerk und dem VPC-Netzwerk, aus dem die Abfrage stammt (dem Spoke), ist nicht erforderlich, da Cloud DNS die Abfrageweiterleitung intern übernimmt.

Sie müssen eine Netzwerkverbindung zwischen dem Endpunkt für ausgehenden Traffic und den Weiterleitungszielen in Ihrer Weiterleitungszone oder Serverrichtlinie konfigurieren. Die Verbindung kann über Cloud Interconnect oder Cloud VPN hergestellt werden, um lokale Resolver zu erreichen. Mit VPC-Netzwerk-Peering können Sie Weiterleitungsziele in einem anderen VPC-Netzwerk erreichen.

  1. Erstellen Sie einen Endpunkt für ausgehenden Traffic im Hub-VPC-Netzwerk.
  2. Erstellen Sie eine Weiterleitungszone oder Serverrichtlinie im Spoke-VPC-Netzwerk und konfigurieren Sie sie so, dass der Endpunkt für ausgehenden Traffic des Hub-Netzwerks verwendet wird.

Die VMs in den Spoke-VPC-Netzwerken senden Abfragen über den Endpunkt für ausgehenden Traffic im Hub-VPC-Netzwerk. Der Endpunkt leitet die Abfrage an den lokalen Resolver weiter.

Unterstützung für freigegebene VPC

Endpunkte für ausgehenden Traffic unterstützen Bereitstellungen mit freigegebene VPC. Der Endpunkt und das zugehörige Nur-Proxy-Subnetz werden zentral im Hostprojekt erstellt. Dienstprojekte können dann private Weiterleitungszonen oder Serverrichtlinien erstellen und sie projektübergreifend an den zentralisierten Endpunkt für ausgehenden Traffic im Hostprojekt binden. Dazu ist die Berechtigung dns.outboundEndpoints.bindPrivateDNSZone oder dns.outboundEndpoints.bindPrivateDNSPolicy für das Hostprojekt erforderlich.

Netzwerkressourcen verwalten, die mit Endpunkten für ausgehenden Traffic verknüpft sind

Cloud DNS-Endpunkte für ausgehenden Traffic erzwingen strenge Lebenszyklusabhängigkeiten mit den zugrunde liegenden VPC-Netzwerken und Subnetzen, um Produktions-DNS-Traffic vor versehentlichen Infrastrukturänderungen wie Löschungen oder Änderungen zu schützen.

Nur-Proxy-Subnetz oder VPC-Netzwerk löschen, wenn es von einem Endpunkt für ausgehenden Traffic verwendet wird

Ein Nur-Proxy-Subnetz oder VPC-Netzwerk, das aktiv von einem Endpunkt für ausgehenden Traffic verwendet wird, ist vor dem Löschen geschützt, um Ausfälle zu vermeiden. Wenn Sie versuchen, diese Ressourcen zu löschen, tritt ein Fehler auf. Wenn Sie diese Ressourcen löschen möchten, müssen Sie die folgenden Schritte in der angegebenen Reihenfolge ausführen:

  1. Cloud DNS-Konfiguration aktualisieren: Bearbeiten Sie alle Weiterleitungszonen oder Serverrichtlinien, die den Endpunkt für ausgehenden Traffic verwenden, und entfernen Sie ihn aus der Konfiguration, damit er nicht mehr verwendet wird.
  2. Endpunkt für ausgehenden Traffic löschen: Nachdem der Endpunkt nicht mehr verwendet wird, können Sie ihn löschen. Dadurch wird die Abhängigkeit vom Nur-Proxy-Subnetz aufgehoben.
  3. Nur-Proxy-Subnetz löschen: Nachdem Sie bestätigt haben, dass es von keinen anderen Ressourcen verwendet wird , löschen Sie das Nur-Proxy-Subnetz.
  4. VPC-Netzwerk löschen: Sobald alle anderen VPC Abhängigkeiten entfernt wurden, können Sie das VPC-Netzwerk löschen.

Subnetz ändern

Sie können ein Nur-Proxy-Subnetz nicht direkt ändern, wenn es aktiv von einem Endpunkt für ausgehenden Traffic verwendet wird. Diese Einschränkung verhindert, dass Sie wichtige Eigenschaften wie den IP-Adressbereich bearbeiten, was Dienstausfälle vermeiden kann. Wenn Sie das Subnetz ändern möchten, müssen Sie die vorhandenen Richtlinien befolgen und zuerst zu einem neuen Subnetz migrieren.

So ändern Sie ein Subnetz, das von einem Endpunkt für ausgehenden Traffic verwendet wird:

  1. Sicherungssubnetz erstellen: Erstellen Sie ein neues Nur-Proxy-Subnetz im selben VPC-Netzwerk und in derselben Region. Sie müssen die Rolle dieses Subnetzes beim Erstellen auf BACKUP festlegen.
  2. Neues Subnetz aktivieren: Aktualisieren Sie die Rolle des neuen Subnetzes auf ACTIVE. Dadurch wird die Rolle des ursprünglichen Subnetzes automatisch auf BACKUP festgelegt und aktive Verbindungen werden daraus entfernt.
  3. Auf Verbindungsausgleich warten: Warten Sie, bis der Vorgang zum Verbindungsausgleich abgeschlossen ist.
  4. Altes Subnetz löschen: Sie können das ursprüngliche Subnetz jetzt löschen, sobald es die BACKUP Rolle hat und keine aktiven Verbindungen mehr vorhanden sind.

Vorhersagbare dedizierte Quell-IP für lokale Firewalls

Wenn Ihre lokalen DNS-Firewalls einen dedizierten und vorhersagbaren Quell-IP-Adressbereich erfordern, der auf DNS-Traffic beschränkt ist, empfehlen wir die folgende Architektur:

  • In einem dedizierten VPC-Netzwerk für ausgehenden Traffic bereitstellen: Erstellen Sie ein dediziertes VPC-Netzwerk mit einem regulären Subnetz (für die IP-Adresse des Endpunkts für ausgehenden Traffic) und einem regionalen Nur-Proxy-Subnetz, das ausschließlich für Cloud DNS reserviert ist (--purpose=REGIONAL_MANAGED_PROXY und --role=ACTIVE).
  • Anwendungs-VPC-Netzwerke isolieren:Stellen Sie kein Peering oder Routing Ihrer Anwendungs-VPC-Netzwerke zu diesem dedizierten Netzwerk für ausgehenden Traffic ein. Cloud DNS leitet Abfragen intern in der Google Cloud Infrastruktur weiter, sodass keine direkte Netzwerkverbindung zwischen diesen VPC Netzwerken erforderlich ist.
  • Dediziertes VPC-Netzwerk für ausgehenden Traffic mit externen Weiterleitungszielen verbinden: Konfigurieren Sie die Verbindung nur zwischen dem dedizierten VPC-Netzwerk für ausgehenden Traffic und Ihren externen oder lokalen Ziel-Nameservern. Stellen Sie diesen Pfad mit den folgenden Methoden her:
    • VPC-Netzwerk-Peering zu einer vorhandenen Transit-VPC: Dies ist der empfohlene und kostengünstigste Ansatz. Wenn Ihre Organisation bereits ein zentrales Transit-VPC-Netzwerk mit Cloud Interconnect oder Cloud VPN zu lokalen Netzwerken hat, stellen Sie Peering zwischen dem dedizierten DNS-VPC-Netzwerk und diesem Transit-Hub ein. Dieser Ansatz vermeidet die Bereitstellung redundanter Hybridverbindungen und minimiert die Kosten.
    • Direkte Hybridverbindung: Dedicated Interconnect, Cross-Cloud Interconnect oder Cloud VPN, das direkt im dedizierten DNS-VPC-Netzwerk endet.

Beschränkungen

Für Endpunkte für ausgehenden Traffic gelten die folgenden Einschränkungen:

  • Quell-IP- und Subnetzfreigabe auf Ressourcen in derselben Region beschränkt: Endpunkte für ausgehenden Traffic weisen Quell-IP-Bereiche aus dem regionalen Nur-Proxy- Subnetz des VPC-Netzwerk zu, an das sie angehängt sind. In Standardbereitstellungen kann dieses Nur-Proxy-Subnetz mit anderen regionalen Ressourcen wie regionalen Application Load Balancern geteilt werden.

  • Direktes Peering zu Nur-Proxy-Subnetzen wird nicht unterstützt: Sie können kein direktes Peering mit einem Nur-Proxy-Subnetz einrichten. Die Netzwerkverbindung zu externen Nameservern muss über das Standard-VPC-Routing wie Cloud Interconnect, Cloud VPN oder VPC-Netzwerk-Peering hergestellt werden.

  • Nur IPv4-Unterstützung: Die Quell-IP-Adresse eines Endpunkts für ausgehenden Traffic ist nur IPv4 und Abfragen können nur an IPv4-Ziele oder FQDN Weiterleitungsziele in Weiterleitungszonen weitergeleitet werden, die in IPv4-Adressen aufgelöst werden.

  • Das Binden von Endpunkten für ausgehenden Traffic an ein Netzwerk über Projektgrenzen hinweg wird nicht unterstützt: Das Erstellen eines Endpunkts für ausgehenden Traffic in einem Dienstprojekt, das an das gemeinsam genutzte VPC-Netzwerk eines Host projekts angehängt ist, wird nicht unterstützt. Endpunkte für ausgehenden Traffic müssen sich im selben Projekt wie das VPC-Netzwerk und das Subnetz befinden, an das sie angehängt sind.

  • Auf private Ziele beschränkt: Endpunkte für ausgehenden Traffic unterstützen nur die Weiterleitung an private Ziele und können nicht als Egress-Proxy oder statischer Quell-IP-Anker für DNS-Traffic im öffentlichen Internet verwendet werden. Abfragen an Ziele im öffentlichen Internet werden direkt über den verteilten Anycast-Edge von Google aufgelöst, um die Latenz zu minimieren und Abhängigkeiten von Cloud NAT zu vermeiden.

  • Regionaler Bereich: Endpunkte für ausgehenden Traffic sind regionale Ressourcen. Sie müssen Endpunkte in jeder Region erstellen, in der Sie sie verwenden möchten.

  • Nur ein Weiterleitungsmechanismus: Der Weiterleitungsmechanismus (entweder der Standardbereich 35.199.192.0/19 oder Endpunkte für ausgehenden Traffic) wird auf Ebene der Weiterleitungszone oder Serverrichtlinie konfiguriert. Sie können jedoch nicht beide Methoden gleichzeitig für dieselbe Zone oder Richtlinie verwenden.

Nächste Schritte