Leitfaden zu Private Link und DNS mit Azure Virtual WAN

Azure Private Link ermöglicht Clients den Zugriff auf Azure PaaS-Dienste direkt über private virtuelle Netzwerke, ohne öffentliche IP-Adressen zu verwenden. Für jeden Dienst konfigurieren Sie einen privaten Endpunkt, der eine private IP-Adresse aus Ihrem Netzwerk verwendet. Clients können dann den privaten Endpunkt verwenden, um eine private Verbindung mit dem Dienst herzustellen.

Clients verwenden den vollqualifizierten Domänennamen (FQDN) eines Diensts, um eine Verbindung mit dem Dienst herzustellen. Sie konfigurieren DNS in Ihrem Netzwerk, um den FQDN des Diensts in die private IP-Adresse des privaten Endpunkts aufzulösen.

Ihr Netzwerkdesign und insbesondere Ihre DNS-Konfiguration sind wichtige Faktoren, um private Endpunktverbindungen mit Diensten zu unterstützen. Dieser Artikel ist eine Reihe von Artikeln, die Anleitungen zum Verständnis Private Link Verhaltens in Virtual WAN Umgebungen bieten. Es werden mehrere Szenarien vorgestellt, einschließlich absichtlich eingeschränkter Beispiele, die verwendet werden, um häufige DNS- und Routing-Herausforderungen zu veranschaulichen. Auch wenn keines der Szenarien genau Ihrer Situation entspricht, sollten Sie in der Lage sein, die Designs an Ihre Anforderungen anzupassen.

Starten der Netzwerktopologie

Die Erste Netzwerktopologie ist die Basisarchitektur für alle Szenarien in dieser Reihe. Es ist ein typisches Hub-Spoke-Netzwerk, das Azure Virtual WAN verwendet.

Abbildung 1: Starten der Netzwerktopologie für alle privaten Endpunkt- und DNS-Szenarien

Laden Sie eine Visio-Datei dieser Architektur herunter. Diese Topologie weist die folgenden Merkmale auf:

• Es ist ein Hub-Spoke-Netzwerk, das mit Azure Virtual WAN implementiert wird.
• Es gibt zwei Regionen mit einem gesicherten virtuellen Hub, der Azure Firewall enthält.
• Jeder gesicherte regionale virtuelle Hub verfügt über die folgenden Sicherheitseinstellungen für Azure Virtual Network-Verbindungen:
  • Internet-Datenverkehr: Secured by Azure Firewall – Der gesamte Datenverkehr zum Internet fließt über die regionale Hubfirewall.
  • Private-Datenverkehr: Gesichert durch Azure Firewall – Der gesamte Datenverkehr zwischen den Spokes fließt über die regionale Hub-Firewall.
• Jeder regionale virtuelle Hub ist mit der Azure-Firewall gesichert. Die regionalen Hubfirewalls haben die folgenden Einstellungen:
  • DNS-Server: Standard (bereitgestellt von Azure) – Die regionale Hubfirewall verwendet explizit Azure DNS für die FQDN-Auflösung in Regelsammlungen.
  • DNS-Proxy: Aktiviert – Die regionale Hubfirewall antwortet auf DNS-Abfragen auf Port 53. Es leitet Abfragen für nicht zwischengespeicherte Werte an Azure DNS weiter.
  • Die Firewall protokolliert Regelauswertungen und DNS-Proxyanforderungen an einen Log Analytics-Arbeitsbereich, der sich in derselben Region befindet. Diese Protokollierung ist eine standardmäßige Netzwerksicherheitsanforderung.
• Jede Speichen verwendet die private IP der regionalen Firewall als DNS-Server. Andernfalls kann die FQDN-Regelauswertung nicht synchron sein.

Routing mit mehreren Regionen

Virtual WAN Hubrouting-Absichts- und Routingrichtlinien ermöglichen Es Ihnen, zu steuern, wie der Datenverkehr zwischen Hubs fließt und ob dieser Datenverkehr von Azure Firewall oder einer anderen Sicherheitslösung überprüft wird.

In einer Multi-Hub-Virtual WAN-Bereitstellung durchläuft privater inter-Hub-Datenverkehr standardmäßig nicht die Azure Firewall. Stattdessen verwendet Azure die integrierte, von Virtual WAN verwaltete Hub-zu-Hub-Verbindung, die parallel zu den gesicherten Datenpfaden innerhalb der einzelnen Hubs ausgeführt wird. Dies bedeutet, dass der private Datenverkehr, der zwischen Hubs wechselt, nicht automatisch überprüft wird.

