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-Plattform as a Service (PaaS)-Dienste direkt aus privaten virtuellen Netzwerken, 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 (FQDN) eines Diensts, um eine Verbindung damit 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 zur Implementierung verschiedener Private Link-Szenarien bieten. 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 eine Netzwerkarchitektur, die als Ausgangspunkt für alle Szenarien in dieser Artikelreihe dient. Die Architektur 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, jeweils mit einem regionalen, durch die Azure Firewall gesicherten virtuellen Hub.
Jeder gesicherte regionale virtuelle Hub verfügt über die folgenden Sicherheitseinstellungen für Azure Virtual Network-Verbindungen:
- Internetdatenverkehr: Durch azure Firewall gesichert – Der gesamte Datenverkehr zum Internet fließt über die regionale Hubfirewall.
- Privater Datenverkehr: Durch die Azure-Firewall gesichert – Der gesamte Datenverkehr, der von der Sprach-zu-Speichen-Übertragung durch die regionale Hubfirewall geleitet wird.
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. Die Protokollierung dieser Ereignisse ist eine häufige Anforderung für die Netzwerksicherheitsprotokollierung.
Jeder verbundene virtuelle Netzwerk-Speichen hat seinen Standard-DNS-Server konfiguriert, um die private IP-Adresse der regionalen Hubfirewall zu sein. Andernfalls kann die FQDN-Regelauswertung nicht synchron sein.

Routing mit mehreren Regionen

Gesicherte virtuelle WAN-Hubs haben eingeschränkte Unterstützung für Die Inter-Hub-Konnektivität, wenn mehrere gesicherte virtuelle Hubs vorhanden sind. Diese Einschränkung wirkt sich auf Multi-Hub-, Regions- und regionsübergreifende Szenarien aus. Daher erleichtert die Netzwerktopologie nicht direkt die Filterung des privaten, regionsübergreifenden Datenverkehrs über die Azure Firewall. Unterstützung für diese Funktion wird mithilfe von Absichts- und Routingrichtlinien für virtuelle WAN-Hub-Routing bereitgestellt. Diese Funktion befindet sich derzeit in der Vorschauphase.

Bei dieser 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 gesicherten virtuellen Hub filtert, sondern stattdessen durchläuft.

Hinzufügen von Speichennetzwerken

Wenn Sie Speichennetzwerke hinzufügen, folgen sie den Einschränkungen, die in der Startnetzwerktopologie definiert sind. Insbesondere ist jedes Speichennetzwerk der Standardroutentabelle zugeordnet, die sich in seinem regionalen Hub befindet, 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 virtuelle Netzwerkverbindungen im virtuellen Hub

Wichtige Herausforderungen

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

Während die Verwendung von Virtual WAN Ihnen eine verwaltete Hub-Erfahrung bietet, besteht der Kompromiss darin, dass die Konfiguration des virtuellen Hubs oder die Möglichkeit, weitere Komponenten hinzuzufügen, eingeschränkt ist. Mit einer herkömmlichen Hub-Spoke-Topologie können Sie Arbeitsauslastungen in Speichen isolieren und gemeinsame Netzwerkdienste wie DNS-Einträge im selbstverwalteten Hub freigeben. 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 virtuellen WAN-Hubs zu verknüpfen, sodass jede DNS-Auflösung, die innerhalb des Hubs erfolgt, nicht über private Zonen informiert ist. Dies ist insbesondere ein Problem für Azure Firewall, der konfigurierte DNS-Anbieter für Workload-Speichen, der DNS für die FQDN-Auflösung verwendet.

Wenn Sie virtuelle WAN-Hubs verwenden, scheint es intuitiv zu sein, dass Sie private DNS-Zonen mit den virtuellen Speichennetzwerken 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 es wird erwartet, dass alle Speichen ihre regionale Firewall als DNS-Quelle verwenden. Azure DNS wird von der Firewall statt aus dem Netzwerk der Workload aufgerufen, sodass alle privaten DNS-Zonenlinks im Workload-Netzwerk in der Auflösung nicht verwendet werden.

Hinweis

Um die regionale Firewall so zu konfigurieren, dass es sich um den DNS-Anbieter des Speichens handeln soll, legen Sie den benutzerdefinierten DNS-Server im virtuellen Speichennetzwerk so fest, dass er auf die private IP-Adresse der Firewall anstelle des normalen Azure DNS-Werts verweist.

