Azure P2S: één Windows-client mist routes na een VNet-wijziging

Twee laptops verifiëren bij dezelfde Azure point-to-site-gateway, en slechts één bereikt het nieuw verbonden VNet. Beide tonen Connected, dus verificatie is niet het verschil; de bestemmingsroutes die ze vasthouden zijn dat. Begin bij de client die faalt, vergelijk één bestemming, en beslis pas daarna of het gatewaypakket of de lokale routetabel de kloof bezit.

Begin bij de client die faalt, niet bij de gateway

Bevestig de topologie voordat u de laptop de schuld geeft. Controleer welke VNets aan het gateway-VNet zijn gekoppeld en of het nieuwe netwerk direct gepeerd is of via een aparte site-to-site-tunnel wordt bereikt. Als het nieuwe VNet helemaal niet aan het gateway-VNet is gekoppeld, kan geen enkel clientpakket erheen routeren, en de werkende laptop is de anomalie die moet worden uitgelegd. Schrijf het antwoord op, want het bepaalt of u een client of een gateway debugt.

Als de topologie klopt, zet de twee laptops naast elkaar. Dezelfde gateway, dezelfde adrespool, hetzelfde protocol en dezelfde clientbuild zijn de vergelijking die u wilt; al het andere is een tweede variabele die u later moet uitsluiten.

Vergelijk één bestemming met route print

Kies een toegestaan resource-IP en vergelijk beide laptops twee keer: losgekoppeld en daarna verbonden. Op Windows toont route print -4 IPv4-routes met bestemmingsprefix, interface, volgende hop en metriek. Noteer de regel die voor die bestemming echt zou winnen in plaats van vermeldingen te tellen die het woord VPN bevatten.

De selectie gaat eerst op de langste prefix en dan op metriek, dus een specifiekere lokale route kan de tunnelroute verslaan zonder verkeerd te lijken. Als de bedoelde bestemming binnen 10.24.0.0/16 ligt, toont een gezonde client een overeenkomende route op de VPN-interface, terwijl de falende client hetzelfde adres naar zijn standaardgateway stuurt.

Een conflicterend lokaal prefix kan hetzelfde symptoom geven. Bepaal voordat u iets toevoegt welk van de twee gevallen u hebt: helemaal geen tunnelroute, of een tunnelroute die verliest van een specifiekere.

TTL expired is geen routedistributiefout

Een ping die TTL expired in transit teruggeeft, zegt dat het pakket zijn hopbudget heeft verbruikt, wat meestal een doorstuurlus betekent en geen kapot VPN-stuurprogramma. Windows-ping accepteert een TTL tot 255, en het verhogen van de waarde repareert geen lus; het stelt alleen dezelfde fout uit. Behandel het bericht als een symptoom van het pad, niet als bewijs over routedistributie.

Gebruik tracert -4 10.24.1.10 om te zien waar het pad zich herhaalt. Als dezelfde twee hops steeds weer verschijnen, zoek dan een route die verkeer richting de tunnel terug de tunnel in stuurt of naar een lokale router die het terugstuurt.

Genereer het pakket opnieuw op de gateway die het bezit

Microsoft documenteert dat Windows-clientpakketten na relevante topologiewijzigingen opnieuw moeten worden gedownload en geïnstalleerd. Haal het huidige pakket van de Azure-gateway die dit profiel bedient, en pas het daarna toe met het ondersteunde proces voor die client. Het vervangen van een uitvoerbaar bestand van een niet-gerelateerde VPN-applicatie is niet dezelfde handeling als het opnieuw genereren van gatewayspecifieke instellingen. Het pakket opnieuw downloaden is goedkoop; gokken op lokale routes niet.

Maak opnieuw verbinding en lees de route voor de oorspronkelijke bestemming opnieuw. Bewaar de regels voor en na bij het wijzigingsrecord, zodat het resultaat preciezer is dan ik heb de client opnieuw geïnstalleerd.

De Azure P2S-routingscenario's scheiden direct gepeerde VNets van netwerken die via andere tunnels worden bereikt, en een nieuw pakket kan peering niet transitief maken. Sommige Windows site-to-site- of BGP-scenario's vereisen ook handmatig geconfigureerde externe routes, dus een pakketvernieuwing is geen universeel routedistributiemechanisme.

Houd een tijdelijke route tijdelijk

Een handmatige route kan een ontbrekende clientroute isoleren, maar bouw hem vanuit het werkelijke ontwerp: route add 10.24.0.0 mask 255.255.0.0 172.16.0.1 if 42, zonder de persistente vlag, zodat hij bij herstart verdwijnt. Kies de interface-index en volgende hop uit de verbonden VPN-adapter, niet uit een gok.

Laat een experimentele route niet als permanente concurrerende eigenaar staan. Toekomstige profielupdates kunnen hetzelfde prefix met een andere metriek toevoegen, en dan beslist de handmatige vermelding stil welke route wint. Noteer de verwijderstap in de wijziging.

Zodra de juiste route actief is, test de doelapplicatie in plaats van een ping. Als pakketten Azure bereiken maar de service nog steeds faalt, controleer dan de netwerkbeveiligingsgroep en het retourpad, want die staan los van of de laptop het prefix heeft geleerd.