La VPN dice que está conectada, pero la ruta predeterminada está muerta
Pasar de Wi-Fi a Ethernet puede dejar la ruta y el resolutor en el túnel antiguo. Lee ambos estados por separado y repara el que esté mal.
El cliente informa de que está conectado, el icono de la bandeja parece normal y no carga nada. Empezó justo después de pasar de Wi-Fi a cable, o justo después de que terminara una actualización de la distribución. Lo que se rompió no es el perfil, sino el estado que se construyó para la conexión base anterior. El núcleo todavía tiene una ruta predeterminada que apunta a un dispositivo de túnel que nadie posee, o el resolutor sigue listando servidores en un enlace que ha desaparecido. Ambos fallos parecen una red muerta y ambos se pueden reparar en el sitio.
Las piezas obsoletas ya estaban mal antes de que te dieras cuenta. Desenchufar un cable solo las hizo visibles.
Pregunta al núcleo adónde iría un paquete
Los listados de rutas son difíciles de leer porque enumeran todo lo que el sistema sabe, incluidas entradas que ya no se aplican. Una consulta de ruta responde a la única pregunta que vale la pena: qué dispositivo transporta este paquete concreto ahora mismo. Si la respuesta nombra un dispositivo de túnel, el núcleo lo usará aunque detrás no haya ningún proceso de cliente vivo, y el paquete cae en una interfaz que nadie mantiene. Si la respuesta nombra el adaptador Ethernet mientras el cliente insiste en que está activo, el túnel existe pero ha perdido la selección, que es el resultado habitual de pasar de inalámbrico a cable.
Ejecuta la consulta dos veces, una para una dirección pública y otra para una interna, porque una política de túnel dividido puede encaminar una con honestidad y dejar caer la otra.
ip route show default
ip route get 1.1.1.1
ip route get 10.20.30.40
El resolutor también conserva el enlace muerto
En un equipo con systemd-resolved, los servidores DNS pertenecen a los enlaces y no a una lista global. Un enlace VPN que ha caído puede seguir registrado con sus servidores durante un tiempo, y entonces cada consulta espera una dirección que nunca responderá. Esa demora se siente como una red muerta y hace que la gente mire las rutas cuando la ruta está bien.
resolvectl status
resolvectl query intranet.example.com
Lee los bloques por enlace e identifica qué enlace posee el dominio en cuestión. Un túnel que está levantado pero no es el propietario del dominio interno reenvía los nombres internos al resolutor público, y el síntoma es indistinguible de una falla de enrutamiento.
Repara el registro en lugar de /etc/resolv.conf. En las instalaciones actuales de Ubuntu y Fedora esa ruta es un enlace simbólico al estado de ejecución del resolutor, así que una edición o se ignora o se sobrescribe en el siguiente evento de red.
Una VPN nunca arranca sola
NetworkManager levanta una VPN sobre una conexión base, y aprende cuál debe seguir a partir de connection.secondaries en esa base. La referencia de ajustes de conexión dice explícitamente que la conexión automática no está implementada para los perfiles VPN. Ese es todo el mecanismo detrás de esta clase de fallo: cambia la base y la VPN tiene que emparejarse de nuevo o reactivarse a mano.
nmcli device status
nmcli connection show --active
nmcli connection up office-vpn
Cuando la lista activa muestra la base sin la VPN, el túnel no está activo en absoluto y la ruta nunca se instaló, en lugar de haber quedado obsoleta. Cuando la activación se queja de que no existe ninguna conexión de origen, la base con la que estaba emparejada ha desaparecido, así que arregla primero la base o el emparejamiento y deja de reintentar la VPN.
Una actualización puede dejar caer ajustes sin ningún mensaje
Actualizar una distribución sustituye el cliente y a menudo su complemento de NetworkManager, mientras el perfil guardado conserva los nombres de propiedad con los que se escribió. Todo lo que el complemento nuevo ya no reconoce se omite en silencio. El perfil sigue activándose y el dispositivo sigue apareciendo, pero la ruta que antes llegaba con él nunca llega.
Los ganchos escritos a mano también se mueven. Un script que instalaba una ruta en un momento predecible de la secuencia antigua puede ahora ejecutarse antes de que exista la interfaz, o después de que el cliente ya haya agotado el tiempo.
Compara el perfil vivo con el complemento que realmente tienes, no con el comportamiento que recuerdas. Si una clave ha desaparecido de la documentación, mueve el trabajo a un script despachador o a un reemplazo admitido en lugar de restaurar la propiedad antigua.
Tres estados, tres reparaciones distintas
Decide en qué estado estás antes de tocar nada, porque un reinicio destruye la evidencia y el fallo vuelve en el siguiente cambio de red.
| What the lookup shows | What it means | Repair |
|---|---|---|
| A default route via a device that exists but is unused | Leftover route from an earlier activation | Remove the stale entry, or bounce the profile that installed it |
| A tunnel device with no client process | The client skipped its cleanup | Fix the disconnect path, then clear the leftover device state |
| No tunnel device and no active profile | Missing base connection or broken pairing | Bring up the base, then pair the VPN with it again |
Termina con una consulta para una dirección pública, una para una dirección interna y una consulta de nombre. Si las direcciones funcionan y el nombre no, el fallo restante es el ámbito de dominio en el resolutor, y la tabla de rutas nunca fue el problema.