NordVPN su Ubuntu: demone, accesso e rimozione pulita

Iniziate da ciò che riporta il terminale, non dal programma di installazione. Un client VPN di un fornitore può fallire perché il suo servizio in background non è in esecuzione, perché il pacchetto si è rotto rispetto a una distribuzione più recente, perché il flusso di accesso è cambiato o perché un vecchio profilo di connessione è ancora attivo. Ogni caso lascia una traccia diversa, e reinstallare ne corregge al massimo uno. Percorrete i controlli in ordine e fermatevi quando le prove indicano uno strato.

Iniziate dal servizio, non dal programma di installazione

Leggete prima lo stato dell'unità: systemctl status nordvpnd indica se il demone è in esecuzione e se è stato riavviato di recente. Un messaggio di autorizzazione del socket come Permission denied accessing /run/nordvpn/nordvpnd.sock riguarda l'appartenenza al gruppo, non il tunnel. Aggiungete l'account al gruppo del fornitore, poi disconnettetevi completamente dalla sessione desktop e rientrate. Un terminale nuovo conserva il vecchio elenco dei gruppi, quindi id è l'unica conferma rapida che la modifica è stata applicata.

Quando il demone è sano ma il client vi ignora, il pacchetto è il sospetto migliore. Una voce grafica che non fa nulla e un comando che esce in silenzio sono sintomi a livello di pacchetto. Dopo un aggiornamento della distribuzione, un gestore del fornitore scritto in Python può fallire contro un'API di libreria rimossa, quindi confrontate la build installata con ciò che il fornitore distribuisce ora prima di cancellare qualsiasi cosa.

Scegliete il percorso di accesso che la build offre

Le istruzioni di accesso dell'anno scorso possono descrivere un flag che non esiste più. Nelle build attuali, nordvpn login --legacy restituisce flag provided but not defined: -legacy, e i due percorsi supportati sono un token del portale e un callback del browser. Per il percorso del token, generatelo nella pagina dell'account e passatelo una volta: nordvpn login --token <token>. Per il percorso del callback, copiate l'indirizzo di successo, sostituite https:// con nordvpn:// e mettete il risultato tra virgolette quando lo consegnate a nordvpn login --callback.

Entrambi i valori sono credenziali. Un token senza scadenza è comodo su una macchina senza schermo e costoso nella cronologia della shell, quindi cancellatelo dopo l'uso e tenetelo fuori dai pacchetti di supporto.

Disinstallate completamente, repository incluso

La rimozione ha tre parti: il pacchetto, la fonte apt e l'appartenenza al gruppo. Purificare solo il pacchetto lascia un repository che continua a rispondere a apt update, e un gruppo obsoleto che continua a concedere l'accesso a un socket che nessuno dovrebbe possedere. Se il client proviene da un .deb scaricato, risolvete prima il nome esatto del pacchetto con dpkg -l | grep -i nordvpn, perché indovinare produce una purga che non rimuove nulla.

Conservate le istruzioni di disinstallazione del fornitore se esistono, e annotate ciò che avete rimosso così che una reinstallazione successiva non erediti silenziosamente mezza configurazione.

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

Rimuovete i profili dimenticati dalla disinstallazione

NetworkManager conserva le connessioni nel proprio archivio, e un client che ne ha scritta una durante la configurazione può lasciarla attiva molto dopo la rimozione. Il colpevole noto è pvpn-ipv6leak-protection. Elencate con nmcli connection show e nmcli connection show --active, annotate l'UUID ed eliminate per quell'identificatore per non rimuovere un profilo vivo. Se la voce riappare dopo un riavvio, eliminate il suo file di chiave sotto /etc/NetworkManager/system-connections/ e riavviate NetworkManager.

Non svuotate quella directory. Altri VPN e profili cablati comuni vivono lì, e una pulizia che li rimuove crea un secondo disservizio. Le voci salvate da altri fornitori meritano la stessa cautela: un profilo server salvato non è un demone in esecuzione, e eliminarlo è una decisione di configurazione, non una correzione di bug.

L'accesso non è la stessa cosa di un tunnel funzionante

Un accesso riuscito prova solo che l'account è stato autenticato. Se il tunnel parte ma i nomi smettono di risolversi, ispezionate la tecnologia scelta dal client e lo stato del resolver prima di cambiare l'account. Alcune build espongono un secondo percorso dati, e passare a quello è la soluzione documentata quando il più recente non riesce ad avviarsi.

Il traffico che si rompe solo mentre siete connessi indica un kill switch o un profilo di protezione dalle fughe rimasto, non un altro accesso. I dispositivi locali richiedono uno sguardo separato: una stampante o un file server che scompare durante la sessione di solito è bloccato dall'elenco delle eccezioni LAN del fornitore, non dal router.