Übersicht über Endpunkte für ausgehenden Traffic

Dieses Dokument bietet eine Übersicht über ausgehende Cloud DNS-Endpunkte. Endpunkte für ausgehenden Traffic können an Weiterleitungszonen oder Serverrichtlinien angehängt werden, um die direkte Weiterleitung von DNS-Abfragen von VPC-Netzwerken an externe und lokale DNS-Resolver über private IP-Adressen zu ermöglichen. Die Verwendung von ausgehenden Endpunkten ermöglicht eine detaillierte Kontrolle über den ausgehenden DNS-Traffic und verbessert die Möglichkeit, DNS-Auflösungsanwendungsfälle für Hybrid- und Multi-Cloud-Umgebungen zu entsperren.

Informationen zum Erstellen, Aktualisieren und Verknüpfen von Endpunkten für ausgehenden Traffic mit Weiterleitungszonen 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 ein VPC-netzwerkspezifisches Verhalten aktivieren, 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 Weiterleitungsproxy-Bereichs.

GKE-Cluster übernehmen automatisch ausgehende Endpunkte, wenn externe Ziele mit dem Host-VPC-Netzwerk abgefragt werden. Wenn das Host-VPC-Netzwerk für eine standardmäßige globale Cloud DNS-Weiterleitungszone oder eine Serverrichtlinie autorisiert ist, die mit Endpunkten für ausgehenden Traffic konfiguriert ist, leiten Pods, die die VPC-DNS-Auflösung verwenden, ausgehende Abfragen automatisch über regionale Endpunkte für ausgehenden Traffic weiter, ohne dass Änderungen auf Clusterebene oder zonale Weiterleitungszonen erforderlich sind.

Weitere Informationen zum Migrieren Ihrer vorhandenen DNS-Weiterleitungskonfiguration zu ausgehenden Endpunkten finden Sie unter Vorhandene Cloud DNS-Weiterleitungskonfiguration zu ausgehenden Endpunkten migrieren.

Architektur und Abfragerouting für Endpunkte für ausgehenden Traffic

Ein ausgehender Endpunkt wird in einem bestimmten VPC-Netzwerk erstellt (mit einem regulären Subnetz in der Zielregion für die interne IP-Adresse des Endpunkts) und verwendet das regionale 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 am höchsten eingestuften Endpunkt für ausgehenden Traffic weiterzuleiten. Dazu wird der vorhandene Algorithmus für die Zielrangfolge verwendet. Wenn dieser Endpunkt fehlerhaft ist, versucht Cloud DNS den nächsten Endpunkt mit dem höchsten Rang. Der geografisch am nächsten gelegene 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 – IP-Auswahl mit der niedrigsten Latenz und Fehlerrate. Die folgenden Faktoren erhöhen das Ranking eines Weiterleitungsziels:

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

Zum Schutz vor regionalen Ausfällen können Sie ausgehende Endpunkte in mindestens zwei Regionen konfigurieren, in denen Sie Rechenarbeitslasten ausführen. Dieser Ansatz bietet Cloud DNS ein regionales Failover-Ziel und sorgt für eine minimale Abfragelatenz. Wenn Ihre Hybridkonnektivität nur in ausgewählten Regionen bereitgestellt wird, können Endpunkte in anderen Compute-Regionen weiterhin über diese Verbindungen geleitet werden, um Ihre lokalen Resolver zu erreichen.

Auch wenn sich der am höchsten eingestufte Endpunkt 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 anstehende Abfragen.

Sie können bis zu 10 Endpunkte für ausgehenden Traffic pro Projekt und Region und bis zu 100 Endpunkte für ausgehenden Traffic pro Weiterleitungszone oder Serverrichtlinie haben.

Abfragen an regionale lokale Resolver weiterleiten

Cloud DNS garantiert nicht, dass Traffic an den Endpunkt in derselben Region wie die ursprüngliche VM gesendet wird. Sie können jedoch Routingrichtlinien zur Standortbestimmung verwenden, um 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 gekoppelt. Unabhängig vom Standort wählt Cloud DNS den Endpunkt aus, der in der Vergangenheit die niedrigste Latenz hatte.

