Qué ocurre realmente cuando inicias una VPN en Linux

Pulse conectar y tres cosas cambian en una máquina Linux: aparece una interfaz, se instalan rutas y el resolutor empieza a responder de otra forma. La mayoría de los fallos de configuración vienen de que una de esas tres ocurra sin las otras, o de que dos programas no se pongan de acuerdo sobre quién las posee. Entender la secuencia explica el fallo más rápido que leer la salida del registro de un cliente.

Una interfaz aparece antes de que nada funcione

Un cliente de túnel abre una interfaz virtual y le entrega paquetes. Un dispositivo TUN transporta paquetes IP, que es lo que necesita una VPN enrutada; un dispositivo TAP transporta tramas Ethernet, que es lo que necesita un diseño puente. El módulo del núcleo proporciona el dispositivo, y el cliente lo posee mientras dura la sesión.

Que la interfaz suba no es lo mismo que el túnel funcione. Puede existir con una dirección mientras el par no es accesible, y por eso la lista de interfaces es la primera comprobación y no la última. Un dispositivo que se declara levantado describe la visión del núcleo de un enlace virtual, no la disposición del par a responder.

Deje el modo de interfaz suministrado tal como está. Cambiar un perfil TUN a TAP no convierte un servidor enrutado en uno puente, y normalmente produce una conexión que se establece y no reenvía nada.

Las rutas las instala quien posee el túnel

Las rutas son el segundo cambio, y su propiedad importa más que su contenido. Un perfil de NetworkManager, una unidad de systemd y un cliente ejecutado a mano pueden instalar rutas, y que dos lo hagan a la vez produce una tabla que nadie podrá explicar después.

ip -br addr show
ip route show
ip -6 route show

Un perfil de túnel completo sustituye la ruta por defecto; un perfil de túnel dividido añade rutas más específicas y deja la ruta por defecto tal como está. Ambas son normales, y la segunda es la razón por la que borrar la ruta por defecto es una mala primera prueba en una máquina que administra en remoto. Eliminarla es también la forma más rápida de perder la sesión que usa para arreglar el problema.

Lea la tabla en lugar de suponer. Una ruta más específica o una regla de política pueden enviar tráfico al túnel mientras la ruta por defecto sigue apuntando a la interfaz física, lo que parece contradictorio hasta que lee toda la tabla. Esa combinación es normal para el túnel dividido y confusa para quien espera que una sola línea describa el diseño. Busque la ruta que coincide con su destino real, no la que coincide con el diagrama.

El resolutor cambia de manos

El DNS es el tercer cambio y el que más probablemente se gestiona en un lugar donde no ha mirado. En un escritorio, NetworkManager puede enviar la configuración del resolutor por conexión. En un sistema que usa systemd-resolved, la configuración se aplica por enlace y /etc/resolv.conf puede ser un stub o un enlace simbólico en lugar de un archivo que deba editar.

resolvectl status
readlink -f /etc/resolv.conf
cat /etc/resolv.conf

Si una edición manual del archivo del resolutor desaparece tras una reconexión, esa es la señal para encontrar el componente que lo mantiene y cambiar el perfil en su lugar. Editar el archivo generado es un cambio que una reconexión borrará.

Los nombres privados suelen necesitar el resolutor interno y los dominios de búsqueda que proporcionó el operador. Sustituirlo por un resolutor público puede romper justo el recurso para el que existe la VPN, y el síntoma parece un fallo de enrutamiento y no de DNS. Pruebe el nombre y la dirección por separado, porque que uno funcione y el otro falle le dice exactamente dónde mirar. Esa única comparación ahorra una hora de depuración de rutas.

Un gestor por conexión

El formato del perfil decide qué programa puede usarlo. Un perfil de OpenVPN necesita OpenVPN o un complemento compatible, y una configuración de WireGuard tiene su propio formato con claves de par y prefijos permitidos. Un diálogo de importación no convierte uno en el otro, diga lo que diga la extensión del archivo.

Elija un gestor y deje que sea dueño de la conexión. Levantar el mismo túnel con dos herramientas hace ambiguos la tabla de rutas y el comportamiento de reconexión, y el segundo que arranca suele ganar de formas difíciles de reproducir.

Instale los paquetes que admite su distribución y obtenga el perfil del operador. Trátelo como una credencial, porque normalmente contiene una clave privada o material equivalente, y guárdelo donde viven el resto de sus secretos. Un perfil dejado en una carpeta de descargas es una clave dejada sobre un escritorio.

Qué comprobar cuando está levantado pero no funciona

Con la interfaz levantada y el cliente informando de éxito, trabaje hacia fuera: ¿la tabla de rutas selecciona el túnel para el destino, responde el resolutor para el nombre privado y tiene el lado remoto un camino de vuelta? Cada uno tiene un comando separado y un propietario separado.

nmcli connection show --active
nmcli device status
wg show

La referencia de nmcli documenta los comandos de estado y conexión si necesita el conjunto completo. Lo que importa aquí es la distinción entre un perfil activo y un dispositivo que transporta tráfico, porque ambos pueden discrepar.

Reconecte una vez con el mismo gestor antes de dar la configuración por terminada, y compruebe que el DNS sigue funcionando tras una desconexión. Una configuración que solo funciona hasta el primer cambio de red no está terminada, simplemente funciona en este momento.