Warum Azure Point-to-Site VPN Ihre öffentliche IP nicht ändert

Ich verbinde den Azure-VPN-Client auf einem Windows-Laptop, öffne eine Adress-Echo-Seite und sehe dieselbe öffentliche Adresse, die mein Heimrouter vergeben hat. Währenddessen antwortet der Jump-Host unter 10.20.0.4, und ein privater Endpunktname wird aufgelöst, der Tunnel ist also nicht kaputt. Ein Point-to-Site-Gateway macht genau das, was seine Standardkonfiguration sagt: Es trägt die privaten Präfixe und lässt alles andere auf dem lokalen Link. Eine von Azure stammende Ausgangsadresse zu bekommen ist eine Änderung des Routing-Designs, keine Reparatur.

Was das Gateway standardmäßig bekannt gibt

Das Gateway verteilt Routen für den Adressraum des virtuellen Netzwerks sowie für Peering-Netzwerke, in denen Gateway-Transit erlaubt ist, und für lokale Präfixe, die über eine Site-to-Site-Verbindung oder BGP gelernt wurden. In dieser Menge gibt es kein 0.0.0.0/0. Ihr Betriebssystem behält seine Standardroute auf Wi-Fi oder Ethernet, daher gelangt ein Paket an eine öffentliche API gar nicht erst in den Tunnel.

Die Adresse, die ein Client im Tunnel erhält, ist ein privates Lease aus dem Point-to-Site-Pool. Sie identifiziert den Client gegenüber Ressourcen im VNet; sie ist keine Adresse, die das Internet sehen kann, und sie wird nie als Quelle einer ausgehenden Anfrage an eine SaaS-API erscheinen. Ein Allowlist-Eintrag, der um dieses Lease herum gebaut ist, kann nicht funktionieren, egal wie lange Sie warten, dass er in den Anbieter-Logs auftaucht.

Split-Tunnel und erzwungenes Tunneling nebeneinander

Nur die zweite Zeile ändert die Adresse, die ein entfernter Dienst sieht. Alles andere in dieser Tabelle sind Kosten und Betriebsfläche, die Sie akzeptieren, wenn der Ausgang innerhalb von Azure geprüft oder übersetzt werden muss. Wenn jemand Sie bittet, die öffentliche IP zu ändern, bittet er um die gesamte rechte Spalte, nicht um eine kleine Anpassung am Client.

Es gibt eine Zwischenlösung, die es wert ist, genannt zu werden, bevor Sie irgendetwas umbauen. Eine Proxy- oder Gateway-VM im VNet gibt Ihnen eine kontrollierte Quelladresse für die Anwendungen, die man darauf zeigen lassen kann, ohne die Standardroute des Clients zu verschieben. Das hält normales Surfen lokal und erfüllt trotzdem einen Partner, der nur einen einzigen API-Aufruf aus Azure braucht. Es scheitert, wenn die Anforderung wirklich den gesamten Datenverkehr betrifft, weil alles, was die Proxy-Einstellung ignoriert, trotzdem lokal hinausgeht.

Bringen Sie den Tunnel dazu, die Standardroute zu tragen

Auf einem Gateway für virtuelle Netzwerke ist der unterstützte Weg, den gesamten Internetverkehr der Clients in den Tunnel zu leiten, das Hinzufügen benutzerdefinierter Routen zur Point-to-Site-Konfiguration. Zwei Hälften decken den gesamten IPv4-Raum ab, und jede ist spezifischer als die lokale Standardroute, daher bevorzugt sie der Client, ohne etwas zu löschen:

Set-AzVirtualNetworkGateway -VirtualNetworkGateway GWOBJ -CustomRoute 0.0.0.0/1,128.0.0.0/1

Diese Zeile ist illustrativ und nicht vollständig zum Kopieren: Holen Sie zuerst das Gateway-Objekt mit Get-AzVirtualNetworkGateway und setzen Sie es anstelle von GWOBJ ein, und bestätigen Sie vor dem Ausführen, dass SKU und Bereitstellungsmodell benutzerdefinierte Routen akzeptieren. Dieselben Präfixe erscheinen im Portal auf der Seite der Point-to-Site-Konfiguration, dem sichereren Ort, um sie zu setzen, wenn Sie das Gateway noch nicht per Skript verwalten.

