Azure P2S: éin Windows-klient manglar ruter etter ei VNet-endring

To laptoper autentiserer mot same Azure point-to-site-gateway, og berre éin når det nyleg tilkopla VNetet. Begge viser Connected, så autentisering er ikkje skilnaden; det er destinasjonsrutene dei held. Start med klienten som feilar, samanlikn éin destinasjon, og avgjer først då om gateway-pakken eller den lokale rutetabellen eig gapet.

Start med klienten som feilar, ikkje gatewayen

Stadfest topologien før du klandrar laptopen. Sjekk kva VNet som er knytte til gatewayens VNet, og om det nye nettet er peera direkte eller nådd via ein eigen site-to-site-tunnel. Dersom det nye VNetet ikkje er knytt til gatewayens VNet i det heile, kan ingen klientpakke rute dit, og laptopen som fungerer er anomalien som må forklarast. Skriv ned svaret, fordi det avgjer om du feilsøkjer ein klient eller ein gateway.

Når topologien stemmer, set dei to laptopsane side ved side. Same gateway, same adressepool, same protokoll og same klientbygg er samanlikninga du vil ha; alt anna er ein andre variabel du må utelukke seinare.

Samanlikn éin destinasjon med route print

Vel ein tillaten ressurs-IP og samanlikn begge laptopsane to gonger: fråkopla og deretter tilkopla. På Windows viser route print -4 IPv4-ruter med destinasjonsprefiks, grensesnitt, neste hopp og metrikk. Noter rada som faktisk ville vinne for den destinasjonen i staden for å telje oppføringar som inneheld ordet VPN.

Utvalet skjer først etter lengste prefiks, deretter metrikk, så ei meir spesifikk lokal rute kan slå tunnelruta utan å sjå feil ut. Dersom den tiltenkte destinasjonen ligg innanfor 10.24.0.0/16, viser ein frisk klient ei samsvarande rute på VPN-grensesnittet, medan klienten som feilar sender same adresse til standardgatewayen.

Eit motstridande lokalt prefiks kan gje same symptom. Før du legg til noko, avgjer kva av dei to tilfella du har: inga tunnelrute i det heile, eller ei tunnelrute som taper mot ei meir spesifikk.

TTL expired er ikkje ein rutedistribusjonsfeil

Ein ping som returnerer TTL expired in transit seier at pakken brukte opp hoppkvoten sin, noko som vanlegvis betyr ei vidaresendingsløkke og ikkje ein øydelagd VPN-drivar. Windows-ping godtek TTL opptil 255, og å auke verdien reparerer ikkje ei løkke; det utset berre same feilen. Handsame meldinga som eit symptom på banen, ikkje som prov om rutedistribusjon.

Bruk tracert -4 10.24.1.10 for å sjå kvar banen blir gjenteken. Dersom dei same to hoppa dukkar opp om og om att, sjå etter ei rute som sender tunnelretta trafikk attende i tunnelen eller til ein lokal ruter som sender han attende.

Generer pakken på nytt på gatewayen som eig han

Microsoft dokumenterer at Windows-klientpakkar må lastast ned og installerast på nytt etter relevante topologiendringar. Hent gjeldande pakke frå Azure-gatewayen som betener denne profilen, og bruk han deretter med den støtta prosessen for den klienten. Å erstatte ei køyrbar fil frå ein urelatert VPN-applikasjon er ikkje same operasjon som å regenerere gateway-spesifikke innstillingar. Å laste ned pakken på nytt er billeg; å gjete på lokale ruter er det ikkje.

Kopla til på nytt og les ruta for den opphavlege destinasjonen igjen. Ta vare på radene før og etter saman med endringsnotatet, slik at resultatet blir meir presist enn installerte klienten på nytt.

Azure P2S-rutingscenario skil direkte peera VNet frå nettverk som ein når via andre tunnelar, og ein ny pakke kan ikkje gjere peering transitiv. Nokre Windows site-to-site- eller BGP-scenario treng òg manuelt konfigurerte eksterne ruter, så pakkeoppdatering er ikkje ein universell rutedistribusjonsmekanisme.

Hald ei mellombels rute mellombels

Ei manuell rute kan isolere ei manglande klientrute, men bygg henne frå den faktiske designen: route add 10.24.0.0 mask 255.255.0.0 172.16.0.1 if 42, utan det vedvarande flagget, slik at ho forsvinn ved omstart. Vel grensesnittindeks og neste hopp frå den tilkopla VPN-adapteren, ikkje frå ei gjetting.

Ikkje la ei eksperimentell rute bli ståande som ein permanent konkurrerande eigar. Framtidige profiloppdateringar kan leggje til same prefikset med ein annan metrikk, og då avgjer den manuelle oppføringa i det stille kva bane som vinn. Noter fjerningssteget i endringa.

Når den rette ruta er aktiv, test målapplikasjonen i staden for ein ping. Dersom pakkane når Azure men tenesta framleis feilar, sjekk nettverkssikkerheitsgruppa og returvegen, fordi dei er åtskilde frå om laptopen har lært prefikset.