Leitfaden zu Private Link und DNS mit Azure Virtual WAN

Azure Private Link

Azure DNS

Azure Firewall

Azure Virtual WAN

Azure Private Link ermöglicht Clients den Zugriff auf Azure PaaS (Platform-as-a-Service)-Dienste direkt aus privaten virtuellen Netzwerken aus, 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 weiterhin den vollqualifizierten Domänennamen (Fully Qualified Domain Name, FQDN) eines Diensts, um eine Verbindung mit diesem herzustellen. Sie konfigurieren DNS in Ihrem Netzwerk, um den FQDN des Diensts in die private IP-Adresse des privaten Endpunkts aufzulösen.

Ihr Netzwerkentwurf und insbesondere Ihre DNS-Konfiguration sind wichtige Faktoren bei der Unterstützung der privaten Endpunktkonnektivität mit Diensten. Dieser Artikel gehört zu einer Reihe von Artikeln, die Anleitungen zur Implementierung verschiedener Private Link-Szenarien bieten. Auch wenn keines der Szenarien genau mit Ihrer Situation übereinstimmt, sollten Sie in der Lage sein, die Designs an Ihre Anforderungen anzupassen.

Starten der Netzwerktopologie

Die Startnetzwerktopologie ist eine Netzwerkarchitektur, die als Startpunkt für alle Szenarien in dieser Artikelreihe dient. Die Architektur ist ein typisches Hub-Spoke-Netzwerk, das Azure Virtual WAN verwendet.

Abbildung 1: Startnetzwerktopologie für alle privaten Endpunkt- und DNS-Szenarien

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

Es handelt sich um ein Hub-Spoke-Netzwerk, das mit Azure Virtual WAN implementiert ist.
Es gibt zwei Regionen mit jeweils einem von Azure Firewall geschützten regionalen virtuellen Hub.
Für die Herstellung der Verbindung zwischen allen geschützten regionalen virtuellen Hubs mit dem Azure Virtual Network wurden die folgenden Sicherheitsparameter konfiguriert:
- Internetdatenverkehr: Durch Azure Firewall gesichert – Der gesamte ausgehende Datenverkehr zum Internet fließt über die Firewall des regionalen Hubs.
- Privater Datenverkehr: Durch Azure Firewall gesichert – Der gesamte Datenverkehr, der von Spoke zu Spoke weitergeleitet wird, fließt über die Firewall des regionalen Hubs.
Jeder regionale virtuelle Hub ist mit Azure Firewall gesichert. Für die Firewalls des regionalen Hubs sind folgenden Parameter konfiguriert:
- DNS-Server: Standard (von Azure bereitgestellt): – Die Firewall des regionalen Hubs verwendet explizit Azure DNS für die FQDN-Auflösung in Regelsammlungen.
- DNS-Proxy: Aktiviert – Die Firewall des regionalen Hubs antwortet auf DNS-Abfragen an Port 53. Er 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. Die Protokollierung dieser Ereignisse ist eine allgemeine Anforderung an die Netzwerksicherheitsprotokollierung.
Für jeden verbundenen virtuellen Netzwerk-Spoke ist der Standard-DNS-Server als private IP-Adresse der Firewall des regionalen Hubs konfiguriert. Andernfalls kann die FQDN-Regelauswertung nicht synchron sein.

Routing über mehrere Regionen

Geschützte Virtual WAN-Hubs verfügen nur über eingeschränkte Unterstützung für die Konnektivität zwischen Hubs, wenn mehrere geschützte virtuelle Hubs vorhanden sind. Diese Einschränkung wirkt sich auf Szenarien mit mehreren Hubs, Intra-Regionsszenarien und regionsübergreifenden Szenarien aus. Daher erleichtert die Netzwerktopologie nicht direkt die Filterung des privaten, regionsübergreifenden Datenverkehrs durch Azure Firewall. Unterstützung für diese Funktion wird mithilfe von Virtual WAN-Hubroutingabsicht und Routingrichtlinien bereitgestellt. Diese Funktion befindet sich derzeit in der Vorschauphase.

Für diese Artikelreihe wird davon ausgegangen, dass interner gesicherter Datenverkehr nicht mehrere Hubs durchläuft. Datenverkehr, der mehrere Hubs durchlaufen muss, muss dies in einer parallelen Topologie tun, die privaten Datenverkehr nicht über einen geschützten virtuellen Hub filtert, sondern ihn stattdessen durchlässt.

Hinzufügen von Spoke-Netzwerken

Wenn Sie Spoke-Netzwerke hinzufügen, folgen diese den Einschränkungen, die in der Startnetzwerktopologie definiert sind. Insbesondere ist jedes Spoke-Netzwerk der Standardroutingtabelle in seinem regionalen Hub zugeordnet, und die Firewall ist so konfiguriert, dass sowohl Internet- als auch privater Datenverkehr geschützt wird. Der folgende Screenshot zeigt ein Konfigurationsbeispiel:

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

