Ubuntu nie ma internetu po usunięciu aplikacji VPN

Odinstalowanie klienta VPN, ponowne uruchomienie i odkrycie, że przeglądarka nic nie ładuje, to częsta sekwencja w Ubuntu. Tunel zniknął, ale reguła, która kierowała do niego ruch, nie, a w Ubuntu te resztki zwykle mieszkają w NetworkManagerze, a nie w pakiecie. Profil połączenia i fikcyjny interfejs utworzone w czasie działania nie należą do żadnego pakietu, więc usunięcie pakietu ich nie usuwa.

Tunel zniknął, reguła nie

Kill switch działa tak, że bez tunelu czyni sieć bezużyteczną. Gdy klient zostanie usunięty, podczas gdy ten stan jest aktywny, nie zostaje nic, co by go wyłączyło. Wynik wygląda dokładnie jak zepsuta karta sieciowa i zwykle jest to profil trzymający trasę.

Dlatego ponowna instalacja czasem przywraca łączność: odtwarza proces, który umie wycofać własną regułę. Klient usunięty przy aktywnym przełączniku zostawił stan, którego nie ma już komu posprzątać.

Przeczytaj obiekty, których pakiet nigdy nie posiadał

Przeczytaj stan, zanim go zmienisz. Wypisz urządzenia, aktywne połączenia i obie tablice routingu, a potem szukaj fikcyjnego urządzenia, które zgłasza połączenie, albo trasy domyślnej wskazującej na nie. IPv4 i IPv6 zawodzą osobno, więc działający ping do adresu z zepsutym rozwiązywaniem nazw wskazuje inny obiekt niż martwa trasa. Fikcyjne urządzenie trzymające trasę domyślną samo wyjaśnia całą awarię.

nmcli device status
nmcli connection show --active
ip -4 route
ip -6 route

Zapisz, co znajdziesz, bo naprawa polega na usunięciu jednego konkretnego obiektu a nie na zresetowaniu wszystkiego. Cokolwiek szerszego ryzykuje drugą awarię. To różnica między naprawą a domysłem.

Pusta tablica routingu z podłączonym urządzeniem to inna usterka i wskazuje na DHCP, a nie na pozostały profil. Przeczytaj dzierżawę, zanim cokolwiek zmienisz.

Usuń profil, nie plik klucza

Usuń profil przez NetworkManager, zamiast usuwać plik klucza. Usunięcie pliku zostawia profil w pamięci aktywny do następnego restartu, co sprawia, że poprawna naprawa wygląda na zawodną. Potem zrestartuj usługę i ponownie odczytaj listę urządzeń. To restart czyni usunięcie rzeczywistym.

sudo nmcli connection delete pvpn-killswitch
sudo systemctl restart NetworkManager

Jeśli fikcyjne łącze przetrwa, usuń także to łącze, a potem przetestuj adres i nazwę osobno. Czysty routing z nieudaną nazwą wskazuje na DNS, a nieudany adres na trasę lub zaporę.

Sprawdź hak startowy, zanim się powtórzy

Niektóre resztki instalują się ponownie przy każdym starcie. Ręcznie napisana jednostka lub skrypt if-up dodający reguły zapory robi to dalej po zniknięciu pakietu, więc awaria wraca, a wcześniejsza naprawa wygląda na szczęście. Przeszukaj pliki jednostek i haki sieciowe, zanim zrestartujesz ponownie. Nazwa jednostki zwykle to zdradza.

systemctl list-unit-files | grep -i vpn
grep -rl -i vpn /etc/systemd/system /etc/network/if-up.d

Usuń lub zamaskuj konkretny plik, potem raz zrestartuj i potwierdź, że stan bez tunelu jest tym, którego chcesz. Ten ostatni restart jest testem, bo naprawa, która trzyma tylko do następnego startu, nie jest naprawą. Potem trzymaj notatkę przy maszynie. Dokumentacja nmcli obejmuje użyte powyżej polecenia urządzeń i połączeń.