Szenario mit einer einzelnen Region: Private Link und DNS in Azure Virtual WAN

Azure Private Link

Azure DNS

Azure Firewall

Azure Virtual WAN

In diesem Artikel wird gezeigt, wie Sie eine PaaS-Ressource über einen privaten Endpunkt für eine bestimmte Workload in einer einzelnen Region verfügbar machen. In diesem Szenario ist die Netzwerktopologie Hub-Spoke, und der Hub ist ein Azure Virtual WAN-Hub.

Wichtig

Dieser Artikel ist Teil einer Reihe von Azure Private Link und Azure DNS in Virtual WAN und baut auf der im Szenarioleitfaden definierten Netzwerktopologie auf. Lesen Sie zuerst die Übersichtsseite, um die Basisnetzwerkarchitektur und die wichtigsten Herausforderungen zu verstehen.

Szenario

Abbildung 1: Szenario mit einer einzelnen Region für Virtual WAN mit Private Link und Azure DNS – die Herausforderung

Laden Sie eine Visio-Datei dieser Architektur herunter. In diesem Abschnitt wird das Szenario definiert und die Herausforderung für dieses Szenario neu definiert (die Herausforderung entspricht dem nicht funktionierenden Beispiel auf der Übersichtsseite). Die Architektur des anfänglichen Szenarios basiert auf der in der Übersicht definierten Anfangsnetzwerktopologie. Im Folgenden sind die Ergänzungen und Änderungen aufgeführt:

Es gibt nur eine Region mit einem virtuellen Hub.
Es gibt ein Azure Storage-Konto in der Region, für das der Zugriff auf öffentliche Netzwerke deaktiviert ist. In diesem Szenario wird davon ausgegangen, dass nur eine Workload auf das Speicherkonto zugreift.
Zunächst ist ein einzelnes virtuelles Netzwerk mit dem virtuellen Hub verbunden.
Das virtuelle Netzwerk verfügt über ein Workloadsubnetz, das einen VM-Client enthält.
Das virtuelle Netzwerk enthält ein Subnetz für private Endpunkte, das einen privaten Endpunkt für das Speicherkonto enthält.

Ergebnis bei Erfolg

Der Azure Virtual Machine-Client kann über den privaten Endpunkt des Speicherkontos, der sich im selben virtuellen Netzwerk befindet, eine Verbindung mit dem Azure Storage-Konto herstellen, und alle anderen Zugriffe auf das Speicherkonto werden blockiert.

Impediment

Sie benötigen einen DNS-Eintrag im DNS-Flow, der den vollqualifizierten Domänennamen (FQDN) des Speicherkontos wieder in die private IP-Adresse des privaten Endpunkts auflösen kann. Wie in der Übersicht beschrieben, gibt es zwei Herausforderungen für das Szenario:

Es ist nicht möglich, eine private DNS-Zone, die die erforderlichen DNS-Einträge für Speicherkonten verwaltet, mit einem virtuellen Hub zu verknüpfen.
Sie können eine private DNS-Zone mit dem Workloadnetzwerk verknüpfen, sodass Sie davon ausgehen könnten, dass dies funktioniert. Leider sieht die Baselinearchitektur vor, dass für jedes verbundene virtuelle Netzwerk DNS-Server konfiguriert sind, um auf die Verwendung des Azure Firewall DNS-Proxys zu verweisen.

Da Sie eine private DNS-Zone nicht mit einem virtuellen Hub verknüpfen können und das virtuelle Netzwerk für die Verwendung des Azure Firewall DNS-Proxys konfiguriert ist, verfügen Azure DNS-Server über keinen Mechanismus, um den FQDN (FQDN) des Speicherkontos in die private IP-Adresse des privaten Endpunkts aufzulösen. Demzufolge empfängt der Client eine fehlerhafte DNS-Antwort.

DNS- und HTTP-Flows

Sehen wir uns den DNS und die daraus resultierenden HTTP-Anforderungsflows für diese Workload an. Anhand der Überprüfung können wir das zuvor beschriebene Impediment visualisieren.

