Zwei öffentliche IP-Adressen auf einer Azure-VPN-VM: Welche was tut

Zwei öffentliche IP-Adressen auf einer Azure-VPN-VM erzeugen eine Erwartung, die selten zutrifft: Die Adresse, mit der Clients sich verbinden, ist auch die Adresse, die Websites sehen. Drei unabhängige Entscheidungen erzeugen dieses Ergebnis, und nur die erste betrifft den Tunnel-Listener. Die zweite ist die Gastquelle für weitergeleiteten Clientverkehr, und die dritte ist die Azure-Ausgangsmethode, die für diese Quelle gilt. Ändern Sie eine, bleiben die anderen beiden, wo sie waren, entscheiden Sie also jede ausdrücklich.

Entscheidung 1: wo der Tunnel endet

Eine öffentliche Azure-IP ist einer privaten IP-Konfiguration auf der NIC zugeordnet; sie ist keine Adresse, die Sie im Gastbetriebssystem hinzufügen. Lesen Sie die Zuordnung, statt sie anzunehmen: az network nic show --ids /subscriptions/.../networkInterfaces/vpn-nic --query 'ipConfigurations[].{private:privateIPAddress,public:publicIPAddress.id}'. Welche private Adresse diese Abfrage auch zurückgibt, genau diese muss der Gast tatsächlich haben.

Eine NIC kann mehrere IP-Konfigurationen tragen, zwei öffentliche Adressen erfordern also nicht zwei NICs. Wenn das Design doch zwei NICs nutzt, bringt jede ihre eigenen Gastrouten und nächsten Hops mit, und Sie haben eine Routingentscheidung hinzugefügt, statt eine zu vereinfachen.

Binden Sie einen Dienst mit ausdrücklicher lokaler Bindung an die echte private Gastadresse, niemals an den öffentlichen Platzhalter. Ein Listener, der alle Adressen annimmt, empfängt Verkehr über jede IP-Konfiguration, die ihn erreicht, begrenzen Sie den Eintritt also mit der Netzwerksicherheitsgruppe und der Host-Firewall, statt zu hoffen, dass die Bindungsreihenfolge entscheidet.

Entscheidung 2: welche Quelle der weitergeleitete Client nutzt

Nachdem das Gateway eine Clientanfrage entschlüsselt hat, ist das weitergeleitete Paket ein anderes als das am VPN-Listener angekommene. Der Gast braucht aktivierte Weiterleitung, eine Firewallrichtlinie, die den Fluss erlaubt, und eine Quelladresse, die das Cloud-Design zulässt. Wenn Sie die innere Clientadresse übersetzen, bewertet Azure genau diese übersetzte Quelle, nicht die innere Adresse des Clients.

Eine enge SNAT-Regel kann eine private Gastquelle wählen, aber eine nachgelagerte Azure-Übersetzung nicht überstimmen. Wählen Sie SNAT, wenn Sie Verantwortlichkeit pro Client innerhalb der VM brauchen; lassen Sie es weg, wenn das Ausgangsdesign des Subnetzes bereits eine stabile öffentliche Quelle bietet und eine zweite Übersetzung nur Zustand hinzufügen würde.

Entscheidung 3: welche Azure-Ausgangsmethode gewinnt

Microsoft dokumentiertdie Vorrangreihenfolge für ausgehenden Verkehr: Eine anwendbare Route zu einer Appliance oder einem Gateway hat Vorrang, und die NAT-Gateway-Konnektivität des Subnetzes hat Vorrang vor einer öffentlichen IP auf Instanzebene auf dem betreffenden Pfad. Diese Reihenfolge ist der Grund, warum eine Übersetzung nach 10.20.0.5 nicht beweist, dass eine Website 198.51.100.20 sieht. Lesen Sie die effektive Routentabelle, die NAT-Gateway-Zuordnung und die öffentliche IP der NIC zusammen, bevor Sie das Ausgangsdesign akzeptieren.

Halten Siedie Weiterleitungseinstellung der Azure-NICgetrennt von der Weiterleitung in Linux. Das Cloud-Flag erlaubt Pakete, deren Quelle oder Ziel der NIC nicht zugewiesen ist; es aktiviert nicht net.ipv4.ip_forward, und die Gasteinstellung erteilt keine Cloud-Berechtigung.

Der Tunnel-Socket hat seine eigene Quellentscheidung

WireGuards Address unter wg-quick weist der WireGuard-Schnittstelle eine Adresse zu; es ist keine Anweisung für eine äußere UDP-Bindung. Die Quelle des verschlüsselten Sockets folgt der Routentabelle, eine Policy-Route oder eine zweite Standardroute kann sie also verschieben, ohne die Schnittstellenadresse zu berühren.OpenVPN: Die Option local und UDP multihome verhalten sich gleich: Sie betreffen den Listener und seine Antworten, nicht die Internetquelle jedes weitergeleiteten Clients.

Bewahren Sie die Underlay-Route, die den Tunnel trägt, und bestätigen Sie, dass der Client weiterhin authentifizierte Antworten aus der erwarteten Eintrittsanordnung erhält. Verlassen Sie sich nicht auf die Reihenfolge der Adressliste als dauerhafte Quellenauswahlrichtlinie, denn die nächste der NIC hinzugefügte Adresse kann ändern, welche gewinnt.

Was zu akzeptieren ist, und in welcher Reihenfolge

Akzeptieren Sie drei Ergebnisse getrennt. Erstens erreicht ein externer Client den vorgesehenen VPN-Eintritt. Zweitens verlässt eine neue erlaubte Anfrage dieses VPN-Clients den dokumentierten Internetausgang. Drittens bleiben unbeabsichtigte Listener- und Weiterleitungspfade verweigert. Halten Sie die Zuordnungen von öffentlich zu privat und die Gast- und Cloud-Verantwortlichen jeder Entscheidung an derselben Stelle fest.

Ein erfolgreicher Tunnel beweist nur den ersten Teil. Testen Sie den Ausgang mit einem neuen Fluss, denn eine zwischengespeicherte Verbindung kann die alte Quelle noch lange nach der Routenänderung weiterverwenden.