Best Practices für das DNS

Dieses Dokument enthält Best Practices für folgende Bereiche:

Einführung

Es ist sowohl für Menschen als auch für Anwendungen einfacher, Anwendungen und Dienste mithilfe des Domain Name System (DNS) zu adressieren. Die Namen lassen sich leichter merken und bieten mehr Flexibilität als IP-Adressen. In einer Hybridumgebung, die aus lokalen Plattformen und einer oder mehreren Cloud-Plattformen besteht, muss häufig umgebungsübergreifend auf DNS-Einträge für interne Ressourcen zugegriffen werden. Traditionell werden lokale DNS-Einträge manuell über einen autoritativen DNS-Server verwaltet, z. B. BIND in UNIX- oder Linux-Umgebungen oder Active Directory in Microsoft Windows-Umgebungen. In diesem Artikel werden Best Practices für die Weiterleitung privater DNS-Anfragen zwischen Umgebungen beschrieben, damit Dienste sowohl von lokalen Umgebungen als auch innerhalb von Google Cloud adressiert werden können.

Allgemeine Grundsätze

Informationen zu DNS-Konzepten in Google Cloud

Wenn Sie DNS in Google Cloud verwenden, müssen Sie die verschiedenen Systeme und Dienste kennen, die in Google Cloud für die DNS-Auflösung und die Domainnamen verfügbar sind:

  • Das interne DNS ist ein Dienst, der automatisch DNS-Namen für virtuelle Maschinen und interne Load-Balancer in Compute Engine erstellt.
  • Cloud DNS ist ein Dienst, der DNS-Zonenbereitstellung mit niedriger Latenz und Hochverfügbarkeit bietet. Dieser Dienst kann als autoritativer DNS-Server für öffentliche Zonen verwendet werden, die im Internet sichtbar sind, oder für private Zonen, die nur innerhalb Ihres Netzwerks sichtbar sind. Weitere Informationen finden Sie in der Übersicht zu Cloud DNS.
  • Managed Service for Microsoft Active Directory ist ein hochverfügbarer, gehärteter Dienst, der Microsoft Active Directory einschließlich eines Domaincontrollers ausführt.
  • Das öffentliche DNS ist ein Google-Dienst, der nicht Teil von Google Cloud ist und als offener, rekursiver DNS-Resolver dient.
  • Google Domains ist ein Domain-Registrator für den Erwerb, die Übertragung oder die Verwaltung von Domains. Dieser Google-Dienst ist nicht Teil von Google Cloud.

Stakeholder, Tools und Prozesse bestimmen

Für eine DNS-Strategie in einer Hybridumgebung ist es wichtig, dass Sie sich zuerst mit Ihrer aktuellen Architektur vertraut machen und mit allen Stakeholdern Kontakt aufnehmen. Gehen Sie so vor:

  • Ermitteln und kontaktieren Sie den Administrator der Unternehmens-DNS-Server Ihrer Organisation. Bitten Sie ihn um die Angaben zu den Konfigurationen, die Sie brauchen, um Ihre lokale Konfiguration einer geeigneten Architektur in Google Cloud zuzuordnen. Weitere Informationen zu Methoden für den Zugriff auf Google Cloud-DNS-Einträge finden Sie unter Bedingte Weiterleitung für den lokalen Zugriff auf DNS-Einträge verwenden.
  • Machen Sie sich mit der aktuellen DNS-Software vertraut und ermitteln Sie die Domainnamen, die in Ihrer Organisation privat verwendet werden.
  • Ermitteln Sie Kontaktpersonen im Netzwerkteam, die dafür sorgen können, dass Traffic korrekt an Cloud DNS-Server weitergeleitet wird.
  • Machen Sie sich mit Ihrer hybriden Konnektivitätsstrategie sowie mit Hybrid- und Multi-Cloud-Mustern und -Verfahrensweisen vertraut.

Einfache und einheitliche Namenskonvention erstellen

Legen Sie eine Namenskonvention fest, die in Ihrer gesamten Organisation einheitlich und leicht zu merken ist. Angenommen, Ihre Organisation verwendet example.com als Domainnamen der zweiten Ebene sowie als Domain für öffentliche Ressourcen (z. B. www.example.com). Der Ort, an dem die öffentlichen Zonen gehostet werden, ist für dieses Dokument nicht von Bedeutung, da es hier um die Migration privater Zonen geht.