Wichtige Herausforderungen

Die Startnetzwerktopologie führt zu Herausforderungen beim Konfigurieren von DNS für private Endpunkte.

Während die Verwendung von Virtual WAN Ihnen eine verwaltete Hub-Erfahrung bietet, besteht der Nachteil darin, dass es nur eingeschränkte Möglichkeiten gibt, die Konfiguration des virtuellen Hubs zu beeinflussen oder ihm weitere Komponenten hinzuzufügen. Mit einer herkömmlichen Hub-Spoke-Topologie können Sie Workloads in Spokes isolieren, während Sie allgemeine Netzwerkdienste wie DNS-Einträge im selbstverwalteten Hub gemeinsam nutzen. Sie verknüpfen normalerweise 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, so dass jede DNS-Auflösung, die innerhalb des Hubs erfolgt, keine Kenntnis von privaten Zonen hat. Dies ist insbesondere ein Problem für Azure Firewall, den konfigurierten DNS-Anbieter für Workload-Spokes, der DNS für die FQDN-Auflösung verwendet.

Wenn Sie Virtual WAN-Hubs verwenden, erscheint es intuitiv, private DNS-Zonen mit den virtuellen Spoke-Netzwerken zu verknüpfen, in denen Workloads eine DNS-Auflösung erwarten. Wie in der Architektur erwähnt, ist der DNS-Proxy jedoch für die regionalen Firewalls aktiviert, und es wird erwartet, dass alle Spokes ihre regionale Firewall als DNS-Quelle verwenden. Azure DNS wird von der Firewall und nicht vom Netzwerk der Workload aufgerufen, sodass alle privaten DNS-Zonenlinks im Workloadnetzwerk in der Auflösung nicht verwendet werden.

Hinweis

Um die regionale Firewall als DNS-Anbieter des Spoke zu konfigurieren, legen Sie den benutzerdefinierten DNS-Server im virtuellen Spoke-Netzwerk so fest, dass er auf die private IP-Adresse der Firewall und nicht auf den normalen Azure DNS-Wert zeigt.

Angesichts der Komplexität, die sich aus der Aktivierung des DNS-Proxys für die regionalen Firewalls ergibt, sollten wir die Gründe für seine Aktivierung überprüfen.

Azure Firewall-Netzwerkregeln unterstützen FQDN-basierte Grenzwerte, um ausgehenden Datenverkehr, der von Anwendungsregeln nicht verarbeitet wird, präziser zu steuern. Dieses Feature erfordert, dass der DNS-Proxy aktiviert ist. Eine häufige Anwendung ist die Beschränkung des NTP (Network Time Protocol)-Datenverkehrs auf bekannte Endpunkte, wie z. B. time.windows.com.
Sicherheitsteams können von der DNS-Anforderungsprotokollierung profitieren. Azure Firewall verfügt über integrierte Unterstützung für die DNS-Anforderungsprotokollierung, sodass die Anforderung, dass alle Spoke-Ressourcen Azure Firewall als DNS-Anbieter verwenden, eine umfassende Abdeckung der Protokollierung gewährleistet.

Um die Herausforderungen zu veranschaulichen, beschreiben die folgenden Abschnitte zwei Konfigurationen. Es gibt ein einfaches Beispiel, das funktioniert, und ein komplexeres, das nicht funktioniert, aber sein Fehlerverhalten ist aufschlussreich.

Funktionierendes Szenario

Das folgende Beispiel ist eine Basiskonfiguration eines privaten Endpunkts. Ein virtuelles Netzwerk enthält einen Client, der die Verwendung eines PaaS-Diensts über einen privaten Endpunkt erfordert. Eine private DNS-Zone, die mit dem virtuellen Netzwerk verknüpft ist, verfügt über einen A-Eintrag, der den FQDN des Diensts in die private IP-Adresse des privaten Endpunkts auflöst. Das folgende Diagramm stellt den Flow dar.

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

Laden Sie eine Visio-Datei dieser Architektur herunter.

Der Client stellt eine Anforderung an stgworkload00.blob.core.windows.net aus.
Azure DNS, der konfigurierte DNS-Server für das virtuelle Netzwerk, wird nach der IP-Adresse für stgworkload00.blob.core.windows.net abgefragt.

Das Ausführen des folgenden Befehls auf dem virtuellen Computer (der VM) veranschaulicht, dass die VM 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    
```
Die private DNS-Zone privatelink.blob.core.windows.net ist mit dem Workload-VNet verknüpft, sodass Azure DNS Datensätze aus dem Workload-VNet in seine Antwort einbezieht.
Da in der privaten DNS-Zone ein A-Eintrag vorhanden ist, der den FQDN stgworkload00.privatelink.blob.core.windows.net der privaten IP-Adresse des privaten Endpunkts zuordnet, wird die private IP-Adresse 10.1.2.4 zurückgegeben.

Durch 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)
```
Die Anforderung wird an die private IP-Adresse des privaten Endpunkts ausgegeben, der in diesem Fall 10.1.2.4 lautet.
Die Anforderung wird über Private Link an das Speicherkonto geroutet.

