NordVPN en Linux bloquea la LAN: lista de permitidos y DNS

Todo parece normal hasta que intentas llegar a algo en tu propio escritorio. El túnel está activo, las páginas cargan y la unidad de red agota el tiempo de espera. Desconecta y la unidad vuelve antes de que termines la frase, lo que te dice más que cualquier registro: el cliente rechaza a propósito el tráfico que no entra en el túnel, y tu red local está en el lado equivocado de esa línea.

El interruptor de seguridad hace su trabajo

Un interruptor de seguridad existe para evitar que el tráfico escape cuando el túnel no está disponible. Los rangos de direcciones privadas cuentan como tráfico que no entra en el túnel, así que una implementación estricta los bloquea junto con todo lo demás. Eso no es un fallo en el sentido que la gente quiere decir cuando presenta el informe.

Lee primero la visión del propio cliente. Un comando imprime la configuración actual y otro muestra los objetos de cortafuegos que el cliente creó. Buscas un descarte o un rechazo que aparezca antes de cualquier excepción del túnel, porque es ese orden el que hace inalcanzable la red local.

nordvpn settings
sudo nft list ruleset
sudo iptables -S

Después ejecuta una prueba que parta el problema en dos. Llega al dispositivo por dirección y luego por nombre. Que la dirección funcione y el nombre falle significa que el cortafuegos es inocente y el resolutor no. Que fallen ambos significa que el cortafuegos rechaza el paquete, y el resto de este artículo se aplica.

Lista de permitidos: elige el tipo de entrada según el síntoma

El cliente ofrece una lista de permitidos con tres tipos de entrada, y elegir el tipo correcto es la mayor parte del trabajo. Una subred cubre hosts. Un puerto cubre un servicio independientemente del destino. Un grupo de multidifusión cubre el tráfico de descubrimiento, que es una forma de tráfico distinta de cualquier cosa dirigida a un solo host.

nordvpn allowlist add subnet 192.168.1.0/24
nordvpn allowlist add port 22
nordvpn allowlist add subnet 239.255.255.250/32
sudo nft list ruleset | grep -i allow

Los fallos de descubrimiento sorprenden porque una impresora o un servidor multimedia puede encontrarse mediante una consulta dirigida al grupo en lugar de una búsqueda de su propia dirección. Añadir la subred del host no cubre automáticamente ese grupo, así que el dispositivo sigue invisible mientras su página web carga bien cuando escribes la dirección.

Mantén la excepción tan estrecha como el síntoma permita. Un prefijo amplio escrito una vez se olvida durante años, y nadie puede explicar después qué máquinas debía admitir. Borra las entradas cuando acabe el proyecto que las necesitaba y comprueba qué queda después de una actualización.

Las compilaciones recientes también exponen un único ajuste de descubrimiento de LAN. Es cómodo, y se relaciona con la lista de permitidos en lugar de apilarse sobre ella: activarlo puede borrar entradas existentes de subredes privadas, y una regla manual de subred privada puede rechazarse mientras siga activado.

Los nombres de host necesitan una decisión aparte

Permitir una subred restaura la conectividad por dirección y deja el nombrado intacto. Los nombres de host locales siguen enviándose al resolutor que el cliente configuró cuando se levantó el túnel, así que un nombre que antes se resolvía ahora no devuelve nada.

Apuntar el cliente al resolutor del router lo arregla en un paso y cambia en silencio lo que compraste. Entonces cada consulta, no solo las locales, sale por el router, así que el túnel ya no protege la parte de tu navegación que revela intenciones.

La ruta más estrecha conserva el resolutor del túnel y añade los pocos nombres que importan, ya sea como dominio de búsqueda o como entradas individuales. Cuesta más atención y preserva la propiedad por la que pagaste.

Comprueba el resultado con una llamada al resolutor del sistema en lugar de con un navegador. Los navegadores cada vez ejecutan su propia resolución cifrada y responden encantados por una ruta que tu shell nunca usa, así que la barra de direcciones puede parecer sana mientras el resolutor del sistema sigue roto.

El problema de instalación que llega primero

Una buena parte de estos informes nunca llegan al cortafuegos, porque el comando no está ahí. El paquete de arranque del proveedor registra un repositorio y una clave de firma. No instala el cliente, así que un comando ausente justo después es el resultado esperado y no un fallo.

Actualiza las listas de paquetes e instala por nombre. Si el gestor de paquetes se queja de una clave pública ausente, la clave no llegó donde la busca, y el arreglo es colocarla allí antes de volver a actualizar.

Si el nombre de host del repositorio resuelve a una dirección privada, detente y lee ese resultado dos veces. Puede que ya estés ejecutando un túnel cuyo resolutor responde por nombres públicos, y reintentar la instalación producirá el mismo mensaje indefinidamente.

Anótalo antes de cerrar la tapa

Establece que el túnel es lo único que ha cambiado y luego permite lo más pequeño que restaure el síntoma. Mantén el nombrado como su propia decisión con su propia nota.

Registra qué excepción existe para qué dispositivo y quién la pidió. Una red local que solo funciona porque alguien escribió un prefijo amplio es una decisión que ya ha sobrevivido a la razón que la motivó.

Vuelve a probar después de que el cliente se actualice. La disposición del cortafuegos cambia entre versiones, y la lista de permitidos del mes pasado no es un hecho sobre este mes.