Comece polo que informa o terminal, non polo instalador. Un cliente VPN de provedor pode fallar porque o seu servizo en segundo plano non se executa, porque o paquete rompeu contra unha distribución máis nova, porque cambiou o fluxo de inicio de sesión ou porque un perfil de conexión antigo segue activo. Cada caso deixa un rastro distinto, e reinstalar arranxa como moito un deles. Percorra as comprobacións en orde e detéñase cando as probas apunten a unha capa.

Comece polo servizo, non polo instalador

Lea primeiro o estado da unidade: systemctl status nordvpnd indica se o daemon se executa e se se reiniciou hai pouco. Unha mensaxe de permiso de socket como Permission denied accessing /run/nordvpn/nordvpnd.sock trata da pertenza ao grupo, non do túnel. Engada a conta ao grupo do provedor, logo peche por completo a sesión de escritorio e volva entrar. Un terminal novo conserva a lista antiga de grupos, así que id é a única confirmación rápida de que o cambio se aplicou.

Cando o daemon está san pero o cliente o ignora, o paquete é o sospeitoso máis probable. Unha entrada gráfica que non fai nada e un comando que sae en silencio son síntomas a nivel de paquete. Tras unha actualización da distribución, un xestor do provedor escrito en Python pode fallar contra unha API de biblioteca eliminada, así que compare a compilación instalada co que o provedor entrega agora antes de borrar nada.

Escolla a ruta de inicio de sesión que ofrece a compilación

As instrucións de inicio de sesión do ano pasado poden describir unha opción que xa non existe. Nas compilacións actuais, nordvpn login --legacy devolve flag provided but not defined: -legacy, e as dúas rutas admitidas son un token do portal e unha chamada de volta do navegador. Para a ruta do token, xéreo na páxina da conta e pásao unha vez: nordvpn login --token <token>. Para a ruta da chamada de volta, copie o enderezo de éxito, cambie https:// por nordvpn:// e entrecomille o resultado cando llo entregue a nordvpn login --callback.

Ambos os valores son credenciais. Un token sen caducidade é cómodo nunha máquina sen pantalla e caro no historial da consola, así que bórreo despois de usalo e mantéñao fóra dos paquetes de soporte.

Desinstale por completo, repositorio incluído

A eliminación ten tres partes: o paquete, a fonte de apt e a pertenza ao grupo. Purga só o paquete deixa un repositorio que segue respondendo a apt update, e un grupo obsoleto que segue concedendo acceso a un socket que ninguén debería posuír. Se o cliente veu dun .deb descargado, resolva primeiro o nome exacto do paquete con dpkg -l | grep -i nordvpn, porque adiviñar produce unha purga que non elimina nada.

Conserve as instrucións de desinstalación do propio provedor se existen, e anote o que eliminou para que unha reinstalación posterior non herde en silencio media configuración.

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

Elimine os perfís que a desinstalación esqueceu

NetworkManager garda as conexións no seu propio almacén, e un cliente que escribiu unha durante a configuración pode deixala activa moito despois da eliminación. O culpable coñecido é pvpn-ipv6leak-protection. Enumere con nmcli connection show e nmcli connection show --active, anote o UUID e borre por ese identificador para non eliminar un perfil activo. Se a entrada reaparece tras un reinicio, borre o seu ficheiro de clave en /etc/NetworkManager/system-connections/ e reinicie NetworkManager.

Non baleire ese directorio. Outros VPN e perfís por cable correntes viven alí tamén, e unha limpeza que os elimina crea unha segunda caída. As entradas gardadas por outros provedores merecen a mesma cautela: un perfil de servidor gardado non é un daemon en marcha, e eliminalo é unha decisión de configuración, non unha corrección de erro.

Iniciar sesión non é o mesmo que un túnel que funciona

Un inicio de sesión correcto só demostra que a conta se autenticou. Se o túnel arrinca pero os nomes deixan de resolverse, inspeccione a tecnoloxía que escolleu o cliente e o estado do resolvedor antes de cambiar a conta. Algunhas compilacións expoñen unha segunda ruta de datos, e pasar a ela é a solución documentada cando a máis nova falla ao arrincar.

O tráfico que só se rompe mentres está conectado apunta a un interruptor de emerxencia ou a un perfil de protección contra fugas sobrante, non a outro inicio de sesión. Os dispositivos locais necesitan unha ollada aparte: unha impresora ou un servidor de ficheiros que desaparece durante a sesión adoita quedar bloqueado pola lista de excepcións de LAN do provedor, non polo router.

Artigos relacionados