Azure P2S: enemu odjemalcu Windows po spremembi VNet manjkajo poti

Dva prenosnika se overita pri istem prehodu Azure point-to-site, in samo eden doseže na novo povezani VNet. Oba prikazujeta Connected, zato overjanje ni razlika; razlika so ciljne poti, ki jih hranita. Začnite pri odjemalcu, ki ne uspe, primerjajte en cilj in šele nato odločite, ali vrzel pripada paketu prehoda ali lokalni tabeli poti.

Začnite pri odjemalcu, ki ne uspe, ne pri prehodu

Potrdite topologijo, preden obtožite prenosnik. Preverite, kateri VNeti so povezani z VNetom prehoda in ali je novo omrežje peerano neposredno ali doseženo prek ločenega tunela site-to-site. Če novi VNet sploh ni povezan z VNetom prehoda, noben odjemalski paket ne more usmerjati tja, in delujoči prenosnik je anomalija, ki jo je treba pojasniti. Zapišite odgovor, ker odloča, ali odpravljate napake odjemalca ali prehoda.

Ko je topologija pravilna, postavite prenosnika drug ob drugega. Isti prehod, isti nabor naslovov, isti protokol in ista različica odjemalca so primerjava, ki jo želite; vse drugo je druga spremenljivka, ki jo boste morali pozneje izločiti.

Primerjajte en cilj z route print

Izberite dovoljeni IP vira in primerjajte oba prenosnika dvakrat: odklopljena in nato povezana. V Windowsu route print -4 izpiše poti IPv4 s predpono cilja, vmesnikom, naslednjim skokom in metriko. Zapišite vrstico, ki bi za ta cilj res zmagala, namesto da štejete vnose, ki vsebujejo besedo VPN.

Izbira poteka najprej po najdaljši predponi, nato po metriki, zato lahko bolj specifična lokalna pot premaga pot tunela, ne da bi bila videti napačna. Če je predvideni cilj znotraj 10.24.0.0/16, zdrav odjemalec pokaže ustrezno pot na vmesniku VPN, medtem ko odjemalec, ki ne uspe, pošlje isti naslov svojemu privzetemu prehodu.

Nasprotujoča si lokalna predpona lahko povzroči enak simptom. Preden kar koli dodate, odločite, kateri od dveh primerov imate: nobene poti tunela ali pot tunela, ki izgubi proti bolj specifični.

TTL expired ni napaka pri razdeljevanju poti

Ping, ki vrne TTL expired in transit, pravi, da je paket porabil svojo kvoto skokov, kar običajno pomeni zanko posredovanja in ne pokvarjenega gonilnika VPN. Ping v Windowsu sprejme TTL do 255, in zvišanje vrednosti zanke ne popravi; le odloži isto napako. Obravnavajte sporočilo kot simptom poti, ne kot dokaz o razdeljevanju poti.

Uporabite tracert -4 10.24.1.10, da vidite, kje se pot ponavlja. Če se ista dva skoka pojavljata znova in znova, poiščite pot, ki promet, namenjen tunelu, pošlje nazaj v tunel ali v lokalni usmerjevalnik, ki ga vrne.

Znova ustvarite paket na prehodu, ki ga ima v lasti

Microsoft dokumentira, da je odjemalske pakete Windows treba po ustreznih spremembah topologije znova prenesti in namestiti. Pridobite trenutni paket s prehoda Azure, ki streže temu profilu, in ga nato uporabite s podprtim postopkom za tega odjemalca. Zamenjava izvršljive datoteke nepovezane aplikacije VPN ni ista operacija kot ponovno ustvarjanje nastavitev, specifičnih za prehod. Znova prenesti paket je poceni; ugibati lokalne poti ni.

Znova se povežite in znova preberite pot za prvotni cilj. Shranite vrstici pred in po skupaj z zapisom spremembe, da bo rezultat natančnejši od znova sem namestil odjemalca.

Scenariji usmerjanja Azure P2S ločujejo neposredno peerane VNete od omrežij, doseženih prek drugih tunelov, in nov paket ne more narediti peeranja tranzitivnega. Nekateri scenariji Windows site-to-site ali BGP zahtevajo tudi ročno nastavljene oddaljene poti, zato osvežitev paketa ni univerzalni mehanizem razdeljevanja poti.

Ohranite začasno pot začasno

Ročna pot lahko izolira manjkajočo odjemalsko pot, vendar jo zgradite iz dejanske zasnove: route add 10.24.0.0 mask 255.255.0.0 172.16.0.1 if 42, brez trajne zastavice, da ob ponovnem zagonu izgine. Indeks vmesnika in naslednji skok izberite iz povezanega adapterja VPN, ne iz ugibanja.

Ne puščajte poskusne poti kot trajnega konkurenčnega lastnika. Prihodnje posodobitve profila lahko dodajo isto predpono z drugo metriko in takrat ročni vnos tiho odloči, katera pot zmaga. Korak odstranitve zapišite v spremembo.

Ko je pravilna pot aktivna, preizkusite ciljno aplikacijo namesto pinga. Če paketi dosežejo Azure, a storitev še vedno ne uspe, preverite varnostno skupino omrežja in povratno pot, ker sta neodvisni od tega, ali se je prenosnik naučil predpone.