Azure P2S: një klient Windows humb rrugët pas një ndryshimi të VNet

Dy laptopë autentikohen në të njëjtën portë Azure point-to-site, dhe vetëm njëri arrin VNet-in e sapo lidhur. Të dy shfaqin Connected, pra autentikimi nuk është diferenca; rrugët e destinacionit që mbajnë janë diferenca. Filloni nga klienti që dështon, krahasoni një destinacion të vetëm, dhe vetëm pastaj vendosni nëse boshllëku i përket paketës së portës apo tabelës lokale të rrugëve.

Filloni nga klienti që dështon, jo nga porta

Konfirmoni topologjinë përpara se të fajësoni laptopin. Kontrolloni cilat VNet janë të lidhura me VNet-in e portës dhe nëse rrjeti i ri është peeruar drejtpërdrejt ose arrihet përmes një tuneli të veçantë site-to-site. Nëse VNet-i i ri nuk është fare i lidhur me VNet-in e portës, asnjë paketë klienti nuk mund të rrugëtojë drejt tij, dhe laptopi që funksionon është anomalia që duhet shpjeguar. Shkruani përgjigjen, sepse ajo vendos nëse po korrigjoni një klient apo një portë.

Kur topologjia është e saktë, vendosni dy laptopët krah për krah. E njëjta portë, i njëjti pishinë adresash, i njëjti protokoll dhe e njëjta version klienti janë krahasimi që dëshironi; çdo gjë tjetër është një variabël e dytë që do t'ju duhet ta eliminoni më vonë.

Krahasoni një destinacion me route print

Zgjidhni një IP burimi të lejuar dhe krahasoni të dy laptopët dy herë: të shkëputur dhe më pas të lidhur. Në Windows, route print -4 liston rrugët IPv4 me prefiksin e destinacionit, ndërfaqen, hop-in e radhës dhe metrikën. Regjistroni rreshtin që do të fitonte vërtet për atë destinacion në vend që të numëroni zërat që përmbajnë fjalën VPN.

Zgjedhja bëhet fillimisht sipas prefiksit më të gjatë, pastaj sipas metrikës, kështu që një rrugë lokale më specifike mund të mundë rrugën e tunelit pa u dukur e gabuar. Nëse destinacioni i synuar është brenda 10.24.0.0/16, një klient i shëndetshëm tregon një rrugë përkatëse në ndërfaqen VPN, ndërsa klienti që dështon dërgon të njëjtën adresë në portën e tij të paracaktuar.

Një prefiks lokal në konflikt mund të prodhojë të njëjtin simptomë. Përpara se të shtoni diçka, vendosni cili nga dy rastet është i juaji: asnjë rrugë tuneli fare, ose një rrugë tuneli që humb ndaj një më specifike.

TTL expired nuk është defekt i shpërndarjes së rrugëve

Një ping që kthen TTL expired in transit thotë se paketa shpenzoi kuotën e hop-eve, që zakonisht do të thotë një lak përcjelljeje dhe jo një drejtues VPN i prishur. Ping-u i Windows pranon TTL deri në 255, dhe rritja e vlerës nuk e rregullon një lak; thjesht e shtyn të njëjtin gabim. Trajtojeni mesazhin si simptomë të shtegut, jo si provë për shpërndarjen e rrugëve.

Përdorni tracert -4 10.24.1.10 për të parë ku përsëritet shtegu. Nëse të njëjtat dy hop-e shfaqen vazhdimisht, kërkoni një rrugë që dërgon trafikun drejt tunelit përsëri në tunel ose në një ruter lokal që e kthen mbrapsht.

Rigjeneroni paketën në portën që e zotëron

Microsoft dokumenton se paketat e klientit Windows duhet të shkarkohen dhe instalohen përsëri pas ndryshimeve të rëndësishme të topologjisë. Merrni paketën aktuale nga porta Azure që shërben këtë profil, dhe më pas zbatojeni me procedurën e mbështetur për atë klient. Zëvendësimi i skedarit ekzekutiv të një aplikacioni VPN të palidhur nuk është i njëjti veprim me rigjenerimin e cilësimeve specifike të portës. Shkarkimi përsëri i paketës është i lirë; hamendja për rrugët lokale nuk është.

Rilidhuni dhe rilexoni rrugën për destinacionin origjinal. Ruani rreshtat para dhe pas bashkë me regjistrin e ndryshimit, që rezultati të jetë më i saktë sesa e riinstalova klientin.

Skenarët e rrugëtimit të Azure P2S ndajnë VNet-të e peeruara drejtpërdrejt nga rrjetet që arrihen përmes tuneleve të tjera, dhe një paketë e re nuk mund ta bëjë peerimin tranzitiv. Disa skenarë Windows site-to-site ose BGP kërkojnë gjithashtu rrugë të largëta të konfiguruara me dorë, prandaj rifreskimi i paketës nuk është mekanizëm universal i shpërndarjes së rrugëve.

Mbani një rrugë të përkohshme të përkohshme

Një rrugë manuale mund të izolojë një rrugë klienti që mungon, por ndërtojeni nga projektimi real: route add 10.24.0.0 mask 255.255.0.0 172.16.0.1 if 42, pa flamurin e vazhdueshëm, që të zhduket në rinisje. Zgjidhni indeksin e ndërfaqes dhe hop-in e radhës nga përshtatësi VPN i lidhur, jo nga hamendja.

Mos e lini një rrugë eksperimentale si pronar konkurrues i përhershëm. Përditësimet e ardhshme të profilit mund të shtojnë të njëjtin prefiks me metrikë tjetër, dhe atëherë zëri manual vendos në heshtje cila rrugë fiton. Regjistroni hapin e heqjes në ndryshim.

Pasi rruga e saktë të jetë aktive, provoni aplikacionin e synuar në vend të ping-ut. Nëse paketat arrijnë në Azure por shërbimi ende dështon, kontrolloni grupin e sigurisë së rrjetit dhe shtegun e kthimit, sepse ato janë të ndara nga fakti nëse laptopi e mësoi prefiksin.