Für die lokale Benennung von Unternehmensressourcen stehen folgende Muster zur Auswahl:

  • Getrennte Domainnamen für lokale Server und für Google Cloud. Bei diesem Muster wird für Ihre verschiedenen Umgebungen eine separate Domain verwendet, z. B. corp.example.com für Ihre lokalen Server und gcp.example.com für alle Ressourcen in Google Cloud. Wenn Sie andere öffentliche Cloud-Umgebungen verwenden, können diese jeweils eine eigene Subdomain haben. Dies ist das bevorzugte Muster, da damit Anfragen zwischen verschiedenen Umgebungen problemlos weitergeleitet werden können.

    Sie können auch vollkommen getrennte Domainnamen wie example.com und example.cloud verwenden.

  • Die Google Cloud-Domain als Subdomain der Domain, die lokale Server enthält. Bei Verwendung der Domain example.com kann die lokale Umgebung corp.example.com und Google Cloud die Subdomain gcp.corp.example.com nutzen. Dies ist ein gängiges Muster, wenn die meisten Ressourcen vor Ort verbleiben.

  • Die lokale Domain als Subdomain der Domain, die Google Cloud-Einträge enthält. Bei Verwendung der Domain example.com kann Google Cloud corp.example.com und die lokale Umgebung dc.corp.example.com nutzen. Dies ist ein eher ungewöhnliches Muster, kann aber für Digital-Native-Organisationen sinnvoll sein, die lokal nur wenige Ressourcen haben.

  • Die gleiche Domain für Google Cloud und die lokale Umgebung. In diesem Fall verwenden sowohl Google Cloud als auch die lokale Umgebung Ressourcen über die Domain corp.example.com. Dieses Muster sollten Sie vermeiden, da es die Verwaltung von Einträgen in einer Hybridumgebung erheblich erschwert. Das Muster ist nur sinnvoll, wenn Sie ein einziges autoritatives DNS-System verwenden.

Im Folgenden werden diesen Domainnamen verwendet:

  • example.com als Domainname für Ihre öffentlichen Einträge (unabhängig davon, wo sie gehostet werden).
  • corp.example.com als Zone, die von Ihrem lokalen DNS-Server gehostet wird. Diese Zone hostet Einträge Ihrer lokalen Ressourcen.
  • gcp.example.com als private verwaltete Cloud DNS-Zone, die Einträge für Ihre Google Cloud-Ressourcen hostet.

Das folgende Diagramm zeigt diese Anordnung:

Beispiel für die Konfiguration eines Domainnamens (zum Vergrößern klicken)
Beispiel für die Konfiguration eines Domainnamens (zum Vergrößern klicken)

Zum Benennen von Ressourcen in Ihrem VPC-Netzwerk können Sie sich an Richtlinien wie unter Best Practices und Referenzarchitekturen für das VPC-Design orientieren.

Ort der DNS-Auflösung auswählen

In einer Hybridumgebung kann die DNS-Auflösung an verschiedenen Orten ausgeführt werden. Sie haben folgende Möglichkeiten:

  • Sie verwenden einen hybriden Ansatz mit zwei autoritativen DNS-Systemen.
  • Sie führen die DNS-Auflösung weiterhin lokal aus.
  • Sie verschieben die gesamte DNS-Auflösung nach Cloud DNS.

Da wir den hybriden Ansatz empfehlen, steht dieser im Mittelpunkt dieses Dokuments. Der Vollständigkeit halber werden auch die alternativen Ansätze kurz beschrieben.

Hybriden Ansatz mit zwei autoritativen DNS-Systemen verwenden

Wir empfehlen einen Hybridansatz mit zwei autoritativen DNS-Systemen. Bei diesem Ansatz gilt Folgendes:

  • Die autoritative DNS-Auflösung für Ihre private Google Cloud-Umgebung wird von Cloud DNS übernommen.
  • Die autoritative DNS-Auflösung für lokale Ressourcen wird von vorhandenen DNS-Servern lokal gehostet.

Das folgende Diagramm zeigt diese Anordnung:

Hybridarchitektur mit zwei autoritativen DNS-Systemen (zum Vergrößern klicken)
Hybridarchitektur mit zwei autoritativen DNS-Systemen (zum Vergrößern klicken)

