Så tar du bort en inaktuell rutt som en Windows-VPN lämnat kvar

Sessionen tog slut för timmar sedan, adaptern är borta, och rutten ligger fortfarande i tabellen och pekar på gränssnitt 42. Att radera den raden tar ett kommando; att avgöra att det är rätt rad tar fyra kontroller. En routetabell delas, så en bred borttagning tar bort vägar som andra anslutningar fortfarande använder, inklusive den som bär tunneln. Varje steg nedan snävar in målet tills bara en post kan matcha.

1. Avgör om posten är inaktuell eller avsiktlig

En post som överlevde en omstart skrevs någonstans, och den platsen är oftast ett beslut, inte en olycka. Delad tunnel bygger på rutter som ser exakt ut som rester, och en princip som skickar ett prefix genom tunneln går inte att skilja från en inaktuell post i en enda lista. Fråga när rutten dök upp: en som bara finns medan tunneln är uppe tillhör klientens konfiguration, så ett städkommando är fel verktyg. Ta bort en avsiktlig rutt och nästa anslutning misslyckas i steget ingen tittar på.

Rutten till slutpunkten förtjänar sin egen varning. När en klient lägger till en värdrutt mot VPN-servern så att krypterade paket kan nå den via den lokala anslutningen, får borttagningen av den rutten tunneln att kollapsa vid nästa återanslutning, och symptomet läses som ett serverfel. Jämför målet med adressen klienten ansluter till innan du rör något: en enda offentlig adress som matchar VPN-servern är den yttre vägen, inte skräp.

2. Anteckna de fyra fält som namnger posten

Ett prefix ensamt är ingen identitet, eftersom två gränssnitt kan ha rutter till samma mål. Anteckna målprefixet, gränssnittsindex, nästa hopp och principarkivet, eftersom de fyra värdena beskriver exakt en post. En lista ger dig alla:

Get-NetRoute -AddressFamily IPv4 | Sort-Object RouteMetric

Sortering på metrik lyfter de rutter som maskinen faktiskt föredrar, och det är där en rest oftast sitter. Jämför posten medan tunneln är uppe och igen efter att den faller: en rutt som försvinner med adaptern var klientens, och den som blir kvar skrevs av något annat. Principarkivet är fältet folk hoppar över, och det är det som förklarar ett återuppträdande, eftersom en post som tagits bort från det aktiva arkivet kommer tillbaka efter nästa principuppdatering. Skriv ned de fyra värdena innan du kör något som ändrar tillstånd.

3. Förhandsgranska borttagningen och ta sedan bort en post

Remove-NetRoute accepterar samma prefix och gränssnittsindex som Get-NetRoute skrev ut, och det har en förhandsgranskningsbrytare, så inget behöver gissas. Kör paret i den här ordningen:

Remove-NetRoute -DestinationPrefix 10.20.0.0/16 -InterfaceIndex 42 -WhatIf
Remove-NetRoute -DestinationPrefix 10.20.0.0/16 -InterfaceIndex 42

Förhandsgranskningen skriver ut objektet den skulle radera, så jämför prefix, gränssnitt och nästa hopp med dina anteckningar innan du släpper brytaren. Ingen av raderna når en beständig post, eftersom det aktiva arkivet är standard; lägg till -PolicyStore PersistentStore när rutten du identifierade bor där, annars ser borttagningen ut att fungera och posten kommer tillbaka vid nästa principuppdatering. Håll en bandlös återställningsväg när sessionen är fjärrstyrd, eftersom borttagning av rutten som bär din egen anslutning avslutar den. Gripa aldrig efter ett kommando som tömmer tabellen.

4. Hitta komponenten som sätter tillbaka den

Borttagning är ingen reparation så länge ägaren fortfarande är konfigurerad att installera rutten. Ägaren är oftast en av tre: VPN-klientens profil med sin delade tunnellista, ett skript eller en schemalagd uppgift som lägger till rutter vid inloggning, eller en domänprincip som tillämpas på maskinen. Kontrollera profilen först, eftersom den körs vid varje anslutning:

Get-VpnConnection | Select-Object Name,SplitTunneling,ServerAddress
Get-NetRoute -PolicyStore PersistentStore

Beständiga poster syns utan att ansluta något, så en rutt som kommer tillbaka efter en omstart utan VPN-session bor nästan alltid i det arkivet eller i ett startskript. Rätta ägaren där, och den manuella borttagningen blir verifiering i stället för behandling.

5. Verifiera uppslaget, grannarna och anteckningen

Ett rent resultat är inte att rutten är borta; det är ett uppslag som nu väljer det gränssnitt du förväntade dig. Fråga maskinen vart ett paket till det drabbade prefixet skulle ta vägen, eftersom en rest fortfarande namnger det döda indexet medan ett rent svar namnger gränssnittet på länken eller rätt gateway. Find-NetRoute svarar på det för en adress i taget:

Find-NetRoute -RemoteIPAddress 10.20.4.7

Testa sedan en granne: välj ett andra prefix som en delad tunnel fortfarande behöver och bekräfta att uppslaget är oförändrat, eftersom att ta bort en rutt för mycket är felet den här städningen bjuder in till. Försök igen med applikationen som ursprungligen misslyckades, och anteckna vilken komponent som äger prefixet nu. Microsofts dokumentation för Get-NetRoute listar fälten du skrev ned i steg två. Om sex månader är det anteckningen som hindrar samma post från att diagnostiseras två gånger.