Wenn Sie Azure Firewall zum Überprüfen des privaten Inter-Hub-Datenverkehrs benötigen, können Sie dieses Verhalten aktivieren, indem Sie eine Private-Datenverkehrsroutingrichtlinie konfigurieren und inter-hub inspection aktivieren. Dadurch wird der private Datenverkehr zwischen Hubs zur Inspektion durch Azure Firewall weitergeleitet.

Diese Konfiguration ist fortgeschrittener und liegt außerhalb des Umfangs dieser Reihe.

Hinzufügen von Speichennetzwerken

Wenn Sie Speichennetzwerke hinzufügen, wenden Sie die in der Startnetzwerktopologie definierten Einschränkungen an. Jeder Spoke ist der Standardroutentabelle des jeweiligen regionalen Hubs entsprechend zugeordnet, und die Azure Firewall sichert sowohl den Internet- als auch den privaten Datenverkehr. Der folgende Screenshot zeigt ein Konfigurationsbeispiel:

Abbildung 2: Sicherheitskonfiguration für virtuelle Netzwerkverbindungen im virtuellen Hub

Wichtige Herausforderungen

Die Erste Netzwerktopologie stellt Herausforderungen beim Konfigurieren von DNS für private Endpunkte.

Während Virtual WAN eine verwaltete Hubumgebung bietet, besteht der Nachteil darin, dass die Möglichkeit, die Konfiguration des virtuellen Hubs zu beeinflussen oder Komponenten hinzuzufügen, begrenzt ist. Mit einer herkömmlichen Hub-Spoke-Topologie können Sie Workloads in Speichen isolieren und gemeinsame Netzwerkdienste wie DNS-Einträge im selbstverwalteten Hub teilen. Normalerweise verknüpfen Sie die private DNS-Zone mit dem Hubnetzwerk, damit Azure DNS private Endpunkt-IP-Adressen für Clients auflösen kann.

Es ist jedoch nicht möglich, private DNS-Zonen mit Virtual WAN-Hubs zu verknüpfen, was bedeutet, dass die DNS-Auflösung innerhalb des Hubs nicht von den privaten Zonen weiß. Dies verursacht insbesondere ein Problem für die Azure Firewall, die als DNS-Provider für Workload-Spokes dient und DNS für die FQDN-Auflösung verwendet.

Wenn Sie Virtual WAN-Hubs verwenden, mag es intuitiv erscheinen, private DNS-Zonen mit den virtuellen Spoke-Netzwerken zu verknüpfen, in denen Workloads die DNS-Auflösung erwarten. Wie in der Architektur erwähnt, ist der DNS-Proxy jedoch für die regionalen Firewalls aktiviert, und alle Speichen müssen ihre regionale Firewall als DNS-Quelle verwenden. Die Azure DNS Abfrage stammt aus der Firewall im Hub, nicht aus dem virtuellen Netzwerk der Workload, sodass private DNS-Zonenverbindungen im Speichennetzwerk nicht in der Auflösung verwendet werden.

Da Virtual WAN Hubs keine Verknüpfung mit Privates DNS Zonen herstellen können, wird der Azure DNS Private Resolver empfohlen, der in einem virtuellen Netzwerk mit Huberweiterung bereitgestellt wird, um die DNS-Auflösung in Private Link Szenarien zu ermöglichen. Dies ermöglicht eine skalierbare, zonenfähige private DNS-Auflösung für Workloads, die mit Virtual WAN Hubs verbunden sind. Nachverfolgungsartikel in dieser Reihe veranschaulichen, wie DNS Private Resolver die Architektur abschließt.

Angesichts der Komplexität der Aktivierung von DNS-Proxys für die regionalen Firewalls sollten wir uns die Gründe für die Aktivierung ansehen.

• Azure Firewall-Netzwerkregeln unterstützen FQDN-basierte Regeln, um ausgehenden Datenverkehr präziser zu steuern, den Anwendungsregeln nicht abdecken. Für dieses Feature muss der DNS-Proxy aktiviert sein. Eine häufige Verwendung ist das Einschränken des Netzwerkzeitprotokoll-Datenverkehrs (NTP) auf bekannte Endpunkte, z. B. time.windows.com.
• Die DNS-Anforderungsprotokollierung kommt Sicherheitsteams zugute. Azure Firewall verfügt über integrierte Unterstützung für die DNS-Anforderungsprotokollierung. Indem sichergestellt wird, dass alle im Spoke befindlichen Ressourcen Azure Firewall als DNS-Anbieter verwenden, wird eine umfassende Protokollierung sichergestellt.