Im Folgenden finden Sie eine allgemeine Übersicht darüber, was Sie tun müssen, um Abfragen an regionale lokale Resolver weiterzuleiten:

  • Zone mit einer Standortrichtlinie erstellen: Erstellen Sie eine neue private Cloud DNS-Zone für einen von Ihnen kontrollierten FQDN (z. B. onprem-resolvers.example.com), der für Ihr VPC-Netzwerk autorisiert ist. Erstellen Sie in dieser Zone A-Einträge für die IP-Adressen Ihrer lokalen DNS-Server und wenden Sie eine Routingrichtlinie zur Standortbestimmung an. Konfigurieren Sie die Richtlinie so, dass Resolver-IP-Adressen für Abfragen aus dieser bestimmten Region zurückgegeben werden. Beispiel: Für Abfragen aus europäischen Google Cloud -Regionen werden europäische Resolver-IP-Adressen zurückgegeben.
  • FQDN als Weiterleitungsziel verwenden: Verwenden Sie in Ihrer Weiterleitungszone den gerade erstellten FQDN (onprem-resolvers.example.com) als Ziel-DNS-Server.
  • Ausgehende Endpunkte konfigurieren: Verknüpfen Sie Ihre regionalen ausgehenden Endpunkte (z. B. einen in einer US-Region und einen in einer europäischen Region) mit dieser Weiterleitungszone.

Wenn eine VM in einer Region eine Abfrage stellt, folgt das System einem zweistufigen Routingprozess:

  • Endpunktauswahl: Cloud DNS wertet die Liste der ausgehenden Endpunkte aus, die der Weiterleitungszone zugeordnet sind, und wählt den besten Endpunkt aus. Beispielsweise wird für eine Abfrage von einer VM in Europa wahrscheinlich ein Endpunkt in Europa ausgewählt.
  • DNS-Auflösung des Ziels: Cloud DNS löst den Ziel-FQDN (onprem-resolvers.example.com) für die Region des Ursprungs der Abfrage auf. Cloud DNS leitet die ursprüngliche Abfrage dann über den ausgewählten ausgehenden Endpunkt an die aufgelöste DNS-Server-IP-Adresse weiter. Die Standortrichtlinie identifiziert die Quelle der Abfrage als diese Region und gibt die spezifische IP-Adresse zurück, die Sie für diese Region konfiguriert haben.

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

Weiterleitung von 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, wird die Weiterleitung trotzdem erfolgreich ausgeführt. Die Abfrage wird regionsübergreifend an den am höchsten eingestuften verfügbaren Endpunkt für ausgehenden Traffic weitergeleitet, der sich im selben VPC-Netzwerk befindet und in der Weiterleitungszone oder Serverrichtlinie konfiguriert ist.

Weiterleitung von mehreren VPC-Netzwerken in derselben Region mit Quell-IP-Isolierung

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

  1. Erstellen Sie in jedem VPC-Netzwerk einen Endpunkt für ausgehenden Traffic: Weitere Informationen finden Sie unter Endpunkt für ausgehenden Traffic erstellen.
  2. Erstellen Sie in jedem VPC-Netzwerk eine Weiterleitungszone oder Serverrichtlinie: 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.

Diese Aktion führt dazu, dass VMs in jedem VPC-Netzwerk Abfragen über den ausgehenden Endpunkt in ihrem VPC-Netzwerk senden. 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, sodass es für den Traffic jedes Netzwerks unterschiedliche Konfigurationen anwenden kann.

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, von dem die Abfrage stammt (dem Spoke), ist nicht erforderlich, da Cloud DNS die Abfrageweiterleitung intern verarbeitet.

Sie müssen die 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. VPC-Netzwerk-Peering kann verwendet werden, um Weiterleitungsziele in einem anderen VPC-Netzwerk zu 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 ausgehenden Endpunkt im Hub-VPC-Netzwerk. Der Endpunkt leitet die Abfrage an den lokalen Resolver weiter.

Unterstützung für freigegebene VPC

Ausgehende Endpunkte unterstützen Bereitstellungen freigegebene VPC. Der Endpunkt, sein reguläres Subnetz und das zugehörige Nur-Proxy-Subnetz werden zentral im Hostprojekt erstellt. Dienstprojekte können Weiterleitungszonen oder Serverrichtlinien übernehmen, die im Hostprojekt erstellt wurden, oder eigene private Weiterleitungszonen oder Serverrichtlinien erstellen und diese projektübergreifend an den zentralisierten Endpunkt für ausgehenden Traffic im Hostprojekt binden (erfordert dns.outboundEndpoints.bindPrivateDNSZone oder dns.outboundEndpoints.bindPrivateDNSPolicy im Hostprojekt).

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 den DNS-Produktionstraffic vor versehentlichen Infrastrukturänderungen wie Löschungen oder Änderungen zu schützen.

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

