Azure Private IP VPN über ExpressRoute ohne NVA

Der Mythos besagt, dass die Verschlüsselung von Datenverkehr über ExpressRoute Private Peering eine virtuelle Netzwerkappliance erfordert. Das tut sie nicht. Azure unterstützt ein Site-to-Site VPN Gateway, dessen Tunnelendpunkt eine private RFC1918-Adresse ist, die über die Verbindung transportiert wird, und die Appliance ist optional statt strukturell. Was der Appliance-Mythos verbirgt, ist der Teil, der wirklich weh tut: das private Endpunkt-Flag an einem Objekt statt an beiden zu setzen und zuzulassen, dass eine direkte Peering-Route stillschweigend über den verschlüsselten Pfad gewinnt.

Woher der Mythos stammt

Die Behauptung hat eine ehrwürdige Herkunft. Jahrelang war das praktische Rezept für IPsec über Private Peering eine NVA, weil das verwaltete Gateway nur öffentliche Endpunkte bereitstellte. Das änderte sich, und Antworten, die vor der Änderung geschrieben wurden, werden weiterhin in Threads zitiert, in denen niemand das Datum prüft. Die Korrektur ist eng: Ein VPN-Gateway mit privater Adresse existiert, und es ändert den Endpunkt, nicht die Routinglogik darum herum.

Nichts davon verabschiedet die NVA in den Ruhestand. Es verabschiedet die Annahme, dass eine Appliance der einzige Weg zur Anforderung ist.

Aktivieren Sie den privaten Endpunkt auf beiden Ebenen

Beginnen Sie mit einer funktionierenden ExpressRoute Private-Peering-Verbindung, die mit dem VNet verknüpft ist, das das VPN-Gateway enthält. Die lokale Seite muss die relevanten privaten Adressen bereits über diese Verbindung erreichen, denn der Tunnel wird diese Adressen als Transport nutzen. Dann die Gateway-Voraussetzung: Das Microsoft-Verfahren für Private-IP-VPN verlangt ein Gateway auf einer öffentlichen Standard-IP-Ressource. Die private Tunneladressierung hebt diese Anforderung nicht auf, was Leute überrascht, die annehmen, „privat“ bedeute „nirgends eine öffentliche IP“.

Aktivieren Sie das Flag nun an beiden Stellen. Die Gateway-Konfiguration hat ihren eigenen Schalter für private IPs, und die einzelne Site-to-Site-Verbindung hat einen zweiten, der diese Verbindung die private Adresse verwenden lässt. Eines zu setzen und das andere nicht ist die häufigste unvollständige Konfiguration; der Tunnel kommt entweder nicht zustande oder zustande zum falschen Endpunkt.

az network vnet-gateway update -g rg-net -n vpngw-prod --set enablePrivateIpAddress=true
az network vpn-connection update -g rg-net -n conn-onprem --set enablePrivateIpAddress=true
az network vnet-gateway show -g rg-net -n vpngw-prod \
  --query '{sku:sku,priv:enablePrivateIpAddress,active:activeActive}'

Prüfen Sie die Eigenschaftsnamen gegen die installierte CLI-Version, denn Portalbezeichnungen und CLI-Eigenschaften stimmen nicht immer wörtlich überein. Ein aktiv-aktives Gateway stellt zwei private Tunneladressen bereit, und das lokale Gerät braucht beide Peers konfiguriert, wenn diese Redundanz etwas bedeuten soll. BGP ist nicht erforderlich, nur um diesen privat adressierten Tunnel hochzubringen, obwohl es normalerweise Teil der Präfixverteilung ist.

Der zweite Mythos: Ein etablierter Tunnel verschlüsselt Ihren Verkehr

Zwei Pfade erreichen nun das Anwendungsnetz: der direkte Private-Peering-Pfad und der Pfad durch das VPN. Beide funktionieren. Nur einer wendet diese IPsec-Schicht an. Microsoft dokumentiert, dass Azure bei identischen Präfixen, die über ExpressRoute und über das VPN angekündigt werden, den direkten ExpressRoute-Pfad bevorzugt; ein gesunder Tunnel mit gesunden Zählern beweist also nichts darüber, wohin die Anwendungspakete gegangen sind.

Die dokumentierten Lenkungsmethoden sind ein überdeckender Bereich auf ExpressRoute mit einem spezifischeren geschützten Bereich auf dem VPN oder disjunkte Präfixe auf beiden Pfaden. Zur Veranschaulichung könnte Private Peering 10.40.0.0/16 führen, während das VPN 10.40.12.0/24 ankündigt. Das spezifischere Präfix gewinnt, und der Rest des Bereichs bleibt direkt.

az network vnet-gateway list-advertised-routes -g rg-net -n vpngw-prod
az network vnet-gateway list-learned-routes -g rg-net -n vpngw-prod
az network vpn-connection show -g rg-net -n conn-onprem --query connectionStatus

Führen Sie dieselbe Prüfung in der lokalen Richtung durch, denn die Präferenz Ihres Routers entscheidet, welchen Weg ausgehender Verkehr nimmt. Und halten Sie den eigenen Transport des Tunnels auf dem ExpressRoute-Pfad; eine Route, die den privaten Endpunkt des Gateways in den Tunnel zieht, macht den Tunnel von sich selbst abhängig.

Entscheiden Sie, was passiert, wenn der Tunnel ausfällt

Eine spezifischere VPN-Route verschwindet, wenn der Tunnel ausfällt, während die breitere direkte Route bleibt. Der Verkehr fließt dann unverschlüsselt, und alles sieht gesund aus – das ist der schlechteste Fehlermodus für eine Anforderung, die die Verschlüsselung garantieren soll. Wenn die Anforderung diesen Rückfall verbietet, müssen Routing und Zugriffsrichtlinie das ausdrücklich sagen, statt sich auf die Verfügbarkeit des Tunnels zu verlassen.

Notieren Sie, welche Präfixe direkt erreichbar bleiben dürfen und welche stoppen müssen, wenn der verschlüsselte Pfad fehlt. Testen Sie dann den erlaubten Fall mit echtem Verkehr und vergleichen Sie die Verbindungszähler, denn die Routentabelle allein sagt Ihnen nicht, ob die Verschlüsselungsanforderung noch gilt.

Dieser Rahmen erlaubt es Ihnen auch, eine NVA nach ihren tatsächlichen Funktionen zu bewerten, etwa mehrere Tunnel, Durchsatz oder Herstellerinspektion, statt eine zu kaufen, weil der Endpunkt privat ist.