Abbildung 2: Szenario mit einer einzelnen Region für Virtual WAN mit Private Link und Azure DNS – die Herausforderung

Laden Sie eine Visio-Datei dieser Architektur herunter.

DNS-Flow

Die DNS-Abfrage für stgworkload00.blob.core.windows.net vom Client wird an den konfigurierten DNS-Server gesendet, das heißt Azure Firewall im regionalen Hub mit Peering.
Azure Firewall leitet die Anforderung an Azure DNS weiter. Da es nicht möglich ist, eine private DNS-Zone mit einem virtuellen Hub zu verknüpfen, weiß Azure DNS nicht, wie der FQDN in die private IP-Adresse des privaten Endpunkts aufgelöst werden soll. Er weiß, wie der FQDN in die öffentliche IP-Adresse des Speicherkontos aufgelöst wird, sodass die öffentliche IP-Adresse des Speicherkontos zurückgegeben wird.

HTTP-Flow

Mit dem DNS-Ergebnis, der öffentlichen IP-Adresse des Speicherkontos, gibt der Client eine HTTP-Anforderung an stgworkload00.blob.core.windows.net aus.
Die Anforderung wird an die öffentliche IP-Adresse des Speicherkontos gesendet. Diese Anforderung schlägt aus verschiedenen Gründen fehl:
- Die NSG im Workloadsubnetz lässt diesen Datenverkehr ins Internet möglicherweise nicht zu.
- Die Azure Firewall, die ausgehenden Datenverkehr in Internet filtert, verfügt wahrscheinlich nicht über eine Anwendungsregel zur Unterstützung dieses Flows.
- Selbst wenn sowohl die NSG als auch Azure Firewall über Zertifikate für diesen Anforderungsflow verfügten, ist das Speicherkonto so konfiguriert, dass der gesamte Zugriff auf öffentliche Netzwerke blockiert wird. Der Versuch verstößt letztendlich gegen unser Ziel, den Zugriff auf das Speicherkonto nur über den privaten Endpunkt zuzulassen.

Lösung: Einrichten einer virtuellen Huberweiterung für DNS

Eine Lösung für die Herausforderung besteht darin, dass das Unternehmensnetzwerkteam eine virtuelle Huberweiterung für DNS implementiert. Die einzige Verantwortung für die DNS-Erweiterung für virtuelle Hubs besteht darin, Workloadteams zu aktivieren, die private DNS-Zonen in ihrer Architektur in dieser beginnenden Virtual WAN-Hubtopologie verwenden müssen.

Die DNS-Erweiterung wird als virtuelles Netzwerk-Spoke implementiert, das mit dem regionalen virtuellen Hub verknüpft ist. Es ist möglich, private DNS-Zonen mit diesem virtuellen Netzwerk zu verknüpfen. Das virtuelle Netzwerk enthält auch einen Azure DNS Private Resolver, mit dem Dienste außerhalb dieses virtuellen Netzwerks, z. B. Azure Firewall, Werte von allen verknüpften privaten DNS-Zonen abfragen und empfangen können. Im Folgenden sind die Komponenten einer typischen virtuellen Huberweiterung für DNS sowie einige erforderliche Konfigurationsänderungen aufgeführt:

Ein neues virtuelles Spoke-Netzwerk, das mit dem virtuellen Hub der Region verknüpft ist. Dieser Spoke ist wie jeder andere Spoke konfiguriert, was bedeutet, dass standardmäßige DNS-Server und Routingregeln die Verwendung von Azure Firewall im regionalen Hub erzwingen.
Eine DNS Private Resolver-Ressource wird mit einem eingehenden Endpunkt im virtuellen Spoke-Netzwerk bereitgestellt.
Eine private DNS-Zonenressource namens privatelink.blob.core.windows.net wird erstellt.
- Diese Zone enthält einen A-Datensatz, der vom FQDN-Namen des Speicherkontos der privaten IP-Adresse des privaten Endpunkts für das Speicherkonto zugeordnet wird.
- Die private DNS-Zone ist mit dem virtuellen Spoke-Netzwerk verknüpft.
- Wenn die rollenbasierte Zugriffssteuerung (Role-Based Access Control, RBAC) dies zulässt, können Sie die automatische Registrierung oder vom Dienst verwaltete Einträge verwenden, um diese DNS-Einträge zu verwalten. Andernfalls ist eine manuelle Verwaltung möglich.
Im regionalen Hub wird der DNS-Server der Azure Firewall so geändert, dass er auf den eingehenden Endpunkt des DNS Private Resolver verweist.