Der Entwurf funktioniert, weil Azure DNS:

Der konfigurierte DNS-Server für das virtuelle Netzwerk ist.
Die verknüpfte private DNS-Zone kennt.
DNS-Abfragen mithilfe der Werte der Zone auflöst.

Nicht funktionierendes 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 Virtual WAN-Hub zu verknüpfen. Wenn Clients also so konfiguriert sind, dass sie die Firewall als ihren DNS-Server verwenden, werden die DNS-Anforderungen von innerhalb des virtuellen Hubs an Azure DNS weitergeleitet, der keine verknüpfte private DNS-Zone hat. Azure DNS weiß nicht, wie es die Abfrage auflösen soll, außer durch die Bereitstellung der Standard-IP-Adresse, welche 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.

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

Das Ausführen des folgenden Befehls auf der VM veranschaulicht, dass die VM für die Verwendung der Firewall des virtuellen Hubs 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    
```
Die Firewall hat den DNS-Proxy mit der Standardeinstellung zum Weiterleiten von Anforderungen an Azure DNS aktiviert. Die Anforderung wird an Azure DNS weitergeleitet.
Azure DNS kann stgworkload00.blob.core.windows.net nicht in die private IP-Adresse des privaten Endpunkts auflösen, weil:
1. Eine private DNS-Zone kann nicht mit einem Virtual WAN-Hub verknüpft werden.
2. Azure DNS weiß nichts von einer privaten 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 auf der VM wird der FQDN des Speicherkontos in die öffentlich IP-Adresse 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 für DNS-Abfragen einen Proxy-Vorgang durchführt, können wir sie protokollieren. Im Folgenden finden 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    
```
Der Client empfängt die private IP-Adresse für den Private Link-Endpunkt nicht und kann keine private Verbindung mit dem Speicherkonto herstellen.

Das obige Verhalten wird erwartet. Es ist das Problem, das die Szenarien adressieren.

Szenarien

Obwohl die Lösungen für dieses Problem ähnlich sind, zeigt das Durchlaufen gängiger Workloadszenarien, wie die Lösungen die Anforderungen verschiedener Situationen adressieren. Die meisten Szenarien bestehen aus einem Client, der über einen privaten Endpunkt auf einen oder mehrere PaaS-Dienste zugreift. Sie halten sich an die Startnetzwerktopologie, unterscheiden sich aber in ihren Anforderungen an die Workload. Die Szenarien beginnen einfach mit einem Client, der auf einen einzelnen regionalen PaaS-Dienst zugreift. Sie werden inkrementell komplexer und fügen mehr Netzwerksichtbarkeit, 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 VMs als Ersatz für jede Azure-Ressource betrachten, die über eine NIC verfügt, die in einem virtuellen Netzwerk verfügbar gemacht wird, z. B. Virtual Machine Scale Sets, Azure Kubernetes Service-Knoten oder einen anderen Dienst, der auf ähnliche Weise geroutet wird.

Wichtig

Die Private Link-Implementierung für das Azure Storage-Konto unterscheidet sich möglicherweise auf subtile Weise von anderen PaaS-Diensten, ist aber für viele gut geeignet. Beispielsweise entfernen einige Dienste FQDN-Datensätze, während sie über Private Link verfügbar gemacht werden, was zu unterschiedlichen Verhaltensweisen führen kann, aber solche Unterschiede spielen normalerweise bei Lösungen für diese Szenarien keine Rolle.

Jedes Szenario beginnt mit dem gewünschten Endzustand und beschreibt die Konfiguration, die erforderlich ist, um von der Startnetzwerktopologie zum gewünschten Endzustand zu gelangen. Die Lösung für jedes Szenario nutzt das Muster für virtuelle Huberweiterungen. Dieses Muster behandelt die Frage, wie gemeinsame Dienste in einer isolierten und sicheren Weise als konzeptionelle Erweiterung eines regionalen Hubs verfügbar gemacht werden können. Die folgende Tabelle enthält Links zum Erweiterungsmuster für virtuelle Hubs und zu den Szenarien.

Handbuch	BESCHREIBUNG
Einzelne Region, dedizierter PaaS	Eine Workload in einer einzelnen Region greift auf eine dedizierte PaaS-Ressource zu.

Nächste Schritte

Lesen des Szenarios für die dedizierte PaaS-Ressource in einer einzelnen Region

Leitfaden zu Private Link und DNS mit Azure Virtual WAN