En VPN-rutt fäst vid ett gränssnittsindex går sönder vid återanslutning

Rutten fungerade i veckor och började sedan skicka trafik ingenstans, medan målet var oförändrat och ingenting redigerades. Det som ändrades är numret: en rutt skapad mot ett visst gränssnittsindex refererar till en adapter som inte längre finns efter en återanslutning, och målprefixet fortsätter att peka på infrastruktur som har bytts ut. Att lägga till varaktighet i det kommandot hjälper inte, för problemet var aldrig om rutten överlevde en omstart. Lösningen är att knyta avsikten till anslutningen, som enligt konstruktionen överlever adapterbyten.

Kontrollera vad rutten faktiskt pekar på

Börja med att läsa ruttposten och adapterna sida vid sida. En rutt med nästa hopp på VPN-gränssnittet och ett index som inte matchar någon aktuell adapter är signaturen för det här felet; samma prefix på ett annat index är antingen en rest eller den rutt du faktiskt vill ha. Läs båda listorna innan du ändrar någon av dem, för den intressanta jämförelsen är mellan numret i rutten och de nummer som finns nu. Om rutten index finns i adapterlistan är indexet inte ditt problem och sökningen flyttar till mätvärden, policy eller den bortre änden. Om det inte finns där är det inget mer att diagnostisera: rutten är knuten till infrastruktur som inte längre finns.

Get-NetRoute -DestinationPrefix '10.77.0.0/16' | Select-Object DestinationPrefix, NextHop, InterfaceIndex, Store
Get-NetAdapter | Where-Object InterfaceDescription -like '*VPN*' | Select-Object Name, InterfaceIndex, InterfaceDescription
Get-VpnConnection -Name 'Lab VPN' | Select-Object Name, ServerAddress, SplitTunneling

Kolonnen Store skiljer en post som består genom omstarter från en som försvinner med adaptern, och den skillnaden avgör om felet kommer tillbaka i morgon. En post i det beständiga lagret som pekar på ett försvunnet index är det värsta fallet, eftersom den överlever omstarter utan att någonsin matcha något.

Bind prefixet till profilen, inte till adaptern

En inbyggd Windows-VPN kan bära sin egen ruttlista, så anslutningen återanvänder rätt adapter varje gång den kommer upp. Rutten följer då profilen i stället för ett nummer du såg en gång, och inget skript behöver gissa ett index efter varje uppringning. Att lägga till ett prefix är också reversibelt via motsvarande borttagningskommando, vilket håller ändringen granskningsbar. Prefixet lagras med anslutningen i stället för i ett startskript, så en profil som kopierats till en annan användare bär avsikten med sig.

Add-VpnConnectionRoute -ConnectionName 'Lab VPN' -DestinationPrefix '10.77.0.0/16' -PassThru

Referensen för Add-VpnConnectionRoute dokumenterar kopplingen till anslutningen, och telefonbokens omfattning spelar roll: en profil per användare och en profil för alla användare är olika objekt. Den här mekanismen tillhör Windows egen VPN-klient, så en leverantörsadapter som styrs av sin egen tjänst kan hämta sina rutter från en helt annan policykälla.

Rensa gamla rutter innan du lägger till den nya

Två rutter med samma prefix och olika ägare är värre än en felaktig rutt, eftersom vinnaren beror på mätvärden som ingen skrev ned. Undersök vad som redan finns för prefixet, inklusive poster i det beständiga lagret, och ta bort bara det som hör till det misslyckade försöket. En rest från en tidigare design är vanlig här, eftersom den felande rutten oftast ersatte något som fungerade. Notera vilka poster som hör till vilken anslutning innan du tar bort något, och håll listan i ändringsloggen.

Get-NetRoute -AddressFamily IPv4 | Where-Object DestinationPrefix -like '10.77.*'
Remove-NetRoute -DestinationPrefix '10.77.0.0/16' -NextHop '0.0.0.0' -Confirm:$false

Matcha prefix, nästa hopp, lager och ägare tillsammans i stället för att radera allt som ser likt ut. En annan anslutning kan legitimt bero på en del av det utrymmet, och en svepande borttagning förvandlar en prydlig reparation till en supportincident.

Återanslut i en annan ordning

Reproducera villkoret i stället för att hoppas att det första försöket var representativt. Koppla från, återanslut och bekräfta den valda vägen till samma fjärrresurs medan tunneln är uppe; med flera VPN inblandade, ta upp dem i en annan ordning och se om den valda vägen ändras. Ordningen är variabeln som de flesta hoppar över, och det är den som avslöjar en rutt knuten till fel anslutning.

rasdial 'Lab VPN' /disconnect
rasdial 'Lab VPN'
Find-NetRoute -RemoteIPAddress 10.77.5.20 | Select-Object -First 1

Det resultat du vill ha är inte att en adapter behåller sitt nummer en gång. Det är att rutten dyker upp med vilket nummer anslutningen än får, varje gång, och försvinner när anslutningen stängs. Att återansluta två gånger är det billigaste sättet att skilja de utfallen åt.

Vet vad rutten inte kan göra

En profilrutt ger en väg och ingenting annat. Den öppnar ingen brandvägg på distans, skapar ingen returrutt i den bortre änden och löser inte två platser som använder samma adressområde; var och en av dessa är en separat konfiguration med en separat ägare. Att bekräfta vägen är därför början på acceptanstestet och inte hela testet.

Håll prefixlistan tillsammans med profilen och notera under vilken omfattning den lades till, så att nästa person kan läsa den avsedda designen i stället för att sluta sig till den från en rutttabell. Rutter som bara finns i någons minne är de som byggs upp fel efter nästa återanslutning. En kommentar på en rad i driftsättningsanteckningarna kostar mindre än en hel eftermiddag av återupptäckt.