Das folgende Diagramm veranschaulicht die Architektur zusammen mit den DNS- und HTTP-Flows.

Abbildung 3: Arbeitslösung für ein Regionsszenario für Virtual WAN mit Private Link und DNS

Laden Sie eine Visio-Datei dieser Architektur herunter.

DNS-Flow für das Einrichten einer virtuellen Huberweiterung für DNS

Die DNS-Abfrage für stgworkload00.blob.core.windows.net vom Client wird an den konfigurierten DNS-Server gesendet, das heißt Azure Firewall im regionalen Hub mit Peering – in diesem Fall 10.100.0.132.

Abbildung 4: DNS-Serverkonfiguration für die Workload des virtuellen Netzwerks
Azure Firewall sendet die Anforderung an den regionalen Azure DNS Private Resolver in der Huberweiterung – in diesem Fall 10.200.1.4, die private IP-Adresse des eingehenden Endpunkts des DNS Private Resolvers.

Screenshot der Azure Firewall-Richtlinie, in der der DNS-Proxy aktiviert ist und die DNS-Server auf „Benutzerdefiniert“ festgelegt sind. Der Einstiegspunkt verweist auf die private IP-Adresse des DNS Private Resolver-Eingabeendpunkts.

Abbildung 5: DNS-Konfiguration in Azure Firewall-Richtlinie
Der DNS Private Resolver sendet die Anforderung an Azure DNS. Da eine private DNS-Zone mit dem virtuellen Netzwerk verknüpft ist, das den eingehenden Endpunkt enthält, kann Azure DNS Datensätze in diesen verknüpften privaten DNS-Zonen verwenden.

Abbildung 6: Links zum virtuellen Netzwerk der DNS-Zone
Azure DNS konsultiert die verknüpfte private DNS-Zone und löst den FQDN von stgworkload00.blob.core.windows.net in 10.1.2.4 auf, d. h. die IP-Adresse des privaten Endpunkts für das Speicherkonto. Diese Antwort wird für Azure Firewall DNS bereitgestellt, das dann die private IP-Adresse des Speicherkontos an den Client zurückgibt.

Abbildung 7: Private DNS-Zone mit dem A-Eintrag für den privaten Endpunkt des Speicherkontos

HTTP-Flow

Mit dem DNS-Ergebnis, der privaten IP-Adresse des Speicherkontos, gibt der Client eine HTTP-Anforderung an stgworkload00.blob.core.windows.net aus.
Die Anforderung wird an die private IP-Adresse (10.1.2.4) des Speicherkontos gesendet. Diese Anforderung wird erfolgreich weitergeleitet, vorausgesetzt, dass keine in Konflikt stehenden Einschränkungen für die lokalen Netzwerksicherheitsgruppen im Clientsubnetz oder im Subnetz des privaten Endpunkts bestehen. Es ist wichtig zu verstehen, dass die Anforderung nicht über Azure Firewall weitergeleitet wird, obwohl Azure Firewall den privaten Datenverkehr sichert, da sich der private Endpunkt im selben virtuellen Netzwerk wie der Client befindet. Das bedeutet, dass für dieses Szenario keine Azure Firewall-Zertifikate erstellt werden müssen.
Eine private Verbindung mit dem Speicherkonto wird über den Private Link-Dienst hergestellt. Das Speicherkonto lässt nur privaten Netzwerkzugriff zu und akzeptiert die HTTP-Anforderung.

