Slik fjerner du en foreldet rute som Windows VPN etterlot

Økten din tok slutt for timer siden, adapteren er borte, og ruten ligger fortsatt i tabellen og peker på grensesnitt 42. Å slette den raden tar én kommando; å avgjøre at det er riktig rad tar fire kontroller. En rutetabell er delt, så en bred fjerning tar ut stier som andre tilkoblinger fortsatt bruker, inkludert den som bærer tunnelen. Hvert trinn nedenfor snevrer inn målet til bare én oppføring kan passe.

1. Avgjør om oppføringen er foreldet eller tilsiktet

En oppføring som overlevde en omstart ble skrevet et sted, og det stedet er vanligvis en beslutning, ikke en ulykke. Splittet tunnel avhenger av ruter som ser nøyaktig ut som rester, og en policy som skyver ett prefiks gjennom tunnelen kan ikke skilles fra en foreldet oppføring i én liste. Spør når ruten dukket opp: en som bare finnes mens tunnelen er oppe, tilhører klientens konfigurasjon, så en oppryddingskommando er feil verktøy. Fjern en bevisst rute, og neste tilkobling feiler på trinnet ingen følger med på.

Endepunktsruten fortjener sin egen advarsel. Når en klient legger til en vertsrute mot VPN-serveren slik at krypterte pakker kan nå den over den lokale tilkoblingen, vil sletting av den ruten kollapse tunnelen ved neste gjenoppkobling, og symptomet leses som en serverfeil. Sammenlign målet med adressen klienten kobler til før du berører noe: én offentlig adresse som samsvarer med VPN-serveren er den ytre stien, ikke søppel.

2. Noter de fire feltene som navngir oppføringen

Et prefiks alene er ikke en identitet, fordi to grensesnitt kan holde ruter til samme mål. Noter målprefikset, grensesnittindeksen, neste hopp og policy-lageret, siden de fire verdiene beskriver nøyaktig én oppføring. Én liste gir deg alle dem:

Get-NetRoute -AddressFamily IPv4 | Sort-Object RouteMetric

Sortering etter metrikk løfter rutene maskinen faktisk foretrekker, og det er der en rest vanligvis sitter. Sammenlign oppføringen mens tunnelen er oppe og igjen etter at den faller: en rute som forsvinner med adapteren var klientens, og den som blir igjen ble skrevet av noe annet. Policy-lageret er feltet folk hopper over, og det er det som forklarer en gjenopptreden, fordi en oppføring fjernet fra det aktive lageret kommer tilbake etter neste policy-oppdatering. Skriv ned de fire verdiene før du kjører noe som endrer tilstand.

3. Forhåndsvis fjerningen, og fjern deretter én oppføring

Remove-NetRoute godtar samme prefiks og grensesnittindeks som Get-NetRoute skrev ut, og det har en forhåndsvisningsbryter, så ingenting må gjettes. Kjør paret i denne rekkefølgen:

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

Forhåndsvisningen skriver ut objektet det ville slette, så sammenlign prefiks, grensesnitt og neste hopp med notatene dine før du slipper bryteren. Ingen av linjene når en vedvarende oppføring, fordi det aktive lageret er standard; legg til -PolicyStore PersistentStore når ruten du identifiserte bor der, ellers ser fjerningen ut til å virke og oppføringen kommer tilbake ved neste policy-oppdatering. Hold en båndløs gjenopprettingsvei når økten er ekstern, siden sletting av ruten som bærer din egen tilkobling avslutter den. Griper aldri etter en kommando som tømmer tabellen.

4. Finn komponenten som setter den tilbake

Sletting er ikke en reparasjon så lenge eieren fortsatt er konfigurert til å installere ruten. Eieren er vanligvis én av tre: VPN-klientens profil med sin splitt-tunnel-liste, et skript eller en planlagt oppgave som legger til ruter ved pålogging, eller en domenepolicy brukt på maskinen. Sjekk profilen først, fordi den kjører ved hver tilkobling:

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

Vedvarende oppføringer er synlige uten å koble til noe, så en rute som kommer tilbake etter en omstart uten VPN-økt bor nesten alltid i det lageret eller i et oppstartsskript. Rett eieren der, og den manuelle slettingen blir verifisering i stedet for behandling.

5. Verifiser oppslaget, naboene og notatet

Et rent resultat er ikke at ruten er borte; det er et oppslag som nå velger grensesnittet du forventet. Spør maskinen hvor en pakke til det berørte prefikset ville gå, fordi en rest fortsatt navngir den døde indeksen mens et rent svar navngir grensesnittet på lenken eller riktig gateway. Find-NetRoute svarer på det for én adresse om gangen:

Find-NetRoute -RemoteIPAddress 10.20.4.7

Test deretter en nabo: velg et andre prefiks som en splittet tunnel fortsatt trenger, og bekreft at oppslaget er uendret, siden å ta ut én rute for mye er feilen denne oppryddingen inviterer til. Prøv applikasjonen som opprinnelig feilet på nytt, og noter hvilken komponent som eier prefikset nå. Microsofts Get-NetRoute-dokumentasjon lister feltene du skrev ned i trinn to. Om seks måneder er det notatet som hindrer samme oppføring i å bli diagnostisert to ganger.