NordVPN sous Ubuntu : démon, connexion et suppression propre

Commencez par ce que le terminal signale, pas par l'installateur. Un client VPN d'un fournisseur peut échouer parce que son service d'arrière-plan ne tourne pas, parce que le paquet s'est cassé face à une distribution plus récente, parce que le flux de connexion a changé ou parce qu'un ancien profil de connexion est toujours actif. Chaque cas laisse une trace différente, et une réinstallation n'en corrige qu'un au plus. Parcourez les vérifications dans l'ordre et arrêtez-vous quand les preuves désignent une couche.

Commencez par le service, pas par l'installateur

Lisez d'abord l'état de l'unité : systemctl status nordvpnd vous dit si le démon tourne et s'il a été redémarré récemment. Un message de permission de socket comme Permission denied accessing /run/nordvpn/nordvpnd.sock concerne l'appartenance au groupe, pas le tunnel. Ajoutez le compte au groupe du fournisseur, puis déconnectez-vous complètement de la session de bureau et reconnectez-vous. Un nouveau terminal conserve l'ancienne liste de groupes, donc id est la seule confirmation rapide que le changement a été appliqué.

Quand le démon est sain mais que le client vous ignore, le paquet est le meilleur suspect. Une entrée graphique qui ne fait rien et une commande qui sort silencieusement sont des symptômes au niveau du paquet. Après une mise à niveau de distribution, un gestionnaire du fournisseur écrit en Python peut échouer face à une API de bibliothèque supprimée, alors comparez la version installée avec ce que le fournisseur livre actuellement avant de purger quoi que ce soit.

Choisissez le chemin de connexion que la version propose

Les instructions de connexion de l'an dernier peuvent décrire un indicateur qui n'existe plus. Sur les versions actuelles, nordvpn login --legacy renvoie flag provided but not defined: -legacy, et les deux chemins pris en charge sont un jeton de portail et un retour d'appel du navigateur. Pour le chemin du jeton, générez-le sur la page du compte et transmettez-le une fois : nordvpn login --token <token>. Pour le chemin du retour d'appel, copiez l'adresse de succès, remplacez https:// par nordvpn:// et mettez le résultat entre guillemets quand vous le donnez à nordvpn login --callback.

Les deux valeurs sont des identifiants. Un jeton sans expiration est pratique sur une machine sans écran et coûteux dans l'historique du shell, alors effacez-le après usage et gardez-le hors des paquets de support.

Désinstallez complètement, dépôt compris

La suppression comporte trois parties : le paquet, la source apt et l'appartenance au groupe. Purger seulement le paquet laisse un dépôt qui continue de répondre à apt update, et un groupe obsolète qui continue d'accorder l'accès à un socket que personne ne devrait posséder. Si le client vient d'un .deb téléchargé, résolvez d'abord le nom exact du paquet avec dpkg -l | grep -i nordvpn, car deviner produit une purge qui n'enlève rien.

Conservez les instructions de désinstallation du fournisseur si elles existent, et notez ce que vous avez supprimé pour qu'une réinstallation ultérieure n'hérite pas silencieusement de la moitié d'une configuration.

sudo apt purge nordvpn
sudo rm /etc/apt/sources.list.d/nordvpn.list
sudo gpasswd -d "$USER" nordvpn

Supprimez les profils oubliés par la désinstallation

NetworkManager conserve les connexions dans son propre magasin, et un client qui en a écrit une pendant l'installation peut la laisser active longtemps après la suppression. Le coupable connu est pvpn-ipv6leak-protection. Énumérez avec nmcli connection show et nmcli connection show --active, notez l'UUID et supprimez par cet identifiant pour ne pas retirer un profil actif. Si l'entrée réapparaît après un redémarrage, supprimez son fichier de clé sous /etc/NetworkManager/system-connections/ et redémarrez NetworkManager.

Ne videz pas ce répertoire. D'autres VPN et des profils filaires ordinaires y vivent aussi, et un nettoyage qui les supprime crée une seconde panne. Les entrées enregistrées par d'autres fournisseurs méritent la même prudence : un profil de serveur enregistré n'est pas un démon en cours d'exécution, et le supprimer est une décision de configuration, pas une correction de bug.

La connexion n'est pas la même chose qu'un tunnel qui fonctionne

Une connexion réussie prouve seulement que le compte s'est authentifié. Si le tunnel démarre mais que les noms cessent d'être résolus, inspectez la technologie choisie par le client et l'état du résolveur avant de changer de compte. Certaines versions exposent un second chemin de données, et y basculer est le contournement documenté quand le plus récent refuse de démarrer.

Le trafic qui ne casse que pendant la connexion désigne un coupe-circuit ou un profil de protection contre les fuites resté en place, pas une autre connexion. Les appareils locaux demandent un regard séparé : une imprimante ou un serveur de fichiers qui disparaît pendant la session est généralement bloqué par la liste d'exceptions LAN du fournisseur, pas par le routeur.