Überlegungen zur Erweiterung virtueller Hubs für DNS

Beachten Sie bei der Implementierung der Erweiterung für Ihr Unternehmen die folgenden Anleitungen.

Das Bereitstellen der DNS-Erweiterung ist keine Aufgabe für das Workloadteam. Diese Aufgabe ist eine Unternehmensnetzwerkfunktion und sollte eine Implementierungsentscheidung mit diesen Personen sein.
Die DNS-Erweiterung und private DNS-Zonen müssen vor dem Hinzufügen eines PaaS-Diensts vorhanden sein, für den Sie DNS-Einträge für private Endpunkte konfigurieren möchten.
Die Erweiterung des virtuellen Hubs ist eine regionale Ressource. Vermeiden Sie regionsübergreifenden Datenverkehr und richten Sie eine Huberweiterung pro regionalem Hub ein, für den eine DNS-Auflösung des privaten Endpunkts erwartet wird.

Virtuelles Spoke-Netzwerk

Gemäß dem Prinzip der alleinigen Verantwortung sollte das virtuelle Netzwerk für die DNS-Erweiterung nur die Ressourcen enthalten, die für die DNS-Auflösung erforderlich sind, und nicht für andere Ressourcen freigegeben werden.
Das virtuelle Netzwerk für die DNS-Erweiterung sollte die gleichen Konfigurationsrichtlinien wie unter Hinzufügen von Spoke-Netzwerken befolgen.

Azure DNS Private Resolver

Jede Region sollte über eine DNS-Erweiterung des virtuellen Hubs mit einem DNS Private Resolver verfügen.
Der DNS Private Resolver erfordert nur einen eingehenden Endpunkt und keine ausgehenden Endpunkte für dieses Szenario. Die private IP-Adresse für den eingehenden Endpunkt wird für den benutzerdefinierten DNS-Dienst in der Azure Firewall-Richtlinie festgelegt (siehe Abbildung 5).
Für eine höhere Resilienz und eine höhere Lastbehandlung können Sie mehrere DNS Private Resolver-Instanzen pro Region bereitstellen, wobei der Azure DNS-Proxy mit mehreren IP-Adressen für die Auflösung über Proxy konfiguriert ist.

Abbildung 8: Eingehende Endpunkte für den DNS Private Resolver
Befolgen Sie die Einschränkungen für virtuelle Netzwerke für den DNS Private Resolver.
Die Netzwerksicherheitsgruppe im Subnetz für den eingehenden Endpunkt des DNS Private Resolvers sollte nur UDP-Datenverkehr von seinem regionalen Hub an Port 53 zulassen. Sie sollten den gesamten ein- und ausgehenden Datenverkehr blockieren.

Private DNS-Zone

Da der Azure DNS Private Resolver DNS über Azure DNS auflöst, kann Azure DNS alle privaten DNS-Zonen aufnehmen, die mit dem virtuellen Netzwerk des eingehenden Subnetzes verknüpft sind.

Verknüpfen Sie die private DNS-Zone mit der virtuellen Hub-Erweiterung für das virtuelle DNS-Netzwerk.
Befolgen Sie die Anleitung zum Verwalten privater DNS-Zonen für private Endpunkte.
Wenn Sie erwarten, dass PaaS-Ressourcenbesitzer ihre eigenen Einträge verwalten, konfigurieren Sie die RBAC entsprechend oder implementieren Sie eine Lösung wie die von Private Link- und DNS-Integration im großen Stil.

Überlegungen zu Szenarien

Mit einer gut verwalteten DNS-Erweiterung für virtuelle Hubs kehren wir zur Workload zurück und behandeln einige zusätzliche Punkte, um die Ziele des Ergebnisses bei Erfolg in diesem Szenario zu erreichen.

Speicherkonto

