Ubuntu har inget internet efter att en VPN-app tagits bort

Att avinstallera VPN-klienten, starta om och sedan upptäcka att webbläsaren inte kan ladda något är en vanlig följd på Ubuntu. Tunneln är borta, men regeln som skickade trafiken dit är inte det, och på Ubuntu bor dessa rester oftast i NetworkManager och inte i paketet. En anslutningsprofil och ett dummy-gränssnitt som skapas under körning tillhör inget paket, så borttagningen av paketet tar inte bort dem.

Tunneln är borta, regeln inte

En kill switch fungerar genom att göra nätverket oanvändbart utan tunneln. När klienten tas bort medan det tillståndet är aktivt finns inget kvar som stänger av det. Resultatet ser exakt ut som ett trasigt nätverkskort och är oftast en profil som håller en rutt.

Därför återställer en ominstallation ibland anslutningen: den återskapar processen som vet hur den ska dra tillbaka sin egen regel. En klient som togs bort medan dess strömbrytare var aktiv lämnade ett tillstånd som ingen finns kvar att städa.

Läs objekten som paketet aldrig ägde

Läs tillståndet innan du ändrar det. Lista enheter, aktiva anslutningar och båda routingtabellerna och leta sedan efter en dummy-enhet som rapporterar sig ansluten eller en standardrutt som pekar på en. IPv4 och IPv6 faller separat, så en ping som fungerar till en adress med trasig namnmatchning pekar på ett annat objekt än en död rutt. En dummy-enhet med en standardrutt förklarar hela avbrottet på egen hand.

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

Skriv ner vad du hittar, eftersom åtgärden är att radera ett specifikt objekt i stället för att återställa allt. Allt bredare riskerar ett andra avbrott. Det är skillnaden mellan en reparation och en gissning.

En tom routingtabell med en ansluten enhet är ett annat fel, och den pekar på DHCP och inte på en kvarvarande profil. Läs leasen innan du redigerar något.

Radera profilen, inte nyckelfilen

Radera profilen via NetworkManager i stället för att ta bort nyckelfilen. Att radera filen lämnar profilen i minnet aktiv till nästa omstart, vilket får en korrekt reparation att verka opålitlig. Starta sedan om tjänsten och läs enhetslistan igen. Det är omstarten som gör raderingen verklig.

sudo nmcli connection delete pvpn-killswitch
sudo systemctl restart NetworkManager

Om en dummy-länk överlever, ta bort den länken också och testa sedan en adress och ett namn var för sig. Ren routing med ett misslyckat namn pekar på DNS, medan en misslyckad adress pekar på en rutt eller en brandvägg.

Kontrollera uppstarts-hooken innan den upprepas

Vissa rester installerar om sig själva vid varje uppstart. En handskriven unit eller ett if-up-skript som lägger till brandväggsregler fortsätter med det även efter att paketet är borta, så avbrottet återkommer och den tidigare reparationen ser ut som tur. Sök i unit-filerna och nätverkshookarna innan du startar om igen. Unit-namnet är oftast det som avslöjar det.

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

Ta bort eller maskera den specifika filen, starta sedan om en gång och bekräfta att tillståndet utan tunnel är det du vill ha. Den sista omstarten är testet, eftersom en rättelse som bara håller till nästa uppstart inte är en rättelse. Behåll anteckningen med maskinen efteråt. nmcli-referensen täcker enhets- och anslutningskommandona som använts ovan.