Azure P2S: un client Windows rămâne fără rute după o modificare de VNet

Două laptopuri se autentifică la același gateway Azure point-to-site, iar doar unul ajunge la VNet-ul conectat recent. Ambele arată Connected, deci autentificarea nu este diferența; rutele de destinație pe care le păstrează sunt. Începeți cu clientul care eșuează, comparați o singură destinație și abia apoi decideți dacă golul aparține pachetului gateway-ului sau tabelului de rute local.

Începeți cu clientul care eșuează, nu cu gateway-ul

Confirmați topologia înainte de a da vina pe laptop. Verificați ce VNet-uri sunt conectate la VNet-ul gateway-ului și dacă rețeaua nouă este peerată direct sau este atinsă printr-un tunel site-to-site separat. Dacă noul VNet nu este deloc conectat la VNet-ul gateway-ului, niciun pachet de client nu poate ruta spre el, iar laptopul care funcționează este anomalia care trebuie explicată. Notați răspunsul, pentru că el decide dacă depanați un client sau un gateway.

După ce topologia este corectă, puneți cele două laptopuri alături. Același gateway, același pool de adrese, același protocol și aceeași versiune de client sunt comparația dorită; orice altceva este o a doua variabilă pe care va trebui să o eliminați mai târziu.

Comparați o destinație cu route print

Alegeți un IP de resursă permis și comparați ambele laptopuri de două ori: deconectate și apoi conectate. În Windows, route print -4 listează rutele IPv4 cu prefixul destinației, interfața, următorul salt și metrica. Înregistrați rândul care ar câștiga efectiv pentru acea destinație, în loc să numărați intrările care conțin cuvântul VPN.

Selecția se face mai întâi după cel mai lung prefix, apoi după metrică, așa că o rută locală mai specifică poate învinge ruta tunelului fără a părea greșită. Dacă destinația vizată este în 10.24.0.0/16, un client sănătos arată o rută corespunzătoare pe interfața VPN, în timp ce clientul care eșuează trimite aceeași adresă către gateway-ul său implicit.

Un prefix local conflictual poate produce același simptom. Înainte de a adăuga ceva, decideți care dintre cele două cazuri este al dumneavoastră: nicio rută de tunel, sau o rută de tunel care pierde în fața uneia mai specifice.

TTL expired nu este un bug de distribuire a rutelor

Un ping care returnează TTL expired in transit spune că pachetul și-a epuizat cota de salturi, ceea ce înseamnă de obicei o buclă de forwarding, nu un driver VPN defect. Ping-ul Windows acceptă TTL până la 255, iar creșterea valorii nu repară o buclă; doar amână aceeași eroare. Tratați mesajul ca simptom al traseului, nu ca dovadă despre distribuirea rutelor.

Folosiți tracert -4 10.24.1.10 pentru a vedea unde se repetă traseul. Dacă aceleași două salturi apar iar și iar, căutați o rută care trimite traficul destinat tunelului înapoi în tunel sau către un router local care îl retrimite.

Regenerați pachetul pe gateway-ul care îl deține

Microsoft documentează că pachetele de client Windows trebuie descărcate și instalate din nou după modificări relevante de topologie. Obțineți pachetul curent de la gateway-ul Azure care deservește acest profil și apoi aplicați-l cu procedura acceptată pentru acel client. Înlocuirea executabilului unei aplicații VPN nelegate nu este aceeași operațiune cu regenerarea setărilor specifice gateway-ului. Descărcarea din nou a pachetului este ieftină; ghicirea rutelor locale nu este.

Reconectați-vă și recitiți ruta pentru destinația originală. Păstrați rândurile de dinainte și de după împreună cu înregistrarea modificării, ca rezultatul să fie mai precis decât am reinstalat clientul.

Scenariile de rutare Azure P2S separă VNet-urile peerate direct de rețelele atinse prin alte tuneluri, iar un pachet nou nu poate face peering-ul tranzitiv. Unele scenarii Windows site-to-site sau BGP necesită și rute la distanță configurate manual, așa că reîmprospătarea pachetului nu este un mecanism universal de distribuire a rutelor.

Păstrați o rută temporară temporară

O rută manuală poate izola o rută de client lipsă, dar construiți-o din proiectul real: route add 10.24.0.0 mask 255.255.0.0 172.16.0.1 if 42, fără indicatorul persistent, ca să dispară la repornire. Alegeți indexul interfeței și următorul salt din adaptorul VPN conectat, nu dintr-o presupunere.

Nu lăsați o rută experimentală ca proprietar concurent permanent. Actualizările viitoare de profil pot adăuga același prefix cu altă metrică, iar atunci intrarea manuală decide în tăcere ce cale câștigă. Notați pasul de eliminare în modificare.

După ce ruta corectă este activă, testați aplicația țintă în loc de un ping. Dacă pachetele ajung la Azure dar serviciul încă eșuează, verificați grupul de securitate de rețea și calea de întoarcere, pentru că acestea sunt separate de faptul că laptopul a învățat prefixul.