Zur Veranschaulichung der Herausforderungen werden in den folgenden Abschnitten zwei Konfigurationen beschrieben. Es gibt ein einfaches Beispiel, das funktioniert, und ein komplexeres Beispiel, das nicht funktioniert, aber sein Fehler ist lehrreich.

Arbeitsszenario

Das folgende Beispiel ist eine grundlegende Konfiguration für private Endpunkte. Ein virtuelles Netzwerk enthält einen Client, der einen PaaS-Dienst über einen privaten Endpunkt erfordert. Eine mit dem virtuellen Netzwerk verknüpfte private DNS-Zone enthält einen A-Record, der den FQDN des Dienstes in die private IP-Adresse des privaten Endpunkts auflöst. Das folgende Diagramm beschreibt den Flow.

Abbildung 3: Eine grundlegende DNS-Konfiguration für private Endpunkte

Laden Sie eine Visio-Datei dieser Architektur herunter.

1. Der Client gibt eine Anforderung an stgworkload00.blob.core.windows.net aus.

2. Azure DNS, der konfigurierte DNS-Server für das virtuelle Netzwerk, wird für die IP-Adresse für stgworkload00.blob.core.windows.net abgefragt.

   Das Ausführen des folgenden Befehls vom virtuellen Computer (VM) veranschaulicht, dass der virtuelle Computer für die Verwendung von Azure DNS (168.63.129.16) als DNS-Anbieter konfiguriert ist.

   resolvectl status eth0
   
   Link 2 (eth0)
         Current Scopes: DNS
     Current DNS Server: 168.63.129.16
            DNS Servers: 168.63.129.16    
   

3. Die private DNS-Zone privatelink.blob.core.windows.net ist mit Workload VNet verknüpft, sodass Azure DNS Einträge von Workload VNet in ihre Antwort integriert.

4. Da in der privaten DNS-Zone ein A-Eintrag existiert, der den FQDN stgworkload00.privatelink.blob.core.windows.net der privaten IP des privaten Endpunktes zuordnet, wird die private IP-Adresse 10.1.2.4 zurückgegeben.

   Durch das Ausführen des folgenden Befehls auf der VM wird der FQDN des Speicherkontos in die private IP-Adresse des privaten Endpunkts aufgelöst.

   resolvectl query stgworkload00.blob.core.windows.net
   
   stgworkload00.blob.core.windows.net: 10.1.2.4   -- link: eth0
                                       (stgworkload00.privatelink.blob.core.windows.net)
   

5. Die Anforderung wird an die private IP-Adresse des privaten Endpunkts ausgegeben, der 10.1.2.4 lautet.

6. Die Anforderung wird über den privaten Link an das Speicherkonto weitergeleitet.

Dieses Design funktioniert, da Azure DNS:

• Ist der konfigurierte DNS-Server für das virtuelle Netzwerk.
• Ist sich der verknüpften privaten DNS-Zone bewusst.
• Löst DNS-Abfragen mithilfe der Werte der Zone auf.

Arbeitsfreies Szenario

Das folgende Beispiel ist ein naiver Versuch, private Endpunkte in der Startnetzwerktopologie zu verwenden. Es ist nicht möglich, eine private DNS-Zone mit einem virtuellen WAN-Hub zu verknüpfen. Wenn Clients daher für die Verwendung der Firewall als DNS-Server konfiguriert sind, werden die DNS-Anforderungen von innerhalb des virtuellen Hubs an Azure DNS weitergeleitet, bei dem keine verknüpfte private DNS-Zone vorhanden ist. Azure DNS weiß nicht, wie die Abfrage aufgelöst werden soll, außer durch die Standardeinstellung bereitzustellen, die die öffentliche IP-Adresse ist.

Abbildung 4: Ein naiver Versuch, private Endpunkte in der Startnetzwerktopologie zu verwenden

Laden Sie eine Visio-Datei dieser Architektur herunter.

1. Der Client gibt eine Anforderung an stgworkload00.blob.core.windows.net aus.

   Wenn Sie den folgenden Befehl auf dem virtuellen Computer ausführen, wird veranschaulicht, dass die VM für die Verwendung der virtuellen Hubfirewall als DNS-Anbieter konfiguriert ist.

   resolvectl status eth0
   
   Link 2 (eth0)
         Current Scopes: DNS
     Current DNS Server: 10.100.0.132
            DNS Servers: 10.100.0.132    
   

2. Die Firewall hat einen DNS-Proxy aktiviert, dessen Standardeinstellung die Weiterleitung von Anforderungen an Azure DNS ist. Die Anforderung wird an Azure DNS weitergeleitet.

