Por qué route-nopull por sí solo deja inalcanzable el servidor de archivos
Ignorar las rutas empujadas es solo la mitad de un túnel dividido. Elige al dueño de la ruta, añade el prefijo de la oficina a mano y prueba tres flujos antes de darlo por arreglado.
El servidor de archivos abre bien, y la videollamada de la ventana de al lado empieza a entrecortarse. Nada va lento y ningún MTU está mal: tu cliente aceptó la lista de rutas que le entregó el servidor, así que ahora cada paquete sale por el cortafuegos de la oficina. La solución no es otra bandera de ajuste sino una decisión sobre quién es dueño de la tabla de rutas del cliente. Esa decisión pertenece a un solo lugar, y los modos de fallo de abajo te dicen qué lugar elegiste en realidad.
Decide quién es dueño de la tabla de rutas
Hay tres dueños posibles. El servidor puede empujar rutas y una puerta de enlace predeterminada, y entonces el cliente instala lo que le digan y se convierte en un túnel completo. El perfil del cliente puede tomar la propiedad descartando los empujes y llevando sus propias líneas de ruta. Un gestor de conexiones de escritorio también puede ser dueño de la decisión mediante sus propias propiedades de ruta y ruta predeterminada.
Cada opción falla de una manera distinta, y por eso vale la pena leer la tabla antes de editar un perfil. La fila que coincide con tu síntoma es el dueño que tienes en realidad.
| Owner | Where it lives | Result |
|---|---|---|
| Server | server config, redirect-gateway, pushed routes | client becomes a full tunnel |
| Profile | route-nopull and its own route lines | tunnel up, office prefix missing |
| Manager | never-default plus its own routes | desktop decides, profile ignored |
Elige uno y anótalo. Mezclar dos deja un host cuya ruta predeterminada contradice su propia documentación, y el siguiente ingeniero no puede saber qué capa ganó. Borra al perdedor de forma explícita.
route-nopull filtra los empujes, no añade rutas
route-nopull pertenece al perfil del cliente, y su orden en ese archivo es irrelevante porque solo descarta los valores que vienen del servidor. Descarta las rutas empujadas, incluida una ruta predeterminada empujada, mientras el túnel sigue levantándose con normalidad.
La consecuencia que la gente pasa por alto es que las opciones DHCP empujadas se van con ellas. Los ajustes de DNS que envía el servidor también se descartan, así que los nombres internos dejan de resolverse aunque el túnel esté sano y el servidor sea alcanzable por dirección.
Eso deja un túnel sin camino hacia el prefijo de la oficina a menos que añadas uno tú mismo: route-nopull seguido de route 10.30.0.0 255.255.0.0 en el mismo perfil. Esa línea lleva una dirección y una máscara; no nombra un siguiente salto.
Una forma alternativa añade un token de puerta de enlace, route 10.30.0.0 255.255.0.0 vpn_gateway, que apunta la entrada al túnel por su nombre. Los importadores difieren en si traducen esa variante, así que inspecciona la conexión guardada si la entrada falta de la tabla del núcleo.
Verifica con consultas de ruta, no con un ping
Un ping te dice que algo respondió. Una consulta de ruta te dice qué interfaz elegiría el núcleo, y esa es la pregunta que hiciste en realidad. Cuatro comandos cortos separan una ruta ausente de una ruta que apunta al dispositivo equivocado.
Lee lo que instaló el túnel con ip route show dev tun0. Ninguna salida significa cero rutas, lo que no es un túnel dividido que funcione, y es el resultado habitual de añadir el filtro sin la línea explícita.
Luego comprueba una dirección de la oficina con ip route get 10.30.5.7, y una dirección de internet corriente con ip route get 1.1.1.1. La segunda debería nombrar la interfaz física; si nombra el túnel, el empuje no se filtró en absoluto.
Por último lee ip rule, porque una regla de política dejada por un intento anterior puede anular la tabla que acabas de corregir. Un perfil correcto con una regla obsoleta encima se ve exactamente como un perfil roto. Borra la regla que añadiste la última vez antes de añadir otra.
Las subredes superpuestas parecen un túnel roto
Dos rangos privados pueden ser idénticos desde el punto de vista del cliente, y ahí es donde se culpa a un túnel dividido de algo que no causó. Si la oficina reparte el mismo prefijo que usa tu router de casa, la ruta del túnel cubre el router y la red de casa parece desaparecer.
Compara la dirección de tu propia interfaz con la ruta que instala el perfil, usando un listado de direcciones simple antes de cambiar nada. La superposición es real, y ninguna opción del perfil la resuelve. Lo que sí puedes arreglar es el nombrado, para que la siguiente persona vea dos rangos en lugar de uno.
Los arreglos honestos son renumerar un lado o traducir direcciones en la oficina. Fijar una sola ruta de host al router funciona hasta que cambia la dirección del router, y entonces se convierte en un segundo misterio encima del primero.
Haz que la decisión sobreviva a una reconexión
Las entradas escritas a mano no sobreviven a una reconexión, y un gestor de conexiones reconstruye la tabla cada vez que arranca el perfil. Pon la decisión donde se crea la conexión, ya sea el perfil o los ajustes guardados del gestor. Después reinicia la conexión una vez a propósito en lugar de descubrir el comportamiento durante una llamada. Un perfil que solo funciona hasta la próxima reconexión no está terminado.
Ejercita tres caminos a la vez: un host de la oficina por dirección literal, el mismo host por nombre, y un sitio público normal. El del medio depende del servicio de nombres que configuraste tras descartar las opciones DNS empujadas, y es el que falla en silencio.