Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Azure Private Link ist eine Technologie, die Ihnen die Möglichkeit bietet, Azure Platform-as-a-Service-Angebote über private IP-Adressen zu verbinden, indem Private Endpunkte zur Verfügung gestellt werden. Mit Azure Virtual WAN können Sie einen privaten Endpunkt in einem der virtuellen Netzwerke bereitstellen, die mit einem beliebigen virtuellen Hub verbunden sind. Durch diese private Verbindung wird Konnektivität mit einem beliebigen anderen virtuellen Netzwerk (oder seiner Verzweigung) hergestellt, das mit derselben Virtual WAN-Instanz verbunden ist.
Voraussetzungen
Bei den Schritten in diesem Artikel wird davon ausgegangen, dass Sie ein virtuelles WAN mit mindestens einem Hub und mindestens zwei virtuellen Netzwerken bereitgestellt haben, die mit virtuellem WAN verbunden sind.
Führen Sie die Schritte in den folgenden Artikeln aus, um ein neues virtuelles WAN und einen neuen Hub zu erstellen:
Überlegungen zum Routing mit Private Link im Virtual WAN
Die Konnektivität privater Endpunkte in Azure ist statusbasiert. Wenn eine Verbindung zu einem privaten Endpunkt über Virtual WAN hergestellt wird, wird der Datenverkehr über einen oder mehrere Hops durch verschiedene Virtual WAN-Komponenten geleitet (z.B. Virtual Hub Router, ExpressRoute Gateway, VPN Gateway, Azure Firewall oder NVA). Welche Hops der Datenverkehr genau durchläuft, hängt von Ihren Virtual WAN Routing-Konfigurationen ab. Im Hintergrund sendet die Software-definierte Networking-Schicht von Azure alle Pakete, die zu einem einzigen 5-Tupel-Flow gehören, an eine der Backend-Instanzen, die verschiedene Virtual WAN-Komponenten bedienen. Asymmetrisch gerouteter Datenverkehr (z.B. Datenverkehr, der einem einzelnen 5-Tupel Flow entspricht, der an verschiedene Backend Instanzen geroutet wird) wird von der Azure Plattform nicht unterstützt und wird von ihr fallen gelassen.
Bei Wartungsereignissen in der virtuellen WAN-Infrastruktur werden Back-End-Instanzen jeweils einzeln neu gestartet. Dies kann zu zeitweiligen Verbindungsproblemen mit privatem Endpunkt führen, da die Instanz, die den Fluss verwaltet, vorübergehend nicht verfügbar ist. Das gleiche Problem kann auftreten, wenn die Azure Firewall oder der Virtual Hub Router horizontal skalieren. Derselbe Datenverkehr kann durch Load-Balancing auf eine neue Backend-Instanz verteilt werden, die sich von der Instanz unterscheidet, die den Flow aktuell bedient.
Um die Auswirkungen von Wartungs- und Scale-Out-Ereignissen auf den Datenverkehr von Private Link oder privaten Endpunkten zu beheben, sollten Sie die folgenden bewährten Verfahren beachten:
- Konfigurieren Sie den TCP-Timeoutwert einer beliebigen Anwendung (unabhängig davon, ob sie lokal oder in einem anderen virtuellen Azure-Netzwerk gehostet wird), das auf den privaten Link/privaten Endpunkt zugreift, um zwischen 15 und 30 Sekunden zu fallen. Ein kleinerer TCP Timeout-Wert bietet die Möglichkeit, dass sich der Datenverkehr von Anwendungen schneller von Wartungs- und horizontal skalierenden Ereignissen erholen kann. Testen Sie alternativ verschiedene Anwendungstimeoutwerte, um ein geeignetes Timeout basierend auf Ihren Anforderungen zu ermitteln.
- Skalieren Sie die Virtual WAN-Komponenten so, dass sie Datenverkehrsbursts handhaben können, um das Auftreten von Autoscale-Ereignissen zu verhindern. Für den Virtual Hub Router können Sie die minimalen Einheiten der Routing-Infrastruktur auf Ihrem Hub-Router festlegen, um eine Skalierung bei Datenverkehrsbursts zu verhindern.
Wenn Sie schließlich die Konnektivität zwischen Azure und on-premises über VPN oder ExpressRoute nutzen, stellen Sie sicher, dass Ihr Gerät on-premises so konfiguriert ist, dass es denselben VPN-Tunnel oder denselben Microsoft Enterprise Edge-Router als Next-Hop für jedes 5-Tupel verwendet, das dem Datenverkehr des privaten Endpunkts entspricht.
Erstellen eines Private Link-Endpunkts
Sie können einen Private Link-Endpunkt für viele verschiedene Dienste erstellen. In diesem Beispiel wird Azure SQL-Datenbank verwendet. Weitere Informationen zum Erstellen eines privaten Endpunkts für eine Azure SQL-Datenbank finden Sie in Schnellstart: Erstellen eines privaten Endpunkts mit dem Azure-Portal. Die folgende Abbildung zeigt die Netzwerkkonfiguration der Azure SQL-Datenbank:
Nachdem Sie die Azure SQL-Datenbank erstellt haben, können Sie die privaten Endpunkte durchsuchen, um die IP-Adresse des privaten Endpunkts zu überprüfen:
Wenn Sie auf den privaten Endpunkt klicken, den wir erstellt haben, sollte die private IP-Adresse und der vollqualifizierte Domänenname (Fully Qualified Domain Name, FQDN) angezeigt werden. Der private Endpunkt sollte eine IP-Adresse im Bereich des VNet (10.1.3.0/24) haben:
Überprüfen der Konnektivität aus demselben VNET
In diesem Beispiel überprüfen Sie die Konnektivität mit Azure SQL-Datenbank von einer Linux-VM, auf der MS SQL-Tools installiert sind. Der erste Schritt besteht darin, sicherzustellen, dass die DNS-Auflösung funktioniert und der vollqualifizierte Domänenname der Azure SQL-Datenbank in eine private IP-Adresse aufgelöst wird, im selben VNet, in dem der private Endpunkt bereitgestellt wird (10.1.3.0/24):
nslookup wantest.database.windows.net
Server: 127.0.0.53
Address: 127.0.0.53#53
Non-authoritative answer:
wantest.database.windows.net canonical name = wantest.privatelink.database.windows.net.
Name: wantest.privatelink.database.windows.net
Address: 10.1.3.228
Wie Sie in der vorherigen Ausgabe sehen können, wird der FQDN wantest.database.windows.net auf wantest.privatelink.database.windows.net zugeordnet, so dass die private DNS-Zone, die entlang des privaten Endpunkts erstellt wird, auf die private IP-Adresse 10.1.3.228 aufgelöst wird. Wenn Sie sich die private DNS-Zone ansehen, wird bestätigt, dass ein A-Eintrag für den privaten Endpunkt der privaten IP-Adresse zugeordnet ist:
Nachdem wir die DNS-Auflösung erfolgreich überprüft haben, können wir versuchen, eine Verbindung mit der Datenbank herzustellen:
query="SELECT CONVERT(char(15), CONNECTIONPROPERTY('client_net_address'));"
sqlcmd -S wantest.database.windows.net -U $username -P $password -Q "$query"
10.1.3.75
Wie Sie sehen, wird eine spezielle SQL-Abfrage verwendet, die die Quell-IP-Adresse zurückgibt, die auf dem SQL-Server für den Client sichtbar ist. In diesem Fall wird für den Server der Client mit seiner privaten IP-Adresse (10.1.3.75) angezeigt. Das bedeutet, dass der Datenverkehr direkt aus dem VNET an den privaten Endpunkt geleitet wird.
Legen Sie die Variablen username und password so fest, dass sie den in der Azure SQL-Datenbank-Instanz definierten Anmeldeinformationen entsprechen, damit die Beispiele in diesem Leitfaden ausgeführt werden können.
Herstellen einer Verbindung von einem anderen VNET
Da jetzt ein VNET in Azure Virtual WAN mit dem privaten Endpunkt verbunden ist, können alle anderen VNETs und Verzweigungen, die mit Virtual WAN verbunden sind, ebenfalls darauf zugreifen. Sie müssen die Konnektivität über eines der von Azure Virtual WAN unterstützten Modelle bereitstellen, z. B. das Any-to-Any-Szenario oder das Szenario von VNET mit gemeinsamen Diensten, um nur zwei Beispiele zu nennen.
Sobald die Konnektivität zwischen dem VNET oder der Verzweigung mit dem VNET besteht, in dem der private Endpunkt bereitgestellt wurde, müssen Sie die DNS-Auflösung konfigurieren:
- Wenn Sie die Verbindung mit dem privaten Endpunkt über ein VNET herstellen, können Sie dieselbe private Zone verwenden, die mit der Azure SQL-Datenbank erstellt wurde.
- Wenn die Verbindung mit dem privaten Endpunkt von einer Verzweigung erfolgt (Site-to-Site-VPN, Point-to-Site-VPN oder ExpressRoute), müssen Sie die lokale DNS-Auflösung verwenden.
In diesem Beispiel stellen Sie eine Verbindung über ein anderes VNet her. Zuerst fügen Sie die private DNS-Zone an das neue VNet an, damit die Workloads den vollqualifizierten Domänennamen der Azure SQL-Datenbank-Instanz in die private IP-Adresse auflösen können. Dies erfolgt durch Verknüpfen der privaten DNS-Zone mit dem neuen VNET:
Nun sollte jeder virtuelle Computer im zugeordneten VNET den FQDN der Azure SQL-Datenbank ordnungsgemäß in die private IP-Adresse des Private Link auflösen:
nslookup wantest.database.windows.net
Server: 127.0.0.53
Address: 127.0.0.53#53
Non-authoritative answer:
wantest.database.windows.net canonical name = wantest.privatelink.database.windows.net.
Name: wantest.privatelink.database.windows.net
Address: 10.1.3.228
Um zu überprüfen, ob das VNET (10.1.1.0/24) über Konnektivität mit dem ursprünglichen VNET verfügt, in dem der private Endpunkt konfiguriert wurde (10.1.3.0/24), können Sie die effektive Routingtabelle auf jedem virtuellen Computer im VNET überprüfen:
Wie Sie sehen können, gibt es eine Route, die auf das VNet 10.1.3.0/24 verweist, das von den Gateways für virtuelle Netzwerke in Azure Virtual WAN eingefügt wurde. Jetzt können wir die Konnektivität mit der Datenbank testen:
query="SELECT CONVERT(char(15), CONNECTIONPROPERTY('client_net_address'));"
sqlcmd -S wantest.database.windows.net -U $username -P $password -Q "$query"
10.1.1.75
In diesem Beispiel haben Sie gesehen, wie durch das Erstellen eines privaten Endpunkts in einem der VNets, die einer Virtual WAN-Instanz zugeordnet sind, Konnektivität mit den restlichen VNets und Verzweigungen in der Virtual WAN-Instanz bereitgestellt wird.
Nächste Schritte
Weitere Informationen zu Virtual WAN finden Sie unter Häufig gestellte Fragen.