3. Azure DNS kann stgworkload00.blob.core.windows.net nicht zu der privaten IP-Adresse des privaten Endpunkts auflösen, da:

   1. Eine private DNS-Zone kann nicht mit einem virtuellen WAN-Hub verknüpft werden.
   2. Azure DNS kennt keine private DNS-Zone, die mit dem virtuellen Workloadnetzwerk verknüpft ist, da der konfigurierte DNS-Server für das virtuelle Workloadnetzwerk Azure Firewall ist.

   Azure DNS antwortet mit der öffentlichen IP-Adresse des Speicherkontos.

   Durch Ausführen des folgenden Befehls vom virtuellen Computer wird der FQDN des Speicherkontos in die öffentliche IP des Speicherkontos aufgelöst.

   resolvectl query stgworkload00.blob.core.windows.net
   
   stgworkload00.blob.core.windows.net: 52.239.174.228 -- link: eth0
                                       (blob.bn9prdstr08a.store.core.windows.net)
   

   Da Azure Firewall DNS-Abfragen proxyt, können wir sie protokollieren. Im Folgenden sehen Sie Beispiele für Azure Firewall-DNS-Proxyprotokolle.

   DNS Request: 10.1.0.4:60137 - 46023 A IN stgworkload00.blob.core.windows.net. udp 63 false 512 NOERROR qr,rd,ra 313 0.009424664s
   DNS Request: 10.1.0.4:53145 - 34586 AAAA IN blob.bn9prdstr08a.store.core.windows.net. udp 69 false 512 NOERROR qr,aa,rd,ra 169 0.000113s    
   

4. Der Client empfängt die private IP-Adresse für den Endpunkt "Privater Link" nicht und kann keine private Verbindung mit dem Speicherkonto herstellen.

Dieses Verhalten wird erwartet. Es ist das Problem, das die Szenarien beheben.

Szenarien

Lösungen für dieses Problem sind ähnlich, aber die Untersuchung allgemeiner Workloadszenarien zeigt, wie jede Lösung unterschiedliche Anforderungen erfüllt. Die meisten Szenarien bestehen aus einem Client, der auf einen oder mehrere PaaS-Dienste über einen privaten Endpunkt zugreift. Sie halten sich an die Startnetzwerktopologie, unterscheiden sich jedoch in ihren Workloadanforderungen. Die Szenarien beginnen mit einem Client, der auf einen einzelnen regionalen PaaS-Dienst zugreift. Sie werden schrittweise komplexer und fügen mehr Sichtbarkeit im Netzwerk, Regionen und PaaS-Dienste hinzu.

In den meisten Szenarien wird der Client als VM implementiert, und der PaaS-Dienst, auf den der Client zugreift, ist ein Speicherkonto. Sie sollten virtuelle Maschinen als Vertreter für jede Azure-Ressource betrachten, die über eine NIC verfügt, die in einem virtuellen Netzwerk bereitgestellt ist, wie z. B. Virtual Machine Scale Sets, Azure Kubernetes Service-Knoten oder andere Dienste, die auf ähnliche Weise geroutet werden.

Jedes Szenario beginnt mit dem gewünschten Endzustand und detailliert die erforderliche Konfiguration, um von der Startnetzwerktopologie zum gewünschten Endzustand zu gelangen. Die Lösung verwendet das Muster der virtual Hub-Erweiterungen, das gemeinsame Dienste als sichere Erweiterung eines regionalen Hubs verfügbar macht, zusammen mit Azure DNS Private Resolver für DNS-Auflösung für private Endpunkte in Virtual WAN Umgebungen. Die folgende Tabelle enthält Links zum Virtuellen Hub-Erweiterungsmuster und zu den Szenarien.

Nächste Schritte

Verwandte Ressourcen

• Was ist ein privater Endpunkt?
• DNS-Konfiguration für private Azure-Endpunkte
• Private Link und DNS-Integration im großen Stil
• Azure Private Link in einem Hub-and-Spoke-Netzwerk
• DNS für lokale und Azure-Ressourcen
• Verwenden von Azure Private Link zum Verbinden von Netzwerken mit Azure Monitor
• Azure DNS Private Resolver-
• Zugriff mit höherer Sicherheit auf mehrinstanzenfähige Web-Apps aus einem lokalen Netzwerk
• Baseline für hochverfügbare zonenredundante Webanwendungen
• Lernprogramm: Erstellen einer privaten Endpunkt-DNS-Infrastruktur mit Azure Private Resolver für eine lokale Workload