Jak usunąć nieaktualną trasę pozostawioną przez VPN w Windows

Sesja zakończyła się kilka godzin temu, adapter zniknął, a trasa nadal jest w tabeli i wskazuje interfejs 42. Usunięcie tego wiersza to jedno polecenie; ustalenie, że to właściwy wiersz, wymaga czterech sprawdzeń. Tabela tras jest wspólna, więc szerokie usunięcie zabiera ścieżki, z których nadal korzystają inne połączenia, w tym ta, która niesie tunel. Każdy krok poniżej zawęża cel, aż może pasować tylko jeden wpis.

1. Ustal, czy wpis jest nieaktualny, czy zamierzony

Wpis, który przetrwał ponowne uruchomienie, został gdzieś zapisany, a to miejsce jest zwykle decyzją, nie przypadkiem. Dzielony tunel zależy od tras, które wyglądają dokładnie jak pozostałości, a zasada przepychająca jeden prefiks przez tunel jest nie do odróżnienia od nieaktualnego wpisu na jednej liście. Zapytaj, kiedy pojawiła się trasa: ta, która istnieje tylko podczas działania tunelu, należy do konfiguracji klienta, więc polecenie czyszczące to niewłaściwe narzędzie. Usuń zamierzoną trasę, a następne połączenie zawiedzie na kroku, którego nikt nie obserwuje.

Trasa punktu końcowego zasługuje na własne ostrzeżenie. Gdy klient dodaje trasę hosta do serwera VPN, aby szyfrowane pakiety mogły do niego dotrzeć przez połączenie lokalne, usunięcie tej trasy zawali tunel przy następnym połączeniu, a objaw czyta się jak awaria serwera. Przed czymkolwiek porównaj cel z adresem, z którym łączy się klient: jeden publiczny adres zgodny z serwerem VPN to ścieżka zewnętrzna, nie śmieci.

2. Zapisz cztery pola, które nazywają wpis

Sam prefiks nie jest tożsamością, bo dwa interfejsy mogą mieć trasy do tego samego celu. Zapisz prefiks docelowy, indeks interfejsu, następny skok i magazyn zasad, ponieważ te cztery wartości opisują dokładnie jeden wpis. Jedna lista daje je wszystkie:

Get-NetRoute -AddressFamily IPv4 | Sort-Object RouteMetric

Sortowanie według metryki podnosi trasy, które maszyna naprawdę preferuje, i tam zwykle siedzi pozostałość. Porównaj wpis, gdy tunel działa, i jeszcze raz po jego spadku: trasa, która znika z adapterem, należała do klienta, a ta, która zostaje, została zapisana przez coś innego. Magazyn zasad to pole, które ludzie pomijają, i to ono wyjaśnia ponowne pojawienie się, bo wpis usunięty z aktywnego magazynu wraca po następnym odświeżeniu zasad. Zapisz cztery wartości, zanim uruchomisz cokolwiek, co zmienia stan.

3. Obejrzyj usunięcie, a potem usuń jeden wpis

Remove-NetRoute przyjmuje ten sam prefiks i indeks interfejsu, które wypisał Get-NetRoute, i ma przełącznik podglądu, więc niczego nie trzeba zgadywać. Uruchom parę w tej kolejności:

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

Podgląd wypisuje obiekt, który zostałby usunięty, więc przed zwolnieniem przełącznika porównaj prefiks, interfejs i następny skok z notatkami. Żadna z linii nie dociera do wpisu trwałego, bo aktywny magazyn jest domyślny; dodaj -PolicyStore PersistentStore, gdy rozpoznana trasa tam mieszka, inaczej usunięcie wygląda na udane, a wpis wraca przy następnym odświeżeniu zasad. Gdy sesja jest zdalna, zachowaj pozapasmową ścieżkę odzyskiwania, bo usunięcie trasy niosącej twoje własne połączenie kończy je. Nigdy nie sięgaj po polecenie, które czyści tabelę.

4. Znajdź komponent, który ją przywraca

Usunięcie nie jest naprawą, dopóki właściciel nadal jest skonfigurowany do instalowania trasy. Właściciel to zwykle jeden z trzech: profil klienta VPN z listą dzielonego tunelu, skrypt lub zadanie zaplanowane, które dodaje trasy przy logowaniu, albo zasada domeny zastosowana do maszyny. Najpierw sprawdź profil, bo działa przy każdym połączeniu:

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

Trwałe wpisy są widoczne bez podłączania czegokolwiek, więc trasa, która wraca po restarcie bez sesji VPN, prawie zawsze mieszka w tym magazynie albo w skrypcie startowym. Popraw tam właściciela, a ręczne usunięcie staje się weryfikacją zamiast leczeniem.

5. Sprawdź wyszukiwanie, sąsiadów i notatkę

Czysty wynik to nie to, że trasa zniknęła; to wyszukiwanie, które teraz wybiera interfejs, którego oczekiwałeś. Zapytaj maszynę, dokąd poszedłby pakiet do dotkniętego prefiksu, bo pozostałość wciąż nazywa martwy indeks, podczas gdy czysta odpowiedź nazywa interfejs bezpośredniego połączenia lub właściwą bramę. Find-NetRoute odpowiada na to dla jednego adresu naraz:

Find-NetRoute -RemoteIPAddress 10.20.4.7

Następnie przetestuj sąsiada: wybierz drugi prefiks, którego dzielony tunel nadal potrzebuje, i potwierdź, że jego wyszukiwanie się nie zmieniło, bo usunięcie jednej trasy za dużo to błąd, do którego to czyszczenie zachęca. Ponów aplikację, która pierwotnie zawiodła, i zapisz, który komponent jest teraz właścicielem prefiksu. Dokumentacja Microsoftu dla Get-NetRoute wymienia pola, które zapisałeś w drugim kroku. Za pół roku to notatka powstrzyma dwukrotne diagnozowanie tego samego wpisu.