Azure P2S: jedan Windows klijent izgubio rute nakon promjene VNet-a

Dva prijenosna računara autentificiraju se na isti Azure point-to-site pristupnik, a samo jedan može doći do novo povezane VNet mreže. Oba prikazuju Connected, pa autentifikacija nije razlika; razlika su rute do odredišta koje drže. Počnite od klijenta koji ne uspijeva, uporedite jedno odredište i tek onda odlučite pripada li praznina paketu pristupnika ili lokalnoj tablici ruta.

Počnite od klijenta koji ne uspijeva, ne od pristupnika

Potvrdite topologiju prije nego okrivite prijenosni računar. Provjerite koje su VNet mreže povezane s VNet mrežom pristupnika i je li nova mreža direktno peerovana ili se do nje dolazi zasebnim site-to-site tunelom. Ako nova VNet mreža uopće nije povezana s VNet mrežom pristupnika, nijedan klijentski paket ne može usmjeravati do nje, a radni prijenosni računar je anomalija koju treba objasniti. Zapišite odgovor, jer on odlučuje debagujete li klijenta ili pristupnik.

Kad topologija bude ispravna, stavite dva prijenosna računara jedan pored drugog. Isti pristupnik, isti bazen adresa, isti protokol i ista verzija klijenta jesu poređenje koje želite; sve drugo je druga varijabla koju ćete kasnije morati ukloniti.

Uporedite jedno odredište pomoću route print

Odaberite dopuštenu IP adresu resursa i uporedite oba prijenosna računara dvaput: isključena, pa povezana. Na Windowsu route print -4 ispisuje IPv4 rute s prefiksom odredišta, sučeljem, sljedećim skokom i metrikom. Zabilježite red koji bi zaista pobijedio za to odredište, umjesto da brojite unose koji sadrže riječ VPN.

Odabir ide po najdužem prefiksu, zatim po metrici, pa konkretnija lokalna ruta može pobijediti tunelsku rutu, a da ne izgleda pogrešno. Ako je željeno odredište unutar 10.24.0.0/16, zdrav klijent prikazuje odgovarajuću rutu na VPN sučelju, dok klijent koji ne uspijeva šalje istu adresu svom zadanom pristupniku.

Sukobljeni lokalni prefiks može proizvesti isti simptom. Prije nego bilo šta dodate, odlučite koji od dva slučaja imate: nikakvu tunelsku rutu, ili tunelsku rutu koja gubi od konkretnije.

TTL expired nije greška u distribuciji ruta

Ping koji vraća TTL expired in transit kaže da je paket potrošio svoju dozvolu skokova, što obično znači petlju prosljeđivanja, a ne pokvaren VPN drajver. Windows ping prihvata TTL do 255, a podizanje vrijednosti ne popravlja petlju; samo odgađa istu grešku. Tretirajte poruku kao simptom putanje, ne kao dokaz o distribuciji ruta.

Upotrijebite tracert -4 10.24.1.10 da vidite gdje se putanja ponavlja. Ako se ista dva skoka pojavljuju iznova, potražite rutu koja promet namijenjen tunelu šalje natrag u tunel ili u lokalni usmjerivač koji ga vraća.

Ponovo generirajte paket na pristupniku koji ga posjeduje

Microsoft dokumentira da se Windows klijentski paketi moraju ponovo preuzeti i instalirati nakon relevantnih promjena topologije. Uzmite trenutni paket s Azure pristupnika koji opslužuje ovaj profil, pa ga primijenite podržanim postupkom za taj klijent. Zamjena izvršne datoteke nepovezane VPN aplikacije nije ista operacija kao ponovno generiranje postavki specifičnih za pristupnik. Ponovno preuzimanje paketa je jeftino; nagađanje o lokalnim rutama nije.

Ponovo se povežite i ponovo pročitajte rutu za izvorno odredište. Sačuvajte redove prije i poslije uz zapis o promjeni kako bi rezultat bio precizniji od ponovo sam instalirao klijenta.

Scenariji Azure P2S usmjeravanja razdvajaju direktno peerovane VNet mreže od mreža do kojih se dolazi drugim tunelima, a novi paket ne može učiniti peerovanje tranzitivnim. Neki Windows site-to-site ili BGP scenariji također traže ručno konfigurirane udaljene rute, pa osvježavanje paketa nije univerzalni mehanizam distribucije ruta.

Neka privremena ruta ostane privremena

Ručna ruta može izolirati nedostajuću klijentsku rutu, ali je izgradite iz stvarnog dizajna: route add 10.24.0.0 mask 255.255.0.0 172.16.0.1 if 42, bez trajnog flaga, tako da nestane pri ponovnom pokretanju. Odaberite indeks sučelja i sljedeći skok sa povezanog VPN adaptera, a ne iz nagađanja.

Ne ostavljajte eksperimentalnu rutu kao trajnog konkurentnog vlasnika. Buduća ažuriranja profila mogu dodati isti prefiks s drugom metrikom i tada ručni unos tiho odlučuje koja putanja pobjeđuje. Zabilježite korak uklanjanja u promjeni.

Kad ispravna ruta bude aktivna, testirajte ciljnu aplikaciju, a ne ping. Ako paketi stignu do Azurea, ali usluga i dalje ne uspijeva, provjerite mrežnu sigurnosnu grupu i povratnu putanju, jer su one odvojene od toga je li prijenosni računar naučio prefiks.