Festlegen des Zugriffs auf das öffentliche Netzwerk: Deaktiviert unter Netzwerkkonnektivität, um sicherzustellen, dass nur über private Endpunkte auf das Speicherkonto zugegriffen werden kann.
Fügen Sie einen privaten Endpunkt zu einem dedizierten privaten Endpunktsubnetz im virtuellen Netzwerk der Workload hinzu.
Senden Sie Azure-Diagnose an den Log Analytics-Arbeitsbereich der Workload. Sie können die Zugriffsprotokolle verwenden, um Konfigurationsprobleme zu beheben.

Sicherheit des privaten Endpunkts

Eine Anforderung dieser Lösung besteht darin, die Offenlegung dieses Speicherkontos zu begrenzen. Nachdem Sie den öffentlichen Internetzugriff auf Ihre PaaS-Ressource entfernt haben, sollten Sie sich mit der Sicherheit privater Netzwerke befassen.

Wenn Azure Firewall privaten Datenverkehr in einer Virtual WAN Hub-Spoke-Topologie schützt, verweigert Azure Firewall standardmäßig die Spoke-to-Spoke-Konnektivität. Diese Standardeinstellung verhindert, dass Workloads in anderen Spoke-Netzwerken auf private Endpunkte (und andere Ressourcen) im virtuellen Workloadnetzwerk zugreifen. Der Datenverkehr, der vollständig innerhalb eines virtuellen Netzwerks stattfindet, wird nicht über Azure Firewall weitergeleitet. Um den Zugriff innerhalb des virtuellen Netzwerks zu steuern und einen präziseren Schutz hinzuzufügen, sollten Sie die folgenden Empfehlungen für Netzwerksicherheitsgruppen (NSG) berücksichtigen.

Erstellen Sie eine Anwendungssicherheitsgruppe (Application Security Group, ASG), um Ressourcen zu gruppieren, die ähnliche Anforderungen an eingehenden oder ausgehenden Zugriff haben. Verwenden Sie in diesem Szenario eine ASG für die Client-VMs, die auf Speicher zugreifen müssen, und eine für Speicherkonten, auf die zugegriffen wird. Weitere Informationen finden Sie unter Konfigurieren einer Anwendungssicherheitsgruppe (ASG) mit einem privaten Endpunkt.
Stellen Sie sicher, dass das Subnetz, das die Workload-VM enthält, über eine NSG verfügt.
Stellen Sie sicher, dass das Subnetz, das die privaten Endpunkte enthält, über eine NSG verfügt.

NSG-Regeln für Subnetz mit Workload-VM

Konfigurieren Sie neben allen anderen Netzwerkregeln, die Ihre Workload erfordert, die folgenden Regeln.

Regeln für ausgehenden Datenverkehr:
- Zulassen, dass die Compute-ASG auf die Speicherkonto-ASG zugreifen kann.
- Erlauben Sie die Verbindung zwischen der Compute-ASG und der privaten IP des regionalen Hubs der Azure Firewall für UDP auf Port 53.

*Abbildung 9: NSG-Regeln für Workload-Subnetz

NSG-Regeln für Subnetz mit privaten Endpunkten

Es gilt als bewährte Methode, private Endpunkte in einem kleinen, dedizierten Subnetz innerhalb des verbrauchenden virtuellen Netzwerks verfügbar zu machen. Ein Grund dafür ist, dass Sie benutzerdefinierte Routen und Netzwerksicherheitsgruppenrichtlinien für private Endpunkte anwenden können, um zusätzliche Datenverkehrskontrolle und -sicherheit zu erhalten.

In diesem Szenario kann eine stark restriktive Netzwerksicherheitsgruppe angewendet werden.

Regeln für eingehenden Datenverkehr:
- Zulassen, dass die Compute-ASG auf die Speicherkonto-ASG zugreifen kann
- Ablehnen des gesamten anderen Datenverkehrs
Regeln für ausgehenden Datenverkehr:
- Ablehnen jeglichen Datenverkehrs

*Abbildung 10: NSG-Regel für Subnetz des privaten Endpunkts