Dieses Szenario ist der bevorzugte Anwendungsfall und wird in diesem Dokument ausführlich erläutert. Das Dokument behandelt folgende Themen:

  • Weiterleitung zwischen Umgebungen mithilfe von privaten Zonen und der DNS-Weiterleitung einrichten
  • Firewalls und Routing konfigurieren
  • Referenzarchitekturen, die zeigen, wie eine oder mehrere VPCs verwendet werden

DNS-Auflösung weiterhin lokal ausführen

Ein alternativer Ansatz besteht darin, für das autoritative Hosting aller internen Domainnamen weiterhin Ihren vorhandenen lokalen DNS-Server zu verwenden. In diesem Fall können Sie alle Anfragen von Google Cloud über die ausgehende DNS-Weiterleitung mithilfe eines alternativen Nameservers weiterleiten. Dieser Ansatz bietet folgende Vorteile:

  • Sie müssen weniger Änderungen an Geschäftsprozessen vornehmen.
  • Sie können weiterhin Ihre vorhandenen Tools verwenden.
  • Einzelne DNS-Anfragen können lokal mit Sperrlisten gefiltert werden.

Der Ansatz hat jedoch die folgenden Nachteile:

  • DNS-Anfragen von Google Cloud haben eine höhere Latenz.
  • Ihr System benötigt eine Verbindung zur lokalen Umgebung für DNS-Vorgänge.
  • Es ist möglicherweise schwierig, hochflexible Umgebungen wie automatisch skalierte Instanzgruppen einzubinden.
  • Das System ist eventuell nicht mit Produkten wie Cloud Dataproc kompatibel, da für diese Produkte die umgekehrte Auflösung der Google Cloud-Instanznamen erforderlich ist.

Gesamte DNS-Auflösung nach Cloud DNS verschieben

Eine andere Möglichkeit ist die Migration zu Cloud DNS als autoritativem Dienst für die gesamte Domainauflösung. Anschließend können Sie die vorhandene lokale Namensauflösung mithilfe von privaten Zonen und der eingehenden DNS-Weiterleitung zu Cloud DNS migrieren. Dieser Ansatz bietet folgende Vorteile:

  • Sie müssen keinen hochverfügbaren DNS-Dienst lokal verwalten.
  • Ihr System kann zentralisiertes Logging und Monitoring mit Cloud DNS nutzen.

Der Ansatz hat jedoch die folgenden Nachteile:

  • Lokale DNS-Anfragen haben eine höhere Latenz.
  • Ihr System benötigt zur Namensauflösung eine zuverlässige Verbindung zu Ihrem VPC-Netzwerk.

Best Practices für private Cloud DNS-Zonen

Private Zonen hosten DNS-Einträge, die nur innerhalb Ihrer Organisation sichtbar sind. Öffentliche Zonen in Cloud DNS werden in diesem Dokument nicht behandelt. Solche Zonen decken die öffentlichen Einträge der Organisation ab, z. B. DNS-Einträge für die öffentliche Website, und sind bei einer Hybridkonfiguration nicht so bedeutsam.

Teams mithilfe von Automatisierung ermöglichen, private Zonen im Hostprojekt der freigegebenen VPC zu verwalten

Wenn Sie in Ihrer Organisation freigegebene VPC-Netzwerke verwenden, müssen Sie alle privaten Zonen in Cloud DNS innerhalb des Hostprojekts hosten. Alle Dienstprojekte können automatisch auf die Einträge in privaten Zonen zugreifen, die mit dem freigegebenen VPC-Netzwerk verbunden sind.

Das folgende Diagramm zeigt, wie private Zonen in einem freigegebenen VPC-Netzwerk gehostet werden:

Private Zonen, die in einem freigegebenen VPC-Netzwerk gehostet werden (zum Vergrößern klicken)
Private Zonen, die in einem freigegebenen VPC-Netzwerk gehostet werden (zum Vergrößern klicken)

Wenn Sie möchten, dass Teams ihre eigenen DNS-Einträge festlegen, empfehlen wir die automatisierte Erstellung von DNS-Einträgen. Sie können z. B. eine Webanwendung oder eine interne API erstellen, mit der Nutzer ihre eigenen DNS-Einträge unter bestimmten Subdomains festlegen. Die Anwendung prüft, ob die Einträge Ihren Organisationsregeln entsprechen. Alternativ können Sie Ihre DNS-Konfiguration in einem Code-Repository wie Cloud Source Repositories in Form von Terraform- oder Cloud Deployment Manager-Deskriptoren ablegen und Pull-Anfragen von Teams akzeptieren. In beiden Fällen bietet ein Dienstkonto mit der IAM-Rolle DNS-Administrator im Hostprojekt die Möglichkeit, die Änderungen nach der Genehmigung automatisch bereitzustellen.

