Azure P2S: en Windows-klient saknar rutter efter en VNet-ändring

Två laptops autentiserar mot samma Azure point-to-site-gateway, och bara en når det nyss anslutna VNetet. Båda visar Connected, så autentiseringen är inte skillnaden; det är destinationsrutterna de håller. Börja med klienten som misslyckas, jämför en enda destination och avgör först därefter om gateway-paketet eller den lokala routingtabellen äger gapet.

Börja med klienten som misslyckas, inte med gatewayen

Bekräfta topologin innan du skyller på laptopen. Kontrollera vilka VNet som är anslutna till gatewayens VNet och om det nya nätet är peerat direkt eller nås via en separat site-to-site-tunnel. Om det nya VNetet inte alls är anslutet till gatewayens VNet kan inget klientpaket routa dit, och laptopen som fungerar är anomalin som måste förklaras. Skriv ned svaret, eftersom det avgör om du felsöker en klient eller en gateway.

När topologin stämmer, ställ de två laptoparna sida vid sida. Samma gateway, samma adresspool, samma protokoll och samma klientbygge är jämförelsen du vill ha; allt annat är en andra variabel som du senare måste eliminera.

Jämför en destination med route print

Välj en tillåten resurs-IP och jämför båda laptoparna två gånger: frånkopplade och sedan anslutna. På Windows visar route print -4 IPv4-rutter med destinationsprefix, gränssnitt, nästa hopp och metrik. Notera raden som faktiskt skulle vinna för den destinationen i stället för att räkna poster som innehåller ordet VPN.

Urvalet sker först efter längsta prefix, sedan metrik, så en mer specifik lokal rutt kan slå tunnelrutten utan att se fel ut. Om den avsedda destinationen ligger inom 10.24.0.0/16 visar en frisk klient en matchande rutt på VPN-gränssnittet, medan klienten som misslyckas skickar samma adress till sin standardgateway.

Ett motstridigt lokalt prefix kan ge samma symptom. Innan du lägger till något, avgör vilket av de två fallen du har: ingen tunnelrutt alls, eller en tunnelrutt som förlorar mot en mer specifik.

TTL expired är inte ett ruttfördelningsfel

En ping som returnerar TTL expired in transit säger att paketet förbrukade sin hoppkvot, vilket oftast betyder en vidarebefordringsslinga och inte en trasig VPN-drivrutin. Windows-ping accepterar TTL upp till 255, och att höja värdet reparerar inte en slinga; det skjuter bara upp samma fel. Behandla meddelandet som ett symptom på vägen, inte som bevis om ruttfördelning.

Använd tracert -4 10.24.1.10 för att se var vägen upprepas. Om samma två hopp dyker upp om och om igen, leta efter en rutt som skickar trafik mot tunneln tillbaka in i tunneln eller till en lokal router som skickar tillbaka den.

Generera om paketet på gatewayen som äger det

Microsoft dokumenterar att Windows-klientpaket måste laddas ned och installeras igen efter relevanta topologiändringar. Hämta aktuellt paket från den Azure-gateway som betjänar den här profilen och använd det sedan med den stödda processen för den klienten. Att ersätta en körbar fil från ett orelaterat VPN-program är inte samma operation som att återskapa gatewayspecifika inställningar. Att ladda ned paketet igen är billigt; att gissa lokala rutter är det inte.

Anslut igen och läs rutten för den ursprungliga destinationen på nytt. Spara raderna före och efter tillsammans med ändringsnoteringen så att resultatet blir mer exakt än installerade om klienten.

Azure P2S-routningsscenarier skiljer direkt peerade VNet från nätverk som nås via andra tunnlar, och ett nytt paket kan inte göra peering transitiv. Vissa Windows site-to-site- eller BGP-scenarier kräver också manuellt konfigurerade fjärrrutter, så paketuppdatering är ingen universell ruttfördelningsmekanism.

Håll en tillfällig rutt tillfällig

En manuell rutt kan isolera en saknad klientrutt, men bygg den från den faktiska designen: route add 10.24.0.0 mask 255.255.0.0 172.16.0.1 if 42, utan den beständiga flaggan, så att den försvinner vid omstart. Välj gränssnittsindex och nästa hopp från den anslutna VPN-adaptern, inte från en gissning.

Lämna inte en experimentell rutt som permanent konkurrerande ägare. Framtida profiluppdateringar kan lägga till samma prefix med en annan metrik, och då avgör den manuella posten i tysthet vilken väg som vinner. Notera borttagningssteget i ändringen.

När den korrekta rutten är aktiv, testa målprogrammet i stället för en ping. Om paketen når Azure men tjänsten fortfarande misslyckas, kontrollera nätverkssäkerhetsgruppen och returvägen, eftersom de är åtskilda från om laptopen har lärt sig prefixet.