Túnel completo de FortiClient: enruta solo la subred de la oficina

El túnel se levanta, el icono se pone verde y la red local desaparece: impresoras, el NAS y el router de la oficina dejan de responder. FortiClient hace lo que el perfil pidió. La pasarela empujó una ruta por defecto, el cliente la instaló, y ahora cada paquete tiene un camino hacia el túnel. La reparación es una edición de la tabla de rutas con una edición de DNS detrás, y el orden de esas ediciones decide si la máquina acaba mejor o peor.

Qué instaló el cliente y por qué desapareció la LAN

Empieza leyendo la tabla en lugar de la interfaz del cliente. En macOS netstat -rn imprime toda la tabla y route -n get default nombra la interfaz y la métrica que ganan ahora mismo; en Linux la pareja es ip route show y ip route get 8.8.8.8. Ambos responden una pregunta: qué entrada llevará un paquete que no coincide con nada más específico.

El nombre del dispositivo del túnel no es fijo. Un perfil IKEv2 en macOS normalmente muestra utun con un número, el cliente SSL VPN muestra ppp0 y OpenVPN muestra tun0. También pueden estar presentes dos rutas por defecto a la vez con métricas distintas, y la entrada del cliente puede tomar el relevo solo tras una reconexión en lugar del momento en que aparece. Por eso dos volcados de la tabla tomados con cinco minutos de diferencia pueden contar historias distintas.

Por qué la ruta por defecto del túnel tiene que irse primero

El núcleo elige el prefijo coincidente más largo y, cuando varias rutas son igual de específicas, elige la de métrica más baja. Por eso un cliente que instala 0.0.0.0/0 con una métrica mejor gana todos los destinos sin borrar la ruta por defecto original, y por eso la ruta física sigue en la tabla y sigue explicando la caída. Quitar primero la ruta por defecto del túnel restaura el comportamiento anterior. Solo entonces una ruta de prefijo por el túnel hace lo que su autor pretendía.

Añadir prefijos antes de ese paso es el error que produce una máquina a medio funcionar. El tráfico del nuevo prefijo sigue el túnel, y todo lo que no está en la lista también sigue la ruta por defecto del túnel, así que nada parece roto hasta que alguien abre un servicio que nadie añadió. Borra, restaura y luego añade, y el estado intermedio se mantiene predecible.

La secuencia en macOS y en Linux

En macOS la secuencia borra la ruta por defecto del túnel, restaura la ruta por defecto física y devuelve un prefijo de la oficina al túnel. Sustituye los nombres de interfaz ilustrativos de aquí por los de tu propia tabla.

sudo route delete -net default -interface utun4
sudo route add -net 0.0.0.0 -interface en0
sudo route add -net 10.20.0.0 -netmask 255.255.0.0 -interface utun4

En Linux el mismo orden usa otra herramienta: la pasarela de la LAN para la ruta por defecto y el dispositivo del túnel para el prefijo de la oficina. El comando antiguo route todavía acepta la sintaxis vieja, pero ip route es la forma que coincide con la documentación actual.

sudo ip route del default dev tun0
sudo ip route add default via 192.168.50.1
sudo ip route add 10.20.0.0/16 dev tun0

Cuando la ruta necesita un salto siguiente en lugar de un dispositivo, toma el peer de la salida del cliente. Adivinar produce uno de dos errores, y significan cosas distintas: una pasarela equivocada da network unreachable de inmediato, mientras que un destino de túnel equivocado da un tiempo de espera agotado. Lee cuál obtuviste antes de volver a cambiar el comando.

Prefijos, el resolutor y la DMZ que se queda a oscuras

Un prefijo rara vez cubre el trabajo. Los servidores de aplicaciones, las redes de gestión, la DMZ y los propios servidores DNS pueden estar cada uno en un rango distinto, así que enumera todos los rangos que puedas nombrar antes de empezar y prueba una consulta junto a cada ping. Un destino descubierto a mitad de la prueba es el que se olvida en el registro de cambios. Una ruta que responde por dirección pero falla por nombre suele ser un problema del resolutor vestido de enrutamiento.

El resolutor es una decisión aparte. Cuando el perfil ha empujado servidores DNS internos, quitar la ruta por defecto puede dejar esas direcciones inalcanzables para los nombres públicos o alcanzables solo por el túnel, y ambos estados producen resultados parciales confusos. Enruta las direcciones del resolutor por el túnel, o configura la resolución por dominio para que las consultas públicas usen el resolutor local.

El cliente SSL de Linux tiene un fallo específico de campo que conviene conocer: el túnel conecta, la LAN de la oficina responde y un rango de la DMZ se queda a oscuras. La pieza que falta es una ruta para ese rango a través de la pasarela del túnel, y la pasarela cambia entre máquinas, así que una dirección codificada a mano es como se rompe el siguiente portátil. Derríbala del estado del cliente y mantén el comando autodocumentado:

PEER=$(ip -4 addr show dev ppp0 | awk '/peer/ {print $4}' | cut -d/ -f1)
sudo ip route add 192.168.30.0/24 via "$PEER"

Lee los dos valores antes de ejecutarlo. peer es el extremo lejano de un túnel punto a punto, que es la dirección que necesita la ruta de la DMZ; en un túnel enrutado el equivalente es la interfaz o la pasarela que informa el cliente. Si no aparece ninguno, el cliente no está en el modo que supusiste.

Después de la próxima conexión y cuándo dejar de hacerlo en local

FortiClient se reconecta tras un sueño o un cambio de red y vuelve a instalar lo que especifica el perfil. Las rutas manuales, por tanto, solo sobreviven hasta la próxima conexión, que es exactamente el intervalo en el que una sola prueba exitosa puede parecer una solución. Una ruta que desaparece de un día para otro es el comportamiento esperado, no un fallo nuevo.

Existen dos respuestas duraderas. Un script que vuelve a ejecutar la corrección tras cada conexión es un apaño que puede sobrevivir a su autor, mientras que un perfil de túnel dividido del administrador de la pasarela es la solución real, porque entonces el cliente solo instala los rangos que el trabajo necesita. Pide la segunda y usa la primera solo mientras esperas. Comprueba también la política que aceptaste antes de dividir un túnel completo en local, porque la red remota puede depender de ver todo tu tráfico.

La lista de comprobación es corta: lee la tabla, borra la ruta por defecto del túnel, restaura la ruta por defecto de la LAN, añade cada prefijo, corrige la resolución aparte y espera que las rutas vuelvan al reconectar.