IAM-Rollen nach dem Prinzip der geringsten Berechtigung festlegen

Verwenden Sie das Sicherheitsprinzip der geringsten Berechtigung und gewähren Sie das Recht zum Ändern von DNS-Einträgen nur solchen Nutzern Ihrer Organisation, die diese Aufgabe ausführen müssen. Vermeiden Sie die Verwendung einfacher Rollen, da diese möglicherweise Zugriff auf Ressourcen gewähren, die über die vom Nutzer benötigten Ressourcen hinausgehen. Cloud DNS bietet Berechtigungen und Rollen, mit denen Sie Lese- und Schreibzugriff gewähren können, der nur für DNS gilt.

Wenn die Möglichkeit zum Erstellen privater Zonen von der Möglichkeit zum Erstellen öffentlicher Zonen getrennt werden muss, verwenden Sie die Berechtigung dns.networks.bindPrivateDNSZone.

Best Practices für DNS-Weiterleitungszonen

Cloud DNS bietet DNS-Serverrichtlinien und DNS-Weiterleitungszonen, um DNS-Namen zwischen Ihrer lokalen Umgebung und der Google Cloud-Umgebung nachschlagen zu können. Sie haben mehrere Möglichkeiten, die DNS-Weiterleitung zu konfigurieren. Der folgende Abschnitt führt Best Practices für die Hybrid-DNS-Konfiguration auf. Diese Best Practices finden Sie unter Referenzarchitekturen für das Hybrid-DNS.

Die DNS-Weiterleitung kann nicht für die Weiterleitung zwischen verschiedenen Google Cloud-Umgebungen verwendet werden, unabhängig davon, auf welche Weise sie miteinander verbunden sind. Verwenden Sie für diesen Anwendungsfall DNS-Peering.

Weiterleitungszonen zum Abfragen lokaler Server verwenden

Zum Abfragen von DNS-Einträgen in Ihrer lokalen Umgebung müssen Sie eine Weiterleitungszone für die Domain einrichten, die Sie lokal für Ihre Unternehmensressourcen verwenden, z. B. corp.example.com. Dieser Ansatz wird gegenüber einer DNS-Richtlinie, die einen alternativen Nameserver aktiviert, bevorzugt. Der Zugriff auf interne DNS-Namen von Compute Engine bleibt erhalten und öffentliche IP-Adressen werden weiterhin ohne einen zusätzlichen Hop über einen lokalen Nameserver aufgelöst.

Der Trafficfluss mit dieser Konfiguration ist in den Referenzarchitekturen dargestellt.

Sie sollten nur dann alternative Nameserver verwenden, wenn der gesamte DNS-Traffic lokal überwacht oder gefiltert werden muss und privates DNS-Logging für Ihre Anforderungen nicht ausreicht.

Mithilfe von DNS-Serverrichtlinien lokale Abfragen zulassen

Damit lokale Hosts DNS-Einträge abfragen können, die in privaten Cloud DNS-Zonen wie gcp.example.com gehostet werden, erstellen Sie eine DNS-Serverrichtlinie mit der eingehenden DNS-Weiterleitung. Mit der eingehenden DNS-Weiterleitung kann Ihr System alle privaten Zonen im Projekt sowie interne DNS-Adressen und Peering-Zonen abfragen. Obwohl Sie für jedes Subnetz eine separate IP-Adresse für eingehende Weiterleitungen haben, geben alle DNS-Abfragen identische Antworten zurück und es gibt keinen Latenzunterschied. Ihre Anwendungen können an jede dieser Adressen Anfragen senden.

Der Trafficfluss mit dieser Konfiguration ist in den Referenzarchitekturen dargestellt.

Google Cloud und lokale Firewalls öffnen, um DNS-Traffic zuzulassen

