Verwenden von Private Link in Virtual WAN

Artikel
10/16/2024

Mit der Technologie Azure Private Link können Sie Platform-as-a-Service-Angebote von Azure über private IP-Adressen verbinden, indem Sie private Endpunkte verfügbar machen. 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 einem oder mehreren Hubs bereitgestellt haben und mindestens zwei virtuelle Netzwerke mit Virtual 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 privater Verbindung im Virtual WAN

Verbindungen mit privaten Endpunkten sind in Azure zustandsbehaftet. Wenn eine Verbindung mit einem privaten Endpunkt über Virtual WAN hergestellt wird, wird Datenverkehr über einen oder mehrere Datenverkehrs-Hops über verschiedene Virtual WAN-Komponenten weitergeleitet (z. B. Virtual Hub-Router, ExpressRoute-Gateway, VPN Gateway, Azure Firewall oder NVA). Der genaue Hops-Datenverkehr basiert auf Ihren Konfigurationen für das Virtual WAN-Routing. Hinter den Kulissen sendet die softwaredefinierte Netzwerkschicht von Azure alle Pakete im Zusammenhang mit einem einzelnen 5-Tupel-Flow an eine der Back-End-Instanzen, die unterschiedliche Virtual WAN-Komponenten bedienen. Asymmetrisch weitergeleiteter Datenverkehr (z. B. Datenverkehr, der einem einzelnen 5-Tupel-Flow entspricht, der an verschiedene Back-End-Instanzen weitergeleitet wird) wird nicht unterstützt und von der Azure-Plattform gelöscht.

Bei Wartungsereignissen in der Virtual WAN-Infrastruktur werden Back-End-Instanzen einzeln neu gestartet, was zu zeitweiligen Verbindungsproblemen mit dem privatem Endpunkt führen kann, da die Instanz, die den Flow verwaltet, vorübergehend nicht verfügbar ist. Ein ähnliches Problem kann auftreten, wenn die Azure Firewall oder der virtuelle Hubrouter skaliert werden. Für denselben Datenverkehrsflow kann ein Lastenausgleich auf eine neue Back-End-Instanz durchgeführt werden, die sich von der aktuell gewarteten Instanz unterscheidet.

Um die Auswirkungen von Wartungs- und horizontalen Skalierungsereignissen auf Private Link- oder privaten Endpunktdatenverkehr zu verringern, sollten Sie die folgenden bewährten Methoden berücksichtigen:

Konfigurieren Sie den TCP-Timeoutwert Ihrer lokalen Anwendung so, dass er zwischen 15 und 30 Sekunden liegt. Bei einem kleineren TCP-Timeoutwert kann der Anwendungsdatenverkehr schneller von Wartungs- und horizontalen Skalierungsereignissen wiederhergestellt werden. Testen Sie alternativ verschiedene Timeoutwerte der Anwendung, um ein geeignetes Timeout basierend auf Ihren Anforderungen zu ermitteln.
Skalieren Sie virtuelle WAN-Komponenten vor, um Datenverkehrsbursts zu bewältigen und das Auftreten von Autoskalierungsereignissen zu verhindern. Für den virtuellen Hubrouter können Sie die minimalen Routinginfrastruktureinheiten auf Ihrem Hubrouter festlegen, um die Skalierung während Datenverkehrsbursts zu verhindern.

Wenn Sie über VPN oder ExpressRoute eine lokale Verbindung zwischen Azure und Ihrem lokalen Gerät herstellen, stellen Sie schließlich sicher, dass Ihr lokales Gerät 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 privaten Endpunktverkehr 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 den privaten Endpunkt auswählen, den Sie erstellt haben, werden die private IP-Adresse sowie ihr vollqualifizierter Domänenname (Fully Qualified Domain Name, FQDN) angezeigt. Der private Endpunkt sollte über eine IP-Adresse im Bereich des VNet (10.1.3.0/24) verfügen:

Ü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. Zunächst wird überprüft, ob die DNS-Auflösung funktioniert und der vollqualifizierte Domänenname der Azure SQL-Datenbank in eine private IP-Adresse im gleichen VNET aufgelöst wird, in dem der private Endpunkt bereitgestellt wurde (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 aus der vorherigen Ausgabe ersehen können, ist der FQDN wantest.database.windows.net zu wantest.privatelink.database.windows.net zugeordnet, und die am privaten Endpunkt erstellte private DNS-Zone wird in die private IP-Adresse 10.1.3.228 aufgelöst. Die Überprüfung der privaten DNS-Zone ergibt, dass für den privaten Endpunkt, der der privaten IP-Adresse zugeordnet ist, ein A-Datensatz vorhanden 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.

Freigeben über