Ubuntu hat kein Internet mehr nach dem Entfernen einer VPN-App

Den VPN-Client zu deinstallieren, neu zu starten und dann festzustellen, dass der Browser nichts laden kann, ist eine häufige Abfolge unter Ubuntu. Der Tunnel ist weg, die Regel, die den Datenverkehr auf ihn lenkte, aber nicht, und unter Ubuntu leben diese Reste meist im NetworkManager und nicht im Paket. Ein Verbindungsprofil und eine zur Laufzeit erzeugte Dummy-Schnittstelle gehören zu keinem Paket, deshalb entfernt das Entfernen des Pakets sie nicht.

Der Tunnel ist weg, die Regel nicht

Ein Kill-Switch funktioniert, indem er das Netzwerk ohne den Tunnel unbrauchbar macht. Wird der Client entfernt, während dieser Zustand aktiv ist, bleibt nichts übrig, was ihn abschalten könnte. Das Ergebnis sieht genau wie ein defekter Netzwerkadapter aus und ist meist ein Profil, das eine Route hält.

Darum stellt eine Neuinstallation manchmal die Verbindung wieder her: Sie erzeugt den Prozess neu, der seine eigene Regel zurücknehmen kann. Ein Client, der entfernt wurde, während sein Schalter aktiv war, hinterließ einen Zustand, den niemand mehr aufräumt.

Lesen Sie die Objekte, die das Paket nie besaß

Lesen Sie den Zustand, bevor Sie ihn ändern. Listen Sie Geräte, aktive Verbindungen und beide Routing-Tabellen auf, und suchen Sie dann ein Dummy-Gerät, das sich als verbunden meldet, oder eine Standardroute, die darauf zeigt. IPv4 und IPv6 fallen getrennt aus, deshalb deutet ein funktionierender Ping auf eine Adresse mit kaputter Namensauflösung auf ein anderes Objekt als eine tote Route. Ein Dummy-Gerät mit einer Standardroute erklärt den ganzen Ausfall für sich allein.

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

Notieren Sie, was Sie finden, denn die Reparatur besteht darin, ein bestimmtes Objekt zu löschen statt alles zurückzusetzen. Alles Breitere riskiert einen zweiten Ausfall. Das ist der Unterschied zwischen einer Reparatur und einer Vermutung.

Eine leere Routing-Tabelle mit einem verbundenen Gerät ist ein anderer Fehler, und er deutet auf DHCP statt auf ein zurückgebliebenes Profil. Lesen Sie das Lease, bevor Sie irgendetwas bearbeiten.

Löschen Sie das Profil, nicht die Schlüsseldatei

Löschen Sie das Profil über den NetworkManager, statt die Schlüsseldatei zu entfernen. Das Löschen der Datei lässt das Profil im Speicher bis zum nächsten Neustart aktiv, was eine korrekte Reparatur unzuverlässig aussehen lässt. Starten Sie dann den Dienst neu und lesen Sie die Geräteliste erneut. Der Neustart ist es, der die Löschung wirklich macht.

sudo nmcli connection delete pvpn-killswitch
sudo systemctl restart NetworkManager

Überlebt ein Dummy-Link, entfernen Sie auch diesen Link und testen Sie danach eine Adresse und einen Namen getrennt. Sauberes Routing mit einem fehlgeschlagenen Namen deutet auf DNS, während eine fehlgeschlagene Adresse auf eine Route oder eine Firewall deutet.

Prüfen Sie den Start-Hook, bevor er sich wiederholt

Manche Reste installieren sich bei jedem Start neu. Eine handgeschriebene Unit oder ein if-up-Skript, das Firewall-Regeln hinzufügt, tut das auch weiter, nachdem das Paket weg ist, sodass der Ausfall zurückkehrt und die frühere Reparatur wie Glück aussieht. Durchsuchen Sie die Unit-Dateien und die Netzwerk-Hooks, bevor Sie erneut starten. Der Unit-Name ist meist der Hinweis.

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

Entfernen oder maskieren Sie die konkrete Datei, starten Sie dann einmal neu und bestätigen Sie, dass der Zustand ohne Tunnel der gewünschte ist. Dieser letzte Neustart ist der Test, denn eine Reparatur, die nur bis zum nächsten Start hält, ist keine Reparatur. Bewahren Sie die Notiz danach beim Rechner auf. nmcli-Referenz deckt die oben verwendeten Geräte- und Verbindungsbefehle ab.