Achten Sie darauf, dass DNS-Traffic an keiner Stelle Ihrer VPC oder lokal gefiltert wird. Dazu muss Folgendes gewährleistet sein:

  • Ihre lokale Firewall leitet Abfragen von Cloud DNS weiter. Cloud DNS sendet Abfragen aus dem IP-Adressbereich 35.199.192.0/19. Das DNS verwendet UDP-Port 53 oder TCP-Port 53, je nach Größe der Anfrage oder Antwort.

  • Ihr DNS-Server blockiert keine Anfragen. Wenn Ihr lokaler DNS-Server nur Anfragen von bestimmten IP-Adressen akzeptiert, muss der Bereich 35.199.192.0/19 enthalten sein.

  • Es ist Trafficfluss von der lokalen Umgebung zu Ihren Weiterleitungs-IP-Adressen möglich. Achten Sie bei der eingehenden Weiterleitung darauf, dass der Traffic, der von Ihren lokalen DNS-Servern oder anderen Clients zu den Weiterleitungs-IP-Adressen geleitet wird, nicht durch Ihre lokale Firewall blockiert wird. Möglicherweise müssen Sie eine Firewallregel für Ihre lokale Firewall erstellen, mit der Traffic von allen Clients an UDP-Port 53 zur Weiterleitungs-IP-Adresse zugelassen wird.

Bedingte Weiterleitung für den lokalen Zugriff auf DNS-Einträge verwenden

Mit Cloud DNS können Sie für den Zugriff auf private Einträge, die lokal auf Unternehmens-DNS-Servern gehostet werden, nur Weiterleitungszonen verwenden. Je nachdem, welche DNS-Serversoftware Sie verwenden, haben Sie jedoch unter Umständen mehrere Möglichkeiten, lokal auf die DNS-Einträge in Google Cloud zuzugreifen. In allen Fällen erfolgt der Zugriff auf die Einträge über die eingehende DNS-Weiterleitung:

  • Bedingte Weiterleitung: Bei Verwendung der bedingten Weiterleitung leitet Ihr Unternehmens-DNS-Server Anfragen für bestimmte Zonen oder Subdomains an die Weiterleitungs-IP-Adressen in Google Cloud weiter. Wir empfehlen diesen Ansatz, da er am wenigsten komplex ist und Sie damit alle DNS-Anfragen auf den Unternehmens-DNS-Servern zentral kontrollieren können.

  • Delegation: Wenn Ihre private Zone in Google Cloud eine Subdomain der lokal verwendeten Zone ist, können Sie diese Subdomain auch an den Google Cloud-Nameserver delegieren. Legen Sie dazu NS-Einträge in Ihrer Zone fest. Mit dieser Konfiguration können Clients direkt mit den Weiterleitungs-IP-Adressen in Google Cloud kommunizieren. Achten Sie also darauf, dass die Firewall diese Anfragen weiterleitet.

  • Zonenübertragungen: Da Cloud DNS keine Zonenübertragungen unterstützt, können Sie DNS-Einträge nicht mit lokalen DNS-Servern mithilfe von Zonenübertragungen synchronisieren.

DNS-Peering verwenden, um die ausgehende Weiterleitung von mehreren VPC-Netzwerken zu vermeiden

Verwenden Sie keine ausgehende Weiterleitung von mehreren VPC-Netzwerken zu Ihren lokalen DNS-Servern, da dies zu Problemen mit dem Rücktraffic führt. Antworten von Ihren DNS-Servern werden von der GCP nur akzeptiert, wenn sie an die VPC weitergeleitet werden, von der die Abfrage stammt. Abfragen von einer VPC haben aber den IP-Bereich 35.199.192.0/19 auch als Quelle. Daher können Antworten nur dann ordnungsgemäß weitergeleitet werden, wenn Ihre lokalen Umgebungen vollständig getrennt sind.

Das folgende Diagramm veranschaulicht das Problem, das sich ergibt, wenn mehrere VPCs die ausgehende Weiterleitung verwenden:

Probleme mit mehreren VPCs, die die ausgehende Weiterleitung verwenden (zum Vergrößern klicken)
Probleme mit mehreren VPCs, die die ausgehende Weiterleitung verwenden (zum Vergrößern klicken)

Wir empfehlen, eine einzelne VPC für das Abfragen lokaler Nameserver über die ausgehende Weiterleitung festzulegen. Anschließend können zusätzliche VPCs die lokalen Nameserver abfragen und dafür die festgelegte VPC mit einer DNS-Peering-Zone ansteuern. Ihre Abfragen werden dann an lokale Nameserver gemäß der Reihenfolge der VPC-Namensauflösung der festgelegten VPC weitergeleitet. Diese Konfiguration wird im Abschnitt Referenzarchitekturen für das Hybrid-DNS dargestellt.

