Azure P2S: én Windows-klient mangler ruter etter en VNet-endring

To laptoper autentiserer mot samme Azure point-to-site-gateway, og bare én når det nylig tilkoblede VNetet. Begge viser Connected, så autentisering er ikke forskjellen; det er destinasjonsrutene de holder. Start med klienten som feiler, sammenlign én destinasjon, og avgjør først da om gateway-pakken eller den lokale rutetabellen eier gapet.

Start med klienten som feiler, ikke gatewayen

Bekreft topologien før du klandrer laptopen. Sjekk hvilke VNet som er koblet til gatewayens VNet, og om det nye nettet er peeret direkte eller nås via en egen site-to-site-tunnel. Hvis det nye VNetet ikke er koblet til gatewayens VNet i det hele tatt, kan ingen klientpakke rute dit, og laptopen som fungerer er anomalien som må forklares. Skriv ned svaret, fordi det avgjør om du feilsøker en klient eller en gateway.

Når topologien stemmer, sett de to laptoppene side ved side. Samme gateway, samme adressepool, samme protokoll og samme klientbygg er sammenligningen du vil ha; alt annet er en andre variabel du må utelukke senere.

Sammenlign én destinasjon med route print

Velg en tillatt ressurs-IP og sammenlign begge laptoppene to ganger: frakoblet og deretter tilkoblet. På Windows viser route print -4 IPv4-ruter med destinasjonsprefiks, grensesnitt, neste hopp og metrikk. Noter raden som faktisk ville vinne for den destinasjonen i stedet for å telle oppføringer som inneholder ordet VPN.

Utvalget skjer først etter lengste prefiks, deretter metrikk, så en mer spesifikk lokal rute kan slå tunnelruten uten å se feil ut. Hvis den tiltenkte destinasjonen ligger innenfor 10.24.0.0/16, viser en frisk klient en samsvarende rute på VPN-grensesnittet, mens klienten som feiler sender samme adresse til standardgatewayen.

Et motstridende lokalt prefiks kan gi samme symptom. Før du legger til noe, avgjør hvilket av de to tilfellene du har: ingen tunnelrute i det hele tatt, eller en tunnelrute som taper mot en mer spesifikk.

TTL expired er ikke en rutedistribusjonsfeil

En ping som returnerer TTL expired in transit sier at pakken brukte opp hoppkvoten sin, noe som vanligvis betyr en videresendingsløkke og ikke en ødelagt VPN-driver. Windows-ping godtar TTL opptil 255, og å øke verdien reparerer ikke en løkke; det utsetter bare samme feil. Behandle meldingen som et symptom på banen, ikke som bevis om rutedistribusjon.

Bruk tracert -4 10.24.1.10 for å se hvor banen gjentas. Hvis de samme to hoppene dukker opp igjen og igjen, se etter en rute som sender tunnelrettet trafikk tilbake i tunnelen eller til en lokal ruter som sender den tilbake.

Generer pakken på nytt på gatewayen som eier den

Microsoft dokumenterer at Windows-klientpakker må lastes ned og installeres på nytt etter relevante topologiendringer. Hent gjeldende pakke fra Azure-gatewayen som betjener denne profilen, og bruk den deretter med den støttede prosessen for den klienten. Å erstatte en kjørbar fil fra en urelatert VPN-applikasjon er ikke samme operasjon som å regenerere gateway-spesifikke innstillinger. Å laste ned pakken på nytt er billig; å gjette på lokale ruter er det ikke.

Koble til på nytt og les ruten for den opprinnelige destinasjonen igjen. Ta vare på radene før og etter sammen med endringsnotatet, slik at resultatet blir mer presist enn reinstallasjonen av klienten.

Azure P2S-rutingscenarier skiller direkte peerete VNet fra nettverk som nås via andre tunneler, og en ny pakke kan ikke gjøre peering transitiv. Noen Windows site-to-site- eller BGP-scenarier trenger også manuelt konfigurerte eksterne ruter, så pakkeoppdatering er ikke en universell rutedistribusjonsmekanisme.

Hold en midlertidig rute midlertidig

En manuell rute kan isolere en manglende klientrute, men bygg den fra den faktiske designen: route add 10.24.0.0 mask 255.255.0.0 172.16.0.1 if 42, uten det vedvarende flagget, slik at den forsvinner ved omstart. Velg grensesnittindeks og neste hopp fra den tilkoblede VPN-adapteren, ikke fra en gjetning.

Ikke la en eksperimentell rute bli stående som en permanent konkurrerende eier. Fremtidige profiloppdateringer kan legge til samme prefiks med en annen metrikk, og da avgjør den manuelle oppføringen i stillhet hvilken bane som vinner. Noter fjernelsestrinnet i endringen.

Når den riktige ruten er aktiv, test målapplikasjonen i stedet for en ping. Hvis pakkene når Azure men tjenesten fortsatt feiler, sjekk nettverkssikkerhetsgruppen og returveien, fordi de er adskilt fra om laptopen har lært prefikset.