Ein reguläres Subnetz, ein Nur-Proxy-Subnetz oder ein VPC-Netzwerk, das aktiv von einem ausgehenden Endpunkt verwendet wird, ist vor dem Löschen geschützt, um Ausfälle zu vermeiden. Bei einem entsprechenden Versuch wird ein Fehler ausgegeben. Wenn Sie diese Ressourcen löschen möchten, müssen Sie die folgenden Schritte in der genauen 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: Wenn der Endpunkt nicht mehr verwendet wird, können Sie ihn löschen. Durch diese Aktion wird die Abhängigkeit vom regulären Subnetz und vom Nur-Proxy-Subnetz aufgehoben.
  3. Subnetze löschen: Nachdem Sie bestätigt haben, dass keine anderen Ressourcen die Subnetze verwenden, löschen Sie die Nur-Proxy- und regulären Subnetze.
  4. VPC-Netzwerk löschen: Nachdem alle anderen VPC-Abhängigkeiten entfernt wurden, können Sie das VPC-Netzwerk löschen.

Subnetze ändern

Sie können ein Nur-Proxy-Subnetz nicht direkt ändern, wenn es von einem Endpunkt für ausgehenden Traffic aktiv verwendet wird. Durch diese Einschränkung können Sie wichtige Attribute wie den IP-Adressbereich nicht bearbeiten, was Dienstausfälle verhindert. 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 das ursprüngliche Subnetz automatisch auf die Rolle BACKUP gesetzt und aktive Verbindungen werden daraus entfernt.
  3. Auf Verbindungsausgleich warten: Warten Sie, bis der Verbindungsausgleich abgeschlossen ist.
  4. Altes Subnetz löschen: Sie können das ursprüngliche Subnetz jetzt löschen, sobald es die Rolle BACKUP hat und keine aktiven Verbindungen mehr bestehen.

Vorhersehbarkeit dedizierter Quell-IP-Adressen für lokale Firewalls

Wenn Ihre lokalen DNS-Firewalls einen dedizierten und vorhersehbaren Quell-IP-Adressbereich erfordern, der vom DNS-Traffic isoliert 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 ausgehenden Endpunkts) 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: Führen Sie kein Peering oder Routing Ihrer Anwendungs-VPC-Netzwerke zu diesem dedizierten Netzwerk für ausgehenden Traffic durch. Cloud DNS leitet Abfragen intern innerhalb 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. Richten Sie diesen Pfad mit Folgendem ein:
    • VPC-Netzwerk-Peering mit einem vorhandenen Transit-VPC: Dies ist der empfohlene Ansatz und die kostengünstigste Methode. Wenn Ihre Organisation bereits ein zentrales Transit-VPC-Netzwerk mit Cloud Interconnect oder Cloud VPN zu lokalen Netzwerken hat, erstellen Sie ein Peering zwischen dem dedizierten DNS-VPC-Netzwerk und diesem Transit-Hub. So vermeiden Sie die Bereitstellung redundanter Hybridschaltungen und minimieren die Kosten.
    • Direkte Hybridkonnektivität: 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: Ausgehende Endpunkte weisen Quell-IP-Bereiche aus dem regionalen Nur-Proxy-Subnetz des VPC-Netzwerk zu, mit dem sie verbunden sind. In Standardbereitstellungen kann dieses Nur-Proxy-Subnetz mit anderen regionalen Ressourcen wie regionalen Application Load Balancern geteilt werden.

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

  • Nur IPv4-Unterstützung: Die Quell-IP-Adresse eines ausgehenden Endpunkts 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 ausgehenden Endpunkten an ein Netzwerk über Projekte hinweg wird nicht unterstützt: Das Erstellen eines ausgehenden Endpunkts in einem Dienstprojekt, das an das gemeinsam genutzte VPC-Netzwerk eines Hostprojekts angehängt ist, wird nicht unterstützt. Ausgehende Endpunkte müssen sich im selben Projekt wie das VPC-Netzwerk und das Subnetz befinden, mit dem sie verbunden sind.

  • Auf private Ziele beschränkt: Ausgehende Endpunkte unterstützen nur die Weiterleitung an private Ziele (einschließlich RFC 1918, RFC 6598 und privat weitergeleitete Adressen außerhalb von RFC 1918, die mit --private-forward-targets oder forwardingPath: "private" konfiguriert sind). Sie können nicht als Proxy für ausgehenden Traffic oder als statischer Quell-IP-Anker für öffentlichen Internet-DNS-Traffic verwendet werden. Abfragen an öffentliche Internetziele werden direkt über den verteilten Anycast-Edge von Google aufgelöst, um die Latenz zu minimieren und Cloud NAT-Abhängigkeiten 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: Ihr Weiterleitungsmechanismus (entweder der Standardbereich 35.199.192.0/19 oder Endpunkte für ausgehenden Traffic) wird auf der Ebene der Weiterleitungszone oder der Serverrichtlinie konfiguriert. Sie können jedoch nicht beide Methoden gleichzeitig für dieselbe Zone oder Richtlinie verwenden.

Nächste Schritte