Sicherheit für privaten Endpunkt in der Praxis

In der folgenden Abbildung wird veranschaulicht, wie das Ausführen der beschriebenen Überlegungen Defense-in-Depth-Sicherheit gewährleisten kann. Das Diagramm zeigt ein zweites virtuelles Spoke-Netzwerk mit einem zweiten virtuellen Computer. Diese Workload kann nicht auf den privaten Endpunkt zugreifen.

Abbildung 11: Arbeitslösung für ein Regionsszenario für Virtual WAN mit Private Link und DNS

Laden Sie eine Visio-Datei dieser Architektur herunter.

DNS-Flow

Der DNS-Flow ist genau derselbe wie im Lösungsfluss.

Hervorzuheben ist, dass der FQDN in die private IP-Adresse und nicht in die öffentliche IP-Adresse aufgelöst wird. Diese Auflösung bedeutet, dass alle Spokes immer die private IP-Adresse dieses Diensts erhalten. In einem anderen Szenario wird beschrieben, wie Sie diesen Ansatz verwenden können, um einen PaaS-Dienst für mehrere Workloads gemeinsam nutzen zu können. Für dieses Szenario mit einer einzelnen Workload ist dies kein Problem.

HTTP-Flow

Mit dem DNS-Ergebnis, der privaten IP-Adresse des Speicherkontos, gibt der Client eine HTTP-Anforderung an stgworkload00.blob.core.windows.net aus.
Die Anforderung wird an die private IP-Adresse des Speicherkontos gesendet. Diese Anforderung schlägt aus verschiedenen Gründen fehl:
- Azure Firewall ist zum Schützen des privaten Datenverkehrs konfiguriert, sodass die Anforderung verarbeitet wird. Sofern Azure Firewall nicht über eine Netzwerk- oder Anwendungsregel verfügt, um den Flow zuzulassen, blockiert Azure Firewall die Anforderung.
- Sie müssen Azure Firewall nicht im Hub verwenden, um privaten Datenverkehr zu schützen. Wenn Ihr Netzwerk beispielsweise privaten regionsübergreifenden Datenverkehr unterstützt, ist die NSG im Subnetz des privaten Endpunkts weiterhin so konfiguriert, dass der gesamte Datenverkehr außer den Compute-ASG-Quellen innerhalb des virtuellen Netzwerks blockiert wird, das die Workload hostet.

Zusammenfassung

In diesem Artikel wird ein Szenario vorgestellt, in dem ein VM-Client über den privaten Endpunkt des Speicherkontos eine Verbindung mit dem Azure Storage-Konto herstellt. Der Endpunkt befindet sich im selben virtuellen Netzwerk wie der Client. Alle anderen Zugriffe auf das Speicherkonto werden blockiert. Dieses Szenario benötigt einen DNS-Eintrag im DNS-Flow, der den vollqualifizierten Domänennamen (FQDN) des Speicherkontos wieder in die private IP-Adresse des privaten Endpunkts auflösen kann.

Die anfängliche Netzwerktopologie für dieses Szenario bringt zwei Herausforderungen mit sich:

Es ist nicht möglich, eine private DNS-Zone mit den erforderlichen DNS-Einträgen für das Speicherkonto mit dem virtuellen Hub zu verknüpfen.
Das Verknüpfen einer privaten DNS-Zone mit dem Workloadsubnetz funktioniert nicht. Die anfängliche Netzwerktopologie erfordert, dass standardmäßige DNS-Server- und Routingregeln die Verwendung von Azure Firewall im regionalen Hub erzwingen.

Die vorgeschlagene Lösung besteht darin, dass das Unternehmensnetzwerkteam eine virtuelle Huberweiterung für DNS implementiert. Diese Erweiterung ermöglicht es dem Unternehmensnetzwerkteam, freigegebene DNS-Dienste für Workload-Spokes verfügbar zu machen, die diese benötigen.

Freigeben über

Szenario mit einer einzelnen Region: Private Link und DNS in Azure Virtual WAN