Unterschied zwischen DNS-Peering und VPC-Netzwerk-Peering

VPC-Netzwerk-Peering ist nicht mit DNS-Peering identisch. Mit dem VPC-Netzwerk-Peering können VMs in mehreren Projekten sich gegenseitig erreichen, die Namensauflösung wird dabei jedoch nicht geändert. Die Ressourcen in den einzelnen VPCs folgen weiterhin ihrer eigenen Auflösungsreihenfolge. Im Gegensatz dazu können Sie über DNS-Peering erlauben, dass Anfragen für bestimmte Zonen an eine andere VPC weitergeleitet werden. Damit lassen sich Anfragen an verschiedene Google Cloud-Umgebungen weiterleiten, unabhängig davon, ob die VPCs miteinander verbunden sind.

VPC-Netzwerk-Peering und DNS-Peering werden auch unterschiedlich eingerichtet. Beim VPC-Netzwerk-Peering muss für beide VPCs eine Peering-Beziehung zur jeweils anderen VPC eingerichtet sein. Das Peering erfolgt dann automatisch in beide Richtungen.

DNS-Peering leitet DNS-Anfragen in eine Richtung weiter und erfordert keine bidirektionale Beziehung zwischen VPCs. Ein VPC-Netzwerk, als DNS-Nutzernetzwerk bezeichnet, sucht nach einer Cloud DNS-Peering-Zone in einem anderen VPC-Netzwerk. Dieses Netzwerk wird als DNS-Produzentennetzwerk bezeichnet. Nutzer mit der IAM-Berechtigung dns.networks.targetWithPeeringZone für das Projekt des Produzentennetzwerks können DNS-Peering zwischen Nutzer- und Produzentennetzwerken einrichten. Zum Einrichten des DNS-Peerings von einem VPC-Nutzernetzwerk aus benötigen Sie die DNS-Peer-Rolle für das Hostprojekt des VPC-Produzentennetzwerks.

Wenn Sie automatisch generierte Namen verwenden, sollten Sie DNS-Peering für interne Zonen verwenden

Wenn Sie automatisch generierte Namen für VMs verwenden, die vom internen DNS-Dienst erstellt werden, haben Sie die Möglichkeit, die projectname.internal-Zonen mithilfe von DNS-Peering an andere Projekte weiterzuleiten. Sie können alle .internal-Zonen in einem Hub-Projekt aggregieren, um sie alle lokal verfügbar zu machen.

Diese Konfiguration wird im folgenden Diagramm dargestellt:

DNS-Peering in einer Mesh-Netzwerkkonfiguration (zum Vergrößern klicken)
DNS-Peering in einer Mesh-Netzwerkkonfiguration (zum Vergrößern klicken)

Bei Problemen der Anleitung zur Fehlerbehebung folgen

Die Anleitung zur Cloud DNS-Fehlerbehebung führt Sie durch die Behebung von häufig beim Einrichten von Cloud DNS auftretenden Fehlern.

Referenzarchitekturen für das Hybrid-DNS

Dieser Abschnitt stellt einige Referenzarchitekturen für gängige Szenarien mit privaten Cloud DNS-Zonen in einer Hybridumgebung dar. In allen Fällen werden sowohl lokale Ressourcen als auch Google Cloud-Ressourceneinträge und -Zonen innerhalb der Umgebung verwaltet. Alle Einträge sind für Abfragen sowohl von lokalen als auch von Google Cloud-Hosts verfügbar.

Sie sollten die Referenzarchitektur verwenden, die für Ihr VPC-Design geeignet ist:

  • Hybridarchitektur mit einer einzelnen freigegebenen VPC unter Verwendung eines einzelnen VPC-Netzwerks, das lokal verbunden ist

  • Hybridarchitektur mit mehreren separaten VPC-Netzwerken, wenn Sie mehrere VPCs über verschiedene VPN-Tunnel oder VLAN-Anhänge lokal verbinden, aber dieselbe DNS-Infrastruktur lokal nutzen

  • Hybridarchitektur mit einem Hub-VPC-Netzwerk, das mit Spoke-VPC-Netzwerken verbunden ist, wenn Sie mit VPC-Netzwerk-Peering ein Hub-VPC-Netzwerk mit mehreren unabhängigen Spoke-VPC-Netzwerken verbinden