Angesichts der Komplexität, die sich aus der Aktivierung des DNS-Proxys in den regionalen Firewalls ergibt, sollten wir uns die Gründe für die Aktivierung ansehen.

Azure Firewall-Netzwerkregeln unterstützen FQDN-basierte Grenzwerte, um den Datenverkehr zu steuern, den Anwendungsregeln nicht verarbeiten. Dieses Feature erfordert, dass der DNS-Proxy aktiviert ist. Eine häufige Verwendung ist das Einschränken des NTP-Datenverkehrs (Network Time Protocol) auf bekannte Endpunkte, z time.windows.com. B. .
Sicherheitsteams können von der DNS-Anforderungsprotokollierung profitieren. Azure Firewall verfügt über integrierte Unterstützung für die DNS-Anforderungsprotokollierung, sodass alle Speichenressourcen Azure Firewall als DNS-Anbieter verwenden müssen, um eine umfassende Protokollierungsabdeckung zu gewährleisten.

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 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 aufgelö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.

Der Client gibt eine Anforderung an stgworkload00.blob.core.windows.net aus.
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    
```
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.
Da in der privaten DNS-Zone ein A-Eintrag vorhanden ist, der den FQDN zugeordnet ist, stgworkload00.privatelink.blob.core.windows.netwird die private IP-Adresse 10.1.2.4 zurückgegeben.

Durch Ausführen des folgenden Befehls von 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, die in diesem Fall 10.1.2.4 lautet.
Die Anforderung wird über den privaten Link an das Speicherkonto weitergeleitet.

Das Design funktioniert, weil Azure DNS:

Ist der konfigurierte DNS-Server für das virtuelle Netzwerk.
Ist der verknüpften privaten DNS-Zone bekannt.
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 kann, als die Standardeinstellung, d. h. die öffentliche IP-Adresse.

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

Laden Sie eine Visio-Datei dieser Architektur herunter.

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    
```
Die Firewall verfügt über einen DNS-Proxy, der die Standardeinstellung zum Weiterleiten von Anforderungen an Azure DNS aktiviert hat. Die Anforderung wird an Azure DNS weitergeleitet.
Azure DNS kann nicht in die private IP-Adresse des privaten Endpunkts aufgelöst werden stgworkload00.blob.core.windows.net , 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    
```
Der Client empfängt die private IP-Adresse für den Endpunkt "Privater Link" nicht und kann keine private Verbindung mit dem Speicherkonto herstellen.

Das oben genannte Verhalten wird erwartet. Es ist das Problem, das die Szenarien beheben.

Szenarien

Obwohl Lösungen für dieses Problem ähnlich sind, zeigen allgemeine Arbeitsauslastungsszenarien, wie die Lösungen die Anforderungen verschiedener Situationen erfüllen. 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 Arbeitsauslastungsanforderungen. Die Szenarien beginnen einfach mit einem Client, der auf einen einzelnen regionalen PaaS-Dienst zugreift. Sie erhalten inkrementellere Komplexität 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 virtuelle Computer als Eigenständige Für alle Azure-Ressourcen betrachten, die über eine NIC verfügen, die in einem virtuellen Netzwerk verfügbar gemacht wird, z. B. Vm Scale Sets, Azure Kubernetes Service-Knoten oder andere Dienste, die auf ähnliche Weise weitergeleitet werden.

Wichtig

Die Implementierung für private Links für das Azure Storage-Konto unterscheidet sich möglicherweise von anderen PaaS-Diensten auf subtile Weise, aber sie eignet sich gut für viele. Beispielsweise entfernen einige Dienste FQDN-Datensätze, während sie über private Verknüpfung verfügbar gemacht werden, was zu unterschiedlichen Verhaltensweisen führen kann, aber solche Unterschiede sind in der Regel kein Faktor in Lösungen für diese Szenarien.

Jedes Szenario beginnt mit dem gewünschten Endzustand und enthält details 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 beschreibt, wie gemeinsame Dienste isoliert und sicher als konzeptionelle Erweiterung auf einen regionalen Hub verfügbar gemacht werden. Die folgende Tabelle enthält Links zum Virtuellen Hub-Erweiterungsmuster und zu den Szenarien.

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

Nächste Schritte

Lesen der einzelnen Region, dediziertes PaaS-Ressourcenszenario