nordvpn dice que no puede llegar al demonio: ¿socket, grupo o unidad?

Ejecutar nordvpn y recibir un mensaje sobre un demonio inalcanzable es una queja estrecha que suele llegar cuando ya vas tarde. No dice nada sobre si el túnel funciona, porque la CLI solo es una interfaz: habla con un proceso en segundo plano a través de un socket de Unix, y el mensaje significa que esa conversación no ocurrió. Camina desde el comando hacia fuera y detente en la primera cosa que resulte falsa.

Empieza donde aparece el error

Hay dos procesos implicados, y confundirlos es lo que hace que esto parezca misterioso. El demonio posee el túnel y escucha en un socket bajo /run/nordvpn/. El comando que escribiste se conecta a ese socket en lugar de tocar las interfaces por sí mismo.

Cuando el socket falta o rechaza la conexión, la CLI no tiene a quién preguntar, así que informa de la variante «demonio de usuario» o «demonio de sistema» de la misma queja. Una de esas variantes nombra la ruta directamente, y es la frase más útil de todo el intercambio.

Comprueba la unidad antes que nada

Pregunta al gestor de servicios si el demonio se está ejecutando y, si no, inícialo y habilítalo en un solo paso:

systemctl status nordvpnd
sudo systemctl enable --now nordvpnd
nordvpn version

Si la unidad existe pero está inactiva, enable --now la inicia y prepara el siguiente arranque a la vez. Si la unidad no existe, el paquete no es el que supones, y el nombre instalado importa más que el nombre de tus notas. Eso suena a distinción pedante hasta que pasas veinte minutos habilitando un servicio que nunca se instaló con esa etiqueta. Lee lo que hay y actúa en consecuencia.

Listar los archivos de unidad lo resuelve con un solo comando, y vale la pena hacerlo antes de concluir nada sobre la instalación:

systemctl list-unit-files 'nordvpn*'
service --status-all

Las versiones han enviado el servicio bajo más de un nombre de unidad, así que una compilación que usa nordvpn en lugar de nordvpnd producirá una copia perfecta de este error mientras un servicio sano se ejecuta justo al lado.

El socket y su grupo deciden el acceso

Incluso con el demonio en marcha, la conexión puede rechazarse por permisos. El instalador crea un grupo nordvpn, y el socket es propiedad en consecuencia, así que un usuario fuera de ese grupo queda denegado mientras el servicio está perfectamente sano.

sudo usermod -aG nordvpn "$USER"
newgrp nordvpn

La pertenencia al grupo se lee cuando empieza una sesión, y por eso el cambio parece no funcionar en la terminal donde lo hiciste. Hace falta un shell de inicio de sesión nuevo o newgrp antes de que la sesión en curso vea el grupo nuevo. Prueba en un shell nuevo, no en el que acaba de ejecutar el comando. Si no, concluirás que el arreglo falló cuando en realidad aún no se ha aplicado.

La propiedad del socket en sí es la segunda mitad de esa comprobación. Compara el grupo del socket con los grupos que informa el shell que ejecuta la CLI, y la cuestión de los permisos queda respondida en un paso en lugar de reinstalando:

ls -l /run/nordvpn
id

Un proceso vivo no es prueba del socket correcto. Un demonio lanzado por otro gestor, o un paquete antiguo que vinculó un socket con otro nombre, informan igual. El listado del directorio distingue esos casos en una línea, y por eso supera a la reinstalación.

El proceso por usuario en empaquetados antiguos

Algunos empaquetados ejecutan un segundo proceso en el contexto del usuario conectado, que la integración de escritorio espera encontrar. Si un script de inicio del sistema lo lanza sin bajar a esa cuenta, la CLI busca un demonio que ninguna sesión posee.

En un init que no es systemd, la disposición documentada reparte los papeles: el servicio del sistema se ejecuta bajo un nombre y el proceso del lado del usuario bajo la cuenta objetivo con chpst -u <user>. Comprueba qué disposición usa realmente tu instalación antes de añadir un script de arranque que presuponga la otra.

Cómo saber que has terminado

La actualización es el desencadenante habitual, porque el binario nuevo espera un estado del servicio que el viejo nunca dejó. Detener, volver a habilitar y arrancar en ese orden lo limpia:

sudo systemctl stop nordvpnd
sudo systemctl enable --now nordvpnd
sudo systemctl start nordvpnd
nordvpn version

Ese último comando es la prueba de aceptación. Una versión impresa significa que el socket responde, lo que mueve cualquier fallo restante al terreno del inicio de sesión, el plan o la conectividad y lo saca de este artículo. Si responde, deja de leer aquí y ve a mirar la cuenta.

Si el socket sigue faltando, lee el registro de la unidad para ver por qué terminó, y luego comprueba que /run/nordvpn existe y que la cuenta del servicio puede escribir allí. Un proceso que arranca y muere de inmediato registra su motivo en ese registro, y una línea se lee más rápido de lo que se realiza una reinstalación.