Azure P2S: ühel Windowsi kliendil kaovad VNet-i muudatuse järel marsruudid

Kaks sülearvutit autendivad end sama Azure point-to-site lüüsi vastu ja ainult üks jõuab äsja ühendatud VNet-i. Mõlemad näitavad Connected, seega autentimine ei ole erinevus; erinevus on sihtkoha marsruudid, mida nad hoiavad. Alustage kliendist, mis ei tööta, võrrelge ühte sihtkohta ja alles siis otsustage, kas lünk kuulub lüüsi paketile või kohalikule marsruuditabelile.

Alustage kliendist, mis ei tööta, mitte lüüsist

Kinnitage topoloogia enne, kui sülearvutit süüdistate. Kontrollige, millised VNet-id on lüüsi VNet-iga ühendatud ja kas uus võrk on otse peeritud või jõutakse selleni eraldi site-to-site tunneliga. Kui uus VNet ei ole lüüsi VNet-iga üldse ühendatud, ei saa ükski kliendipakett sinna marsruutida ja töötav sülearvuti on anomaalia, mida tuleb selgitada. Kirjutage vastus üles, sest see otsustab, kas silute klienti või lüüsi.

Kui topoloogia on korras, asetage kaks sülearvutit kõrvuti. Sama lüüs, sama aadressikogum, sama protokoll ja sama kliendi versioon on võrdlus, mida soovite; kõik muu on teine muutuja, mille peate hiljem kõrvaldama.

Võrrelge ühte sihtkohta käsuga route print

Valige lubatud ressursi IP ja võrrelge mõlemat sülearvutit kaks korda: lahtiühendatult ja seejärel ühendatult. Windowsis loetleb route print -4 IPv4 marsruudid sihtkoha prefiksi, liidese, järgmise hüppe ja metrikaga. Märkige rida, mis selle sihtkoha jaoks tegelikult võidaks, mitte ei loendaks kirjeid, mis sisaldavad sõna VPN.

Valik käib kõigepealt pikema prefiksi, seejärel meetrika järgi, nii et täpsem kohalik marsruut võib tunnelimarsruudi võita, ilma et see vale välja näeks. Kui kavandatud sihtkoht on vahemikus 10.24.0.0/16, näitab terve klient VPN-liidesel sobivat marsruuti, samal ajal kui rikkis klient saadab sama aadressi oma vaikelüüsile.

Vastuoluline kohalik prefiks võib tekitada sama sümptomi. Enne millegi lisamist otsustage, milline kahest juhtumist teil on: tunnelimarsruut puudub täielikult, või tunnelimarsruut kaotab täpsemale.

TTL expired ei ole marsruutide jaotamise viga

Ping, mis tagastab TTL expired in transit, ütleb, et pakett kasutas oma hüppekihtkvoodi ära, mis tavaliselt tähendab edastussilmust, mitte katkist VPN-draiverit. Windowsi ping aktsepteerib TTL-i kuni 255 ja väärtuse tõstmine silmust ei paranda; see ainult lükkab sama vea edasi. Käsitlege sõnumit tee sümptomina, mitte tõendina marsruutide jaotamise kohta.

Kasutage tracert -4 10.24.1.10, et näha, kus tee kordub. Kui samad kaks hüpet ilmuvad ikka ja jälle, otsige marsruuti, mis saadab tunnelisse suunatud liikluse tagasi tunnelisse või kohalikku ruuterisse, mis selle tagasi edastab.

Genereerige pakett uuesti lüüsis, millele see kuulub

Microsoft dokumenteerib, et Windowsi kliendipaketid tuleb pärast asjakohaseid topoloogiamuudatusi uuesti alla laadida ja installida. Hankige praegune pakett Azure'i lüüsist, mis seda profiili teenindab, ja rakendage seda selle kliendi jaoks toetatud protsessiga. Sõltumatu VPN-rakenduse käivitatava faili asendamine ei ole sama toiming kui lüüsipõhiste seadete uuesti genereerimine. Paketi uuesti allalaadimine on odav; kohalike marsruutide oletamine ei ole.

Ühendage uuesti ja lugege algse sihtkoha marsruut uuesti. Hoidke enne ja pärast read koos muudatuse kirjega, et tulemus oleks täpsem kui installisin kliendi uuesti.

Azure P2S marsruutimistsenaariumid eristavad otseselt peeritud VNet-e teiste tunnelite kaudu jõutavatest võrkudest ja uus pakett ei saa peerimist transitiivseks muuta. Mõned Windowsi site-to-site või BGP stsenaariumid vajavad ka käsitsi seadistatud kaugmarsruute, seega paketi värskendamine ei ole universaalne marsruutide jaotamise mehhanism.

Hoidke ajutine marsruut ajutisena

Käsitsi marsruut võib isoleerida puuduva kliendimarsruudi, kuid ehitage see tegelikust disainist: route add 10.24.0.0 mask 255.255.0.0 172.16.0.1 if 42, ilma püsiväljaga, et see taaskäivitusel kaoks. Valige liidese indeks ja järgmine hüpe ühendatud VPN-adapterilt, mitte oletusest.

Ärge jätke katsemarsruuti püsiva konkureeriva omanikuna alles. Tulevased profiilivärskendused võivad lisada sama prefiksi teise meetrikaga ja siis otsustab käsitsi kirje vaikselt, milline tee võidab. Märkige eemaldamise samm muudatusse.

Kui õige marsruut on aktiivne, testige sihtrakendust, mitte pingi. Kui paketid jõuavad Azure'i, kuid teenus ikka ei tööta, kontrollige võrgu turvagruppi ja tagasiteed, sest need on eraldi sellest, kas sülearvuti prefiksi õppis.