Azure P2S: Einem Windows-Client fehlen nach einer VNet-Änderung Routen

Zwei Laptops authentifizieren sich am selben Azure-Point-to-Site-Gateway, und nur einer erreicht das neu verbundene VNet. Beide zeigen Connected, die Authentifizierung ist also nicht der Unterschied; die Zielrouten, die sie halten, sind es. Beginnen Sie beim fehlschlagenden Client, vergleichen Sie ein einziges Ziel, und entscheiden Sie erst dann, ob das Gateway-Paket oder die lokale Routingtabelle die Lücke besitzt.

Beginnen Sie beim fehlschlagenden Client, nicht beim Gateway

Bestätigen Sie die Topologie, bevor Sie den Laptop beschuldigen. Prüfen Sie, welche VNets mit dem Gateway-VNet verbunden sind und ob das neue Netz direkt gepeert oder über einen separaten Site-to-Site-Tunnel erreicht wird. Ist das neue VNet gar nicht mit dem Gateway-VNet verbunden, kann kein Client-Paket dorthin routen, und der funktionierende Laptop ist die Anomalie, die erklärt werden muss. Schreiben Sie die Antwort auf, denn sie entscheidet, ob Sie einen Client oder ein Gateway debuggen.

Wenn die Topologie stimmt, stellen Sie die beiden Laptops nebeneinander. Gleiches Gateway, gleicher Adresspool, gleiches Protokoll und gleicher Client-Build sind der Vergleich, den Sie wollen; alles andere ist eine zweite Variable, die Sie später ausschließen müssen.

Vergleichen Sie ein Ziel mit route print

Wählen Sie eine erlaubte Ressourcen-IP und vergleichen Sie beide Laptops zweimal: getrennt und dann verbunden. Unter Windows listet route print -4 IPv4-Routen mit Zielpräfix, Schnittstelle, nächstem Hop und Metrik. Notieren Sie die Zeile, die für dieses Ziel tatsächlich gewinnen würde, statt Einträge zu zählen, die das Wort VPN enthalten.

Die Auswahl erfolgt zuerst nach dem längsten Präfix, dann nach der Metrik, sodass eine spezifischere lokale Route die Tunnelroute schlagen kann, ohne falsch auszusehen. Liegt das beabsichtigte Ziel in 10.24.0.0/16, zeigt ein gesunder Client eine passende Route auf der VPN-Schnittstelle, während der fehlschlagende Client dieselbe Adresse an sein Standardgateway schickt.

Ein konkurrierendes lokales Präfix kann dasselbe Symptom erzeugen. Bevor Sie etwas hinzufügen, entscheiden Sie, welchen der beiden Fälle Sie haben: gar keine Tunnelroute oder eine Tunnelroute, die gegen eine spezifischere verliert.

TTL expired ist kein Fehler der Routenverteilung

Ein Ping, der TTL expired in transit zurückgibt, besagt, dass das Paket sein Hop-Kontingent verbraucht hat, was meist eine Weiterleitungsschleife bedeutet und keinen defekten VPN-Treiber. Windows-Ping akzeptiert eine TTL bis 255, und ein höherer Wert repariert keine Schleife; er verzögert nur denselben Fehler. Behandeln Sie die Meldung als Pfadsymptom, nicht als Beleg über die Routenverteilung.

Nutzen Sie tracert -4 10.24.1.10, um zu sehen, wo sich der Pfad wiederholt. Erscheinen dieselben zwei Hops immer wieder, suchen Sie eine Route, die tunnelgebundenen Verkehr zurück in den Tunnel oder in einen lokalen Router schickt, der ihn zurücksendet.

Erzeugen Sie das Paket auf dem Gateway neu, dem es gehört

Microsoft dokumentiert, dass Windows-Client-Pakete nach relevanten Topologieänderungen erneut heruntergeladen und installiert werden müssen. Holen Sie das aktuelle Paket vom Azure-Gateway, das dieses Profil bedient, und wenden Sie es dann mit dem unterstützten Verfahren für diesen Client an. Eine ausführbare Datei einer unabhängigen VPN-Anwendung zu ersetzen ist nicht dieselbe Operation wie gatewayspezifische Einstellungen neu zu erzeugen. Das Paket erneut herunterzuladen ist billig; lokale Routen zu raten nicht.

Verbinden Sie sich erneut und lesen Sie die Route für das ursprüngliche Ziel noch einmal. Bewahren Sie die Zeilen davor und danach mit dem Änderungsdatensatz auf, damit das Ergebnis präziser ist als habe den Client neu installiert.

Die Azure P2S-Routingszenarien trennen direkt gepeerte VNets von Netzen, die über andere Tunnel erreicht werden, und ein neues Paket kann Peering nicht transitiv machen. Manche Windows-Site-to-Site- oder BGP-Szenarien benötigen zudem manuell konfigurierte Remote-Routen, daher ist eine Paketaktualisierung kein universeller Mechanismus der Routenverteilung.

Halten Sie eine temporäre Route temporär

Eine manuelle Route kann eine fehlende Client-Route isolieren, aber bauen Sie sie aus dem tatsächlichen Design: route add 10.24.0.0 mask 255.255.0.0 172.16.0.1 if 42, ohne das persistente Flag, damit sie beim Neustart verschwindet. Wählen Sie Schnittstellenindex und nächsten Hop am verbundenen VPN-Adapter, nicht aus einer Vermutung.

Lassen Sie eine experimentelle Route nicht als dauerhaften konkurrierenden Besitzer stehen. Künftige Profilaktualisierungen können dasselbe Präfix mit anderer Metrik hinzufügen, und dann entscheidet der manuelle Eintrag still, welcher Pfad gewinnt. Notieren Sie den Entfernungsschritt in der Änderung.

Sobald die richtige Route aktiv ist, testen Sie die Zielanwendung statt eines Pings. Wenn Pakete Azure erreichen, der Dienst aber weiterhin fehlschlägt, prüfen Sie die Netzwerksicherheitsgruppe und den Rückweg, denn diese sind davon unabhängig, ob der Laptop das Präfix gelernt hat.