Azure P2S: engem Windows-Client fehlen no enger VNet-Ännerung d'Routen

Zwee Laptopen authentifizéieren sech um selwechten Azure point-to-site Gateway, an nëmmen een erreecht d'nei verbonnen VNet. Béid weisen Connected, also d'Authentifikatioun ass net den Ënnerscheed; d'Destinatiounsrouten, déi si halen, sinn et. Fänkt beim Client un, dee feelt, vergläicht eng eenzeg Destinatioun, an entscheet erscht duerno, ob de Gateway-Paket oder d'lokal Routentabell d'Lück huet.

Fänkt beim Client un, dee feelt, net beim Gateway

Confirméiert d'Topologie, ier Dir de Laptop beschëllegt. Kuckt, wéi eng VNeten mam Gateway-VNet verbonne sinn a wéi d'neit Netzwierk direkt gepeert oder iwwer en separat site-to-site-Tunnel erreecht gëtt. Wann d'neit VNet guer net mam Gateway-VNet verbonne ass, kann kee Client-Paket dohinner routen, an de Laptop, dee funktionnéiert, ass d'Anomalie, déi een erkläre muss. Schreift d'Äntwert op, well se entscheet, ob Dir e Client oder e Gateway debuggt.

Wann d'Topologie stëmmt, setzt déi zwee Laptopen niewenteneen. Deelweis Gateway, déiselwecht Adresspool, dee selwechte Protokoll an déi selwecht Client-Versioun sinn de Verglach, deen Dir wëllt; alles anescht ass eng zweet Variabel, déi Dir spéider musst eliminéieren.

Vergläicht eng Destinatioun mat route print

Wielt eng erlaabten Ressource-IP a vergläicht béid Laptopen zweemol: ofgekoppelt an duerno verbonnen. Ënner Windows listet route print -4 IPv4-Routen mat Destinatiounspräfix, Interface, nächstem Hop a Metrik. Notéiert déi Linn, déi fir déi Destinatioun wierklech géif gewannen, amplaz Entréen ze zielen, déi d'Wuert VPN enthalen.

D'Auswiel ass fir d'éischt de längste Präfix an duerno d'Metrik, also kann eng méi spezifesch lokal Route d'Tunnelroute schloen, ouni falsch auszegesinn. Wann d'Destinatioun bannent 10.24.0.0/16 läit, weist e gesonde Client eng passend Route um VPN-Interface, wärend de Client, dee feelt, déiselwecht Adress un säin Standardgateway schéckt.

E konfliktende lokale Präfix kann déiselwecht Symptomer ginn. Ier Dir eppes bäifüügt, entscheet, wéi ee vun den zwee Fäll Dir hutt: guer keng Tunnelroute, oder eng Tunnelroute, déi géint eng méi spezifesch verléiert.

TTL expired ass kee Routeverdeelungsfehler

E Ping, deen TTL expired in transit zréckgëtt, seet, datt de Paket säi Hopkontingent opgebraucht huet, wat meeschtens eng Weiderleitungsschleef bedeit an net en defekten VPN-Treiber. Windows-Ping akzeptéiert eng TTL bis 255, an den Héichstelle vum Wäert reparéiert keng Schleef; en hält just dee selwechte Fehler op. Behandelt d'Message als Symptom vum Wee, net als Beweis iwwer d'Routeverdeelung.

Benotzt tracert -4 10.24.1.10 fir ze gesinn, wou de Wee sech widderhëlt. Wann déiselwecht zwee Hops ëmmer erëm optrieden, sicht eng Route, déi Tunnelverkéier zréck an den Tunnel schéckt oder an e lokale Router, deen en zréckschéckt.

Regeneréiert de Paket um Gateway, deem en gehéiert

Microsoft dokumentéiert, datt Windows-Client-Paketen no relevante Topologieännerunge mussen erofgelueden an nei installéiert ginn. Huelt dee aktuellen Paket vum Azure-Gateway, dee dëse Profil servéiert, a wendt en duerno mam ënnerstëtzte Prozess fir dee Client un. Eng ausféierbar Datei vun enger onenspriechend VPN-Applikatioun ersetzen ass net déiselwecht Operatioun wéi gateway-spezifesch Astellungen nei ze generéieren. De Paket nach eng Kéier eroflueden ass bëlleg; lokal Routen ze roden net.

Verbindnech nach eng Kéier a liest d'Route fir d'originär Destinatioun nach eng Kéier. Halt d'Linnen virun an no zesumme mam Ännerungsrekord, sou datt d'Resultat méi genee ass wéi den Client nei installéiert.

D'Azure P2S-Routing-Szenarien trennen direkt gepeert VNeten vun Netzwierker, déi iwwer aner Tunnelen erreecht ginn, an e neie Paket kann d'Peering net transitiv maachen. E puer Windows site-to-site oder BGP-Szenarien brauchen och manuell konfiguréiert Fernrouten, dofir ass eng Paketaktualiséierung keen universelle Mechanismus fir Routeverdeelung.

Hält eng temporär Route temporär

Eng manuell Route kann eng fehlend Client-Route isoléieren, awer baut se aus dem richtege Design: route add 10.24.0.0 mask 255.255.0.0 172.16.0.1 if 42, ouni de persistenten Fändel, sou datt se beim Neistart verschwënnt. Wielt den Interface-Index an den nächsten Hop vum verbonnenen VPN-Adapter, net vun enger Vermutung.

Loosst eng experimentell Route net als permanente konkurréierende Besetzer stoen. Zukünfteg Profilupdates kënnen dee selwechte Präfix mat enger anerer Metrik bäifügen, an dann entscheet den manuellen Entrée roueg, wéi ee Wee gewënnt. Notéiert de Schrëtt fir d'Entfernen an der Ännerung.

Wann déi richteg Route aktiv ass, test d'Zilapplikatioun amplaz e Ping. Wa Paketen Azure erreechen, awer den Service nach ëmmer feelt, kuckt d'Netzwierksécherheetsgrupp an de Réckwee, well déi onofhängeg dovu sinn, ob de Laptop de Präfix geléiert huet.