In allen Fällen ist die lokale Umgebung über einen oder mehrere Cloud VPN-Tunnel oder über Verbindungen des Typs "Cloud Interconnect – Dedicated" bzw. "Cloud Interconnect – Partner" mit den Google Cloud-VPCs verbunden. Es spielt dabei keine Rolle, welche Verbindungsmethode für jedes einzelne VPC-Netzwerk verwendet wird.

Hybridarchitektur mit nur einem freigegebenen VPC-Netzwerk

Der häufigste Fall ist ein einzelnes freigegebenes VPC-Netzwerk, das mit der lokalen Umgebung verbunden ist, wie im folgenden Diagramm dargestellt:

Hybridarchitektur mit einem einzelnen freigegebenen VPC-Netzwerk
Hybridarchitektur mit einem einzelnen freigegebenen VPC-Netzwerk (zum Vergrößern klicken)

So richten Sie diese Architektur ein:

  1. Richten Sie Ihre lokalen DNS-Server als autoritative Server für corp.example.com ein.
  2. Konfigurieren Sie in Cloud DNS eine autoritative private Zone wie z. B. gcp.example.com im Hostprojekt des freigegebenen VPC-Netzwerks und richten Sie alle Einträge für Ressourcen in dieser Zone ein.
  3. Legen Sie im Hostprojekt für das freigegebene VPC-Netzwerk eine DNS-Serverrichtlinie fest, um die eingehende DNS-Weiterleitung zuzulassen.
  4. Geben Sie eine DNS-Weiterleitungszone an, die corp.example.com an die lokalen DNS-Server weiterleitet. Die freigegebene VPC muss berechtigt sein, die Weiterleitungszone abzufragen.
  5. Richten Sie die Weiterleitung zu gcp.example.com auf Ihren lokalen DNS-Servern so ein, dass sie auf eine IP-Adresse für eingehende Weiterleitungen im freigegebenen VPC-Netzwerk verweist.
  6. Achten Sie dafür, dass DNS-Traffic in Ihrer lokalen Firewall zulässig ist.
  7. Fügen Sie in Cloud Router-Instanzen benutzerdefiniertes Route Advertisement für den Bereich 35.199.192.0/19 lokal hinzu.

Hybridarchitektur mit mehreren separaten VPC-Netzwerken

Eine weitere Option für Hybridarchitekturen ist die Verwendung mehrerer separater VPC-Netzwerke. Diese VPC-Netzwerke sind in Ihrer Google Cloud-Umgebung nicht über VPC-Netzwerk-Peering miteinander verbunden. Alle VPC-Netzwerke sind über eigene Cloud-VPN-Tunnel oder VLAN-Anhänge mit Ihren lokalen Umgebungen verknüpft. Ein typischer Anwendungsfall für diese Architektur sind separate Umgebungen, die nicht miteinander kommunizieren, aber DNS-Server gemeinsam nutzen. Ein typisches Beispiel hierfür sind getrennte Produktions- und Entwicklungsumgebungen.

Diese Architektur ist im folgenden Diagramm dargestellt:

Hybridarchitektur mit mehreren separaten VPC-Netzwerken (zum Vergrößern klicken)
Hybridarchitektur mit mehreren separaten VPC-Netzwerken (zum Vergrößern klicken)

So richten Sie diese Architektur ein:

  1. Richten Sie Ihre lokalen DNS-Server als autoritative Server für corp.example.com ein.
  2. Konfigurieren Sie in Cloud DNS eine private Zone wie z. B. prod.gcp.example.com im Hostprojekt des freigegebenen VPC-Produktionsnetzwerks und richten Sie alle Einträge für Ressourcen in dieser Zone ein.
  3. Konfigurieren Sie in Cloud DNS eine private Zone wie z. B. dev.gcp.example.com im Hostprojekt des freigegebenen VPC-Entwicklungsnetzwerks und richten Sie alle Einträge für Ressourcen in dieser Zone ein.
  4. Legen Sie im Hostprojekt für das freigegebene VPC-Produktionsnetzwerk eine DNS-Serverrichtlinie fest, um die eingehende DNS-Weiterleitung zuzulassen.
  5. Legen Sie im freigegebenen VPC-Produktionsnetzwerk eine DNS-Zone fest, um corp.example.com an die lokalen DNS-Server weiterzuleiten.
  6. Richten Sie für example.com eine DNS-Peering-Zone vom freigegebenen VPC-Entwicklungsnetzwerk zum freigegebenen VPC-Produktionsnetzwerk ein.
  7. Legen Sie für dev.gcp.example.com eine DNS-Peering-Zone vom freigegebenen VPC-Produktionsnetzwerk zum freigegebenen VPC-Entwicklungsnetzwerk fest.
  8. Richten Sie die Weiterleitung an gcp.example.com auf Ihren lokalen DNS-Servern so ein, dass sie auf eine IP-Adresse für eingehende Weiterleitungen im freigegebenen VPC-Produktionsnetzwerk verweist.
  9. Achten Sie darauf, dass die Firewall DNS-Traffic sowohl lokal als auch in Google Cloud-Firewalls zulässt.
  10. Fügen Sie in Cloud Router-Instanzen benutzerdefiniertes Route Advertisement für den Bereich 35.199.192.0/19 im freigegebenen VPC-Produktionsnetzwerk lokal hinzu.

