Azure P2S: un client Windows es queda sense rutes després d'un canvi de VNet

Dos portàtils s'autentiquen a la mateixa passarel·la Azure point-to-site, i només un arriba a la VNet connectada recentment. Tots dos mostren Connected, així que l'autenticació no és la diferència; ho són les rutes de destinació que mantenen. Comença pel client que falla, compara una sola destinació i només després decideix si la bretxa és del paquet de la passarel·la o de la taula de rutes local.

Comença pel client que falla, no per la passarel·la

Confirma la topologia abans de culpar el portàtil. Comprova quines VNet estan connectades a la VNet de la passarel·la i si la xarxa nova està emparellada directament o s'hi arriba per un túnel site-to-site separat. Si la VNet nova no està connectada a la VNet de la passarel·la, cap paquet de client no hi pot encaminar, i el portàtil que funciona és l'anomalia a explicar. Anota la resposta, perquè decideix si depures un client o una passarel·la.

Un cop la topologia és correcta, posa els dos portàtils costat a costat. La mateixa passarel·la, el mateix pool d'adreces, el mateix protocol i la mateixa versió del client són la comparació que vols; qualsevol altra cosa és una segona variable que hauràs d'eliminar després.

Compara una destinació amb route print

Tria una IP de recurs permesa i compara tots dos portàtils dues vegades: desconnectats i després connectats. A Windows, route print -4 llista les rutes IPv4 amb el prefix de destinació, la interfície, el següent salt i la mètrica. Anota la fila que realment guanyaria per a aquesta destinació en lloc de comptar entrades que continguin la paraula VPN.

La selecció és primer el prefix més llarg i després la mètrica, així que una ruta local més específica pot guanyar la ruta del túnel sense semblar incorrecta. Si la destinació prevista és dins de 10.24.0.0/16, un client sa mostra una ruta coincident a la interfície VPN, mentre que el client que falla envia la mateixa adreça a la seva passarel·la per defecte.

Un prefix local en conflicte pot produir el mateix símptoma. Abans d'afegir res, decideix quin dels dos casos tens: cap ruta de túnel, o una ruta de túnel que perd contra una de més específica.

TTL expired no és un error de distribució de rutes

Un ping que retorna TTL expired in transit diu que el paquet ha esgotat el seu marge de salts, cosa que normalment significa un bucle de reenviament i no un controlador VPN trencat. El ping de Windows accepta un TTL de fins a 255, i apujar el valor no repara un bucle; només ajorna el mateix error. Tracta el missatge com un símptoma del camí, no com una prova sobre la distribució de rutes.

Fes servir tracert -4 10.24.1.10 per veure on es repeteix el camí. Si els mateixos dos salts apareixen una vegada i una altra, busca una ruta que torni el trànsit destinat al túnel cap al túnel o cap a un encaminador local que el reenviï de tornada.

Regenera el paquet a la passarel·la que el posseeix

Microsoft documenta que els paquets de client de Windows s'han de tornar a baixar i instal·lar després de canvis de topologia rellevants. Agafa el paquet actual de la passarel·la d'Azure que serveix aquest perfil i aplica'l amb el procés admès per a aquest client. Substituir l'executable d'una aplicació VPN no relacionada no és la mateixa operació que regenerar paràmetres específics de la passarel·la. Tornar a baixar el paquet és barat; endevinar rutes locals no ho és.

Torna a connectar-te i torna a llegir la ruta de la destinació original. Guarda les files d'abans i de després amb el registre del canvi perquè el resultat sigui més precís que vaig reinstal·lar el client.

Els escenaris d'encaminament d'Azure P2S separen les VNet emparellades directament de les xarxes a què s'arriba per altres túnels, i un paquet nou no pot fer l'emparellament transitiu. Alguns escenaris Windows site-to-site o BGP també necessiten rutes remotes configurades manualment, així que refrescar el paquet no és un mecanisme universal de distribució de rutes.

Mantén una ruta temporal com a temporal

Una ruta manual pot aïllar una ruta de client que falta, però construeix-la a partir del disseny real: route add 10.24.0.0 mask 255.255.0.0 172.16.0.1 if 42, sense el flag persistent, perquè desaparegui en reiniciar. Tria l'índex d'interfície i el següent salt de l'adaptador VPN connectat, no d'una suposició.

No deixis una ruta experimental com a propietari competidor permanent. Actualitzacions futures del perfil poden afegir el mateix prefix amb una mètrica diferent, i llavors l'entrada manual decideix en silenci quin camí guanya. Anota el pas de retirada al canvi.

Un cop la ruta correcta estigui activa, prova l'aplicació de destinació en lloc d'un ping. Si els paquets arriben a Azure però el servei encara falla, revisa el grup de seguretat de xarxa i el camí de tornada, perquè són independents de si el portàtil ha après el prefix.