Azure P2S: én Windows-klient mangler ruter efter en VNet-ændring

To laptops godkendes mod den samme Azure point-to-site-gateway, og kun én kan nå det nyligt tilknyttede VNet. Begge viser Connected, så godkendelse er ikke forskellen; det er de destinationsruter, de holder. Start med den klient, der fejler, sammenlign én enkelt destination, og afgør først derefter, om gateway-pakken eller den lokale rutetabel ejer hullet.

Start med den klient, der fejler, ikke med gatewayen

Bekræft topologien, før du bebrejder laptop'en. Undersøg hvilke VNet der er tilknyttet gatewayens VNet, og om det nye netværk er peered direkte eller nås via en separat site-to-site-tunnel. Hvis det nye VNet slet ikke er tilknyttet gatewayens VNet, kan ingen klientpakke route dertil, og den fungerende laptop er den anomali, der skal forklares. Skriv svaret ned, fordi det afgør, om du fejlretter en klient eller en gateway.

Når topologien stemmer, stil de to laptops side om side. Samme gateway, samme adressepulje, samme protokol og samme klientbuild er den sammenligning, du vil have; alt andet er en anden variabel, som du senere skal udelukke.

Sammenlign én destination med route print

Vælg en tilladt ressource-IP, og sammenlign begge laptops to gange: afbrudt og derefter tilsluttet. På Windows viser route print -4 IPv4-ruter med destinationspræfiks, interface, næste hop og metrik. Notér den række, der faktisk ville vinde for den destination, i stedet for at tælle poster, der indeholder ordet VPN.

Valget sker efter længste præfiks først og derefter metrik, så en mere specifik lokal rute kan slå tunnelruten uden at se forkert ud. Hvis den tilsigtede destination ligger inden for 10.24.0.0/16, viser en sund klient en matchende rute på VPN-interfacet, mens den fejlende klient sender samme adresse til sin standardgateway.

Et konfliktende lokalt præfiks kan give det samme symptom. Før du tilføjer noget, skal du afgøre, hvilket af de to tilfælde du har: ingen tunnelrute overhovedet, eller en tunnelrute, der taber til en mere specifik.

TTL expired er ikke en rutefordelingsfejl

En ping, der returnerer TTL expired in transit, siger, at pakken har brugt sin hop-kvote, hvilket normalt betyder en videresendelsesløkke og ikke en ødelagt VPN-driver. Windows ping accepterer en TTL på op til 255, og at hæve værdien reparerer ikke en løkke; det udsætter kun den samme fejl. Behandl meddelelsen som et stisymptom, ikke som bevis om rutefordeling.

Brug tracert -4 10.24.1.10 til at se, hvor stien gentages. Hvis de samme to hop dukker op igen og igen, så led efter en rute, der sender tunnelrettet trafik tilbage i tunnelen eller til en lokal router, der videresender den tilbage.

Generér pakken igen på den gateway, der ejer den

Microsoft dokumenterer, at Windows-klientpakker skal downloades og installeres igen efter relevante topologiændringer. Hent den aktuelle pakke fra den Azure-gateway, der betjener denne profil, og anvend den derefter med den understøttede proces for den klient. At erstatte en eksekverbar fil fra en ikke-relateret VPN-applikation er ikke samme handling som at regenerere gatewayspecifikke indstillinger. At downloade pakken igen er billigt; at gætte på lokale ruter er ikke.

Genopret forbindelsen, og læs ruten for den oprindelige destination igen. Gem rækkerne før og efter sammen med ændringsnotatet, så resultatet er mere præcist end geninstallerede klienten.

Azure P2S-rutingscenarier skelner direkte peerede VNet fra netværk, der nås via andre tunneler, og en ny pakke kan ikke gøre peering transitiv. Nogle Windows site-to-site- eller BGP-scenarier kræver også manuelt konfigurerede fjernruter, så pakkefornyelse er ikke en universel rutefordelingsmekanisme.

Hold en midlertidig rute midlertidig

En manuel rute kan isolere en manglende klientrute, men byg den ud fra det faktiske design: route add 10.24.0.0 mask 255.255.0.0 172.16.0.1 if 42, uden det persistente flag, så den forsvinder ved genstart. Vælg interfaceindeks og næste hop ud fra den tilsluttede VPN-adapter, ikke ud fra et gæt.

Efterlad ikke en eksperimentel rute som en permanent konkurrerende ejer. Fremtidige profilopdateringer kan tilføje samme præfiks med en anden metrik, og så afgør den manuelle post i al stilhed, hvilken sti der vinder. Notér fjernelsestrinet i ændringen.

Når den korrekte rute er aktiv, test den pågældende applikation i stedet for en ping. Hvis pakker når Azure, men tjenesten stadig fejler, så undersøg netværkssikkerhedsgruppen og returvejen, fordi de er adskilt fra, om laptop'en har lært præfikset.