Brak internetu po odinstalowaniu VPN? Sprawdź trzech właścicieli
Pozostały adapter, filtr lub trasa mogą przeżyć klienta. Sprawdź trzech właścicieli, usuń najwęższy obiekt, a następnie ponownie przetestuj dostęp bezpośredni i tunelowy.
Klient zniknął, a maszyna nadal donikąd nie dociera, co kusi, by wyrównać zaporę i zacząć od nowa. Nie rób tego. Stan blokady może pochodzić od trzech różnych właścicieli na tej samej maszynie, a każdy ma własną ścieżkę usuwania. Wylanie wszystkiego naraz usuwa obiekt, którego chciałeś się pozbyć, wraz z ochroną, której nadal potrzebujesz, i niszczy dowód, który właściciel spowodował problem. Pięć kontroli, po kolei, temu zapobiega.
Kontrola 1: co jeszcze jest i do czego służy
Szukaj trzech artefaktów osobno: adaptera wirtualnego, który nadal istnieje, filtra lub reguły zapory, która nadal blokuje, oraz trasy lub reguły zasad, która nadal wskazuje tunel, którego już nie ma. Ich obecność sama w sobie niczego nie dowodzi, ponieważ celowy wyłącznik awaryjny wygląda z zewnątrz tak samo jak porzucony.
Get-NetAdapter | Where-Object Status -eq 'Up'
Get-NetFirewallRule -Enabled True -Direction Outbound | Where-Object Action -eq 'Block'
ip route show
ip -4 rule show
Zapisz czas, w którym łączność ustała, oraz czy normalny klient nadal może uruchomić swój tunel. Jeśli klient może przywrócić tunel i ruch wraca, blokada wykonuje swoją pracę, a problem leży w stanie klienta, nie w pozostałej regule.
Kontrola 2: który właściciel to kontroluje
Każdy artefakt ma właściciela. Adapter wirtualny należy do klienta VPN lub jego sterownika. Filtr może należeć do klienta, do zapory platformy lub do zarządzanego produktu bezpieczeństwa. Trasa mogła zostać zainstalowana przez klienta przy połączeniu i pozostawiona.
Na zarządzanym sprzęcie sprawdź zasady urządzenia, zanim czegokolwiek dotkniesz. Filtr wymuszony przez zasady zostanie przywrócony przy następnym zameldowaniu, więc lokalne usunięcie kupuje godzinę i raport zgodności. Ta rozmowa należy do administratora, nie do interfejsu zapory.
Kontrola 3: usuń najwęższą rzecz, która to wyjaśnia
Zacznij od ścieżki obsługiwanej przez dostawcę: instalacja naprawcza lub prawidłowe odinstalowanie często poprawnie czyści wygenerowany stan, w tym filtry, które ręczne usunięcie by pominęło. Przeczytaj instrukcje odzyskiwania dla zainstalowanej wersji, ponieważ kolejność ma znaczenie, a odinstalowanie po nieudanym usunięciu zachowuje się inaczej.
Jeśli ręczna inspekcja jest naprawdę konieczna, zapisz nazwę reguły, interfejs i podany cel, zanim cokolwiek zmienisz, i usuń ten obiekt po nazwie. Usuwanie każdego adaptera sieciowego lub wylanie całego zestawu reguł, by trafić w jednego klienta, to droga, na której sprawa wsparcia staje się przebudową.
Kontrola 4: DNS i trasy przeżywają adaptery
Stan rozwiązywania może przeżyć tunel. Resolver, który nadal wskazuje adres wewnątrz tunelu, którego już nie ma, generuje limity czasu wyglądające dokładnie jak odrzucenie przez zaporę, a zwykły wniosek jest błędny.
resolvectl status
ip route get 1.1.1.1
nslookup example.com
Jeśli adres się rozwiązuje i surowe połączenie przez IP działa, DNS jest pozostałym problemem, a nie filtrowanie. Jeśli oba zawodzą, wróć do kontroli pierwszej z trasą i filtrem w ręku.
Kontrola 5: przetestuj obie ścieżki i przywróć diagnostykę
Najpierw sprawdź zwykłą łączność, potem każdy pozostały profil VPN przez jego własne mechanizmy: połącz, użyj, rozłącz i potwierdź, że host wrócił do zwykłej łączności. Ten obieg jest testem, który dowodzi, że porzucona blokada zniknęła, a nie została tylko ominięta.
Na koniec przywróć wszelkie zmiany diagnostyczne wykonane po drodze. Skuteczne czyszczenie usuwa jedną porzuconą zależność; nie usuwa ogólnej ochrony hosta i nie powinno zostawiać trwale poluzowanej zapory. Zanotuj, który właściciel trzymał blokadę, ponieważ następne odinstalowanie da tych samych trzech kandydatów.