Hybridarchitektur mit einem Hub-VPC-Netzwerk, das mit Spoke-VPC-Netzwerken verbunden ist

Eine weitere Möglichkeit besteht darin, die lokale Infrastruktur über Cloud Interconnect oder Cloud VPN mit einem einzelnen Hub-VPC-Netzwerk zu verbinden. Für das Peering dieses VPC-Netzwerks mit mehreren Spoke-VPC-Netzwerken verwenden Sie VPC-Netzwerk-Peering. Jedes Spoke-VPC-Netzwerk hostet seine eigenen privaten Zonen in Cloud DNS. Mit benutzerdefinierten Routen im VPC-Netzwerk-Peering und mit benutzerdefiniertem Route Advertisement in Cloud Router sind ein kompletter Routenaustausch und vollständige Konnektivität zwischen den lokalen und allen Spoke-VPC-Netzwerken möglich. DNS-Peering wird parallel zur VPC-Netzwerk-Peering-Verbindung ausgeführt, um die Namensauflösung zwischen Umgebungen zu ermöglichen.

Diese Architektur wird im folgenden Diagramm dargestellt:

Hybridarchitektur mit Hub-VPC-Netzwerken, die mit Spoke-VPC-Netzwerken verbunden sind (zum Vergrößern klicken)
Hybridarchitektur mit Hub-VPC-Netzwerken, die mit Spoke-VPC-Netzwerken verbunden sind (zum Vergrößern klicken)

So richten Sie diese Architektur ein:

  1. Richten Sie Ihre lokalen DNS-Server als autoritative Server für corp.example.com ein.
  2. Konfigurieren Sie in Cloud DNS eine private Zone wie z. B. projectX.gcp.example.com für jede Spoke-VPC und richten Sie alle Einträge für Ressourcen in dieser Zone ein.
  3. Legen Sie im Hub-Projekt für das freigegebene VPC-Produktionsnetzwerk eine DNS-Serverrichtlinie fest, um die eingehende DNS-Weiterleitung zuzulassen.
  4. Erstellen Sie in der Hub-VPC eine private DNS-Zone für corp.example.com und konfigurieren Sie die ausgehende Weiterleitung zu den lokalen DNS-Servern.
  5. Legen Sie für projectX.gcp.example.com eine DNS-Peering-Zone von der Hub-VPC zu jeder Spoke-VPC fest.
  6. Legen Sie für example.com eine DNS-Peering-Zone von jeder Spoke-VPC zur Hub-VPC fest.
  7. Richten Sie die Weiterleitung zu gcp.example.com auf Ihren lokalen DNS-Servern so ein, dass sie auf eine IP-Adresse für eingehende Weiterleitungen in der Hub-VPC verweist.
  8. Achten Sie darauf, dass die Firewall DNS-Traffic sowohl lokal als auch in Google Cloud-Firewalls zulässt.
  9. Fügen Sie in Cloud Router-Instanzen benutzerdefiniertes Route Advertisement für den Bereich 35.199.192.0/19 in der Hub-VPC lokal hinzu.
  10. (Optional) Wenn Sie auch die automatisch generierten internen DNS-Namen verwenden, führen Sie ein Peering für jede Spoke-Projektzone wie spoke-project-x.internal mit dem Hub-Projekt aus und leiten Sie alle lokalen Abfragen für .internal weiter.

Weitere Informationen