Din session sluttede for timer siden, adapteren er væk, og ruten står stadig i tabellen og peger på interface 42. At slette den række koster én kommando; at afgøre, at det er den rigtige række, koster fire kontroller. En rutetabel deles, så en bred fjernelse tager stier, som andre forbindelser stadig bruger, inklusive den, der bærer tunnelen. Hvert trin nedenfor indsnævrer målet, indtil kun én post kan matche.

1. Afgør, om posten er forældet eller bevidst

En post, der overlevede en genstart, blev skrevet et sted, og det sted er som regel en beslutning og ikke et uheld. Split-tunneling afhænger af ruter, der ser præcis ud som rester, og en politik, der skubber et præfiks gennem tunnelen, kan ikke skelnes fra en forældet post i en enkelt liste. Spørg, hvornår ruten dukkede op: en, der kun findes, mens tunnelen er oppe, hører til klientens konfiguration, så en oprydningskommando er det forkerte værktøj. Fjern en bevidst rute, og den næste forbindelse fejler ved det trin, ingen overvåger.

Endepunktsruten fortjener sin egen advarsel. Når en klient tilføjer en host-rute til VPN-serveren, så krypterede pakker kan nå den over den lokale forbindelse, får sletning af den rute tunnelen til at kollapse ved næste genopkobling, og symptomet læses som en serverfejl. Sammenlign destinationen med den adresse, klienten forbinder til, før du rører noget: en enkelt offentlig adresse, der matcher VPN-serveren, er den ydre sti, ikke affald.

2. Notér de fire felter, der navngiver posten

Et præfiks alene er ikke en identitet, fordi to interfaces kan holde ruter til den samme destination. Notér destinationspræfikset, interfaceindekset, næste hop og politik-lageret, da disse fire værdier beskriver præcis én post. En enkelt liste giver dig dem alle:

Get-NetRoute -AddressFamily IPv4 | Sort-Object RouteMetric

Sortering efter metrik løfter de ruter, maskinen faktisk foretrækker, og det er der, en rest som regel sidder. Sammenlign posten, mens tunnelen er oppe, og igen efter den er faldet: en rute, der forsvinder med adapteren, var klientens, og en, der bliver, blev skrevet af noget andet. Politik-lageret er det felt, folk springer over, og det er det, der forklarer en genoptræden, fordi en post, der er fjernet fra det aktive lager, vender tilbage efter næste politikopdatering. Skriv de fire værdier ned, før du kører noget, der ændrer tilstand.

3. Se fjernelsen forud, og fjern så én post

Remove-NetRoute accepterer det samme præfiks og interfaceindeks, som Get-NetRoute udskrev, og det har en forhåndsvisningskontakt, så intet skal gættes. Kør parret i denne rækkefølge:

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

Forhåndsvisningen udskriver det objekt, den ville slette, så sammenlign præfiks, interface og næste hop med dine noter, før du slipper kontakten. Ingen af de to linjer når en vedvarende post, fordi det aktive lager er standarden; tilføj -PolicyStore PersistentStore, når den identificerede rute bor der, ellers ser fjernelsen ud til at virke, og posten vender tilbage ved næste politikopdatering. Hold en out-of-band gendannelsessti, når sessionen er fjern, fordi sletning af den rute, der bærer din egen forbindelse, afslutter den. Grib aldrig efter en kommando, der rydder tabellen.

4. Find ud af, hvilken komponent der sætter den tilbage

En sletning er ikke en rettelse, mens ejeren stadig er konfigureret til at installere ruten. Ejeren er som regel en af tre: VPN-klientens profil med sin split-tunnel-liste, et script eller en planlagt opgave, der tilføjer ruter ved logon, eller en domænepolitik anvendt på maskinen. Tjek profilen først, fordi den kører ved hver forbindelse:

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

Vedvarende poster er synlige uden at forbinde noget, så en rute, der vender tilbage efter en genstart uden VPN-session, bor næsten altid i det lager eller i et opstartsscript. Ret ejeren der, og den manuelle sletning bliver verifikation i stedet for behandling.

5. Bekræft opslaget, naboerne og noten

Et rent resultat er ikke «ruten er væk»; det er et opslag, der nu vælger det interface, du forventede. Spørg maskinen, hvor en pakke til det berørte præfiks ville gå hen, fordi en rest stadig nævner det døde indeks, mens et rent svar nævner interface på linket eller den korrekte gateway. Find-NetRoute besvarer det for én adresse ad gangen:

Find-NetRoute -RemoteIPAddress 10.20.4.7

Test derefter en nabo: vælg et andet præfiks, som en split-tunnel stadig har brug for, og bekræft, at dets opslag er uændret, fordi at fjerne én rute for meget er den fejl, denne oprydning inviterer til. Prøv igen den applikation, der oprindeligt fejlede, og notér, hvilken komponent der ejer præfikset nu. Microsofts dokumentation for Get-NetRoute lister de felter, du skrev ned i trin to. Om seks måneder er netop den note det, der forhindrer, at den samme post bliver diagnosticeret to gange.

Relaterede artikler