Ubuntu n’a plus d’internet après la suppression d’une application VPN

Désinstaller le client VPN, redémarrer, puis constater que le navigateur ne charge rien est une séquence courante sur Ubuntu. Le tunnel a disparu, mais pas la politique qui y dirigeait le trafic, et sur Ubuntu ces restes vivent généralement dans NetworkManager plutôt que dans le paquet. Un profil de connexion et une interface factice créés à l’exécution n’appartiennent à aucun paquet, donc supprimer le paquet ne les supprime pas.

Le tunnel a disparu, pas la politique

Un kill switch fonctionne en rendant le réseau inutilisable sans le tunnel. Quand le client est retiré alors que cet état est actif, il ne reste rien pour le désactiver. Le résultat ressemble exactement à une carte réseau cassée et c’est généralement un profil qui retient une route.

C’est pourquoi une réinstallation rétablit parfois la connectivité : elle recrée le processus qui sait défaire sa propre politique. Un client retiré alors que son commutateur était actif a laissé un état que plus personne ne nettoie.

Lisez les objets que le paquet n’a jamais possédés

Lisez l’état avant de le modifier. Listez les périphériques, les connexions actives et les deux tables de routage, puis cherchez un périphérique factice qui se déclare connecté ou une route par défaut qui pointe vers un. IPv4 et IPv6 échouent séparément, donc un ping qui fonctionne vers une adresse dont la résolution de noms est cassée pointe vers un autre objet qu’une route morte. Un périphérique factice retenant une route par défaut explique toute la panne à lui seul.

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

Notez ce que vous trouvez, car le correctif est de supprimer un objet précis plutôt que de tout réinitialiser. Tout ce qui est plus large risque une seconde panne. C’est la différence entre une réparation et une supposition.

Une table de routage vide avec un périphérique connecté est une autre panne, et elle pointe vers DHCP plutôt que vers un profil résiduel. Lisez le bail avant de modifier quoi que ce soit.

Supprimez le profil, pas le fichier de clé

Supprimez le profil via NetworkManager plutôt que de retirer le fichier de clé. Supprimer le fichier laisse le profil en mémoire actif jusqu’au prochain redémarrage, ce qui rend une réparation correcte peu fiable. Redémarrez ensuite le service et relisez la liste des périphériques. C’est le redémarrage qui rend la suppression réelle.

sudo nmcli connection delete pvpn-killswitch
sudo systemctl restart NetworkManager

Si un lien factice survit, retirez aussi ce lien, puis testez une adresse et un nom séparément. Un routage propre avec un nom en échec pointe vers DNS, tandis qu’une adresse en échec pointe vers une route ou un pare-feu.

Vérifiez le crochet de démarrage avant qu’il ne se répète

Certains restes se réinstallent à chaque démarrage. Une unité écrite à la main ou un script if-up qui ajoute des règles de pare-feu continue après la disparition du paquet, si bien que la panne revient et que la réparation précédente ressemble à de la chance. Cherchez dans les fichiers d’unité et les crochets réseau avant de redémarrer à nouveau. Le nom de l’unité est généralement l’indice.

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

Supprimez ou masquez le fichier précis, redémarrez une fois et confirmez que l’état sans tunnel est celui que vous voulez. Ce dernier redémarrage est le test, car un correctif qui ne tient que jusqu’au prochain démarrage n’est pas un correctif. Gardez la note avec la machine ensuite. La référence nmcli couvre les commandes de périphérique et de connexion utilisées plus haut.