Eine Änderung dieser Präfixe macht das Clientpaket ungültig. Laden Sie das VPN-Clientpaket erneut herunter und installieren Sie es neu, denn die Routen reisen im Profil mit. Ein Client, der sich mit seinem alten Profil erneut verbindet, behält den alten Routensatz, und Sie können eine Stunde damit verlieren, eine Änderung zu debuggen, die ihn nie erreicht hat.

In einem abgesicherten Virtual WAN Hub ist das Äquivalent eine Standardroute in der Hub-Routentabelle, die dem Point-to-Site-Gateway zugeordnet ist, wobei Azure Firewall im Hub den Verkehr übernimmt. Die Firewall übersetzt internetgebundene Verbindungen auf ihre eigenen öffentlichen IP-Adressen, und aus dieser Übersetzung stammt die neue Ausgangsadresse. Wenn eine Firewall mehrere öffentliche IPs hat, kann jede davon als Quelle auftauchen, also muss eine Allowlist alle enthalten.

Beide Designs oben sind IPv4. Die beiden /1-Präfixe bewirken für IPv6 nichts, und die Point-to-Site-Unterstützung für IPv6 ist so schmal, dass Sie die Kombination testen sollten, bevor Sie Parität versprechen.

Prüfen Sie die Route, dann den Ausgang

Bestätigen Sie nach der Neuinstallation des Pakets und dem erneuten Verbinden, dass der Client die Hälften tatsächlich installiert hat. Unter Windows sollten Get-NetRoute -DestinationPrefix 0.0.0.0/1 und dieselbe Abfrage für 128.0.0.0/1 die Tunnelschnittstelle nennen, und route print zeigt beide neben Ihrer ursprünglichen Standardroute. Unter Linux muss ip route show die beiden Präfixe auflisten; tut es das nicht, hat das Profil sie nie transportiert.

Prüfen Sie dann die öffentliche Adresse vom Client aus erneut und lesen Sie das Firewall-Log für dieselbe Verbindung. Die Quelle sollte die öffentliche IP der Firewall mit einem übersetzten Port sein. Ein Client, der weiterhin lokal hinausgeht, obwohl beide Routen existieren, bedeutet, dass Pakete Azure erreicht haben und über einen anderen Weg verlassen haben: eine benutzerdefinierte Route im Gateway-Subnetz, eine Firewall, die selbst zum lokalen Netz erzwungen getunnelt wird, oder eine Richtlinie, die den Datenfluss vor der Übersetzung verwirft.

Testen Sie ein privates Ziel in derselben Sitzung erneut. Ein Jump-Host, der nach der Änderung nicht mehr antwortet, ist das übliche Zeichen dafür, dass die neuen Präfixe etwas verdrängt haben, entweder eine engere lokale Route, die zuvor angekündigt wurde, oder die Namensauflösung, die nun zu einem Resolver ohne Forwarder für Ihre privaten Zonen geht.

Wann man den Split-Tunnel in Ruhe lässt

Wenn es nur darum geht, eine private API, einen privaten Endpunkt oder eine interne Admin-Seite zu erreichen, ist das Standardverhalten billiger und ruhiger. Erzwungenes Tunneling fügt Firewall-Stunden und Datenverarbeitungskosten hinzu, einen längeren Pfad und eine weitere Stelle, an der jeder Client-Flow scheitern kann. Es erfasst außerdem weit mehr Verkehr als das eine Ziel, um das Sie sich gekümmert haben.

Greifen Sie danach, wenn die Anforderung in Bezug auf den Ausgang formuliert ist: Ein Partner muss eine feste Azure-Adresse sehen, die Sicherheit will die Verbindungen protokolliert und geprüft haben, oder Daten müssen über einen kontrollierten Punkt hinausgehen. Selbst dann gibt das Design jedem Benutzer einen gemeinsamen Ausgang, sodass die Verantwortlichkeit pro Benutzer aus der Identität in der Anwendung kommen muss und nicht aus der Quelladresse.

Bevor Sie die Änderung abschließen, bestätigen Sie vier Dinge: Das installierte Clientpaket ist das neue, die beiden /1-Routen liegen auf der Tunnelschnittstelle, ein privates Ziel antwortet noch, und das Log des entfernten Dienstes zeigt die Firewall-Adresse.