Conserve las rutas privadas y descarte la redirección: túnel dividido de OpenVPN

El túnel se levanta, la aplicación se carga y entonces todo lo demás en el portátil empieza a comportarse de forma extraña. Esa es la forma habitual de una política solo privada implementada borrando una línea. Quitar una ruta predeterminada empujada sí cambia adónde va el tráfico, pero no dice adónde debería ir el tráfico en su lugar, y no toca en absoluto la resolución de nombres. Una política necesita dos mitades positivas antes de poder probarse.

Borrar la redirección es solo la mitad del cambio

Una redirección de túnel completo y una política solo privada difieren en lo que afirman sobre el mundo. La redirección reclama cada destino, mientras que la política privada reclama una lista y deja el resto en paz. Borrar la reclamación sin escribir la lista produce un cliente que no alcanza nada fuera de la LAN, lo que parece un fallo de enrutamiento más que un hueco de política. Escriba la lista antes de quitar la reclamación, y el orden de esos dos pasos deja de importar.

Ambas mitades son requisitos, no valores predeterminados. Los prefijos privados tienen que entrar en el túnel, y los destinos normales tienen que conservar la ruta que tenían antes de la conexión.

Si una organización exige el túnel completo, nada de esto se aplica. El diseño solo privado pertenece a despliegues en los que el enrutamiento dividido está aprobado.

pull-filter es una coincidencia, no un interruptor

La directiva pull-filter elimina las opciones empujadas cuyos nombres coinciden con un prefijo, y eso es todo lo que hace. Ignorar la redirección deja cada otra opción empujada en su sitio, que suele ser lo que uno quiere: las rutas, los ajustes de DNS y el valor de puerta de enlace de ruta siguen llegando. Tampoco puede eliminar una directiva escrita en el perfil local, porque el filtrado se aplica a lo que empuja el servidor.

Resista la tentación de ignorar todas las opciones que empiecen por route. Ese patrón también descarta las rutas privadas que necesita la conexión, y puede tirar información de puerta de enlace de la que depende el túnel.

route-nopull es una decisión más amplia de lo que parece. Impide que el cliente acepte las rutas empujadas y las opciones tipo DHCP como grupo, lo que es una política distinta de filtrar una sola opción.

Escriba la lista de rutas desde la aplicación hacia fuera

Empiece por lo que el usuario abre en realidad y luego añada las piezas de apoyo. Una aplicación en 10.60.20.15 implica su subred 10.60.0.0/16, y un nombre privado implica el resolutor que lo responde. Por tanto, un usuario que pidió una sola aplicación necesita dos destinos y una decisión de DNS. Todo lo que queda más allá de esa lista está fuera de alcance por construcción, y eso es lo que mantiene la política revisable.

En un servidor que colabora, eso se convierte en dos rutas empujadas, y ninguna de las dos es una redirección. Conserve la topología del túnel y los valores de puerta de enlace de ruta que suministra el servicio existente.

Cuando solo algunos usuarios necesitan esta política, aplíquela por cliente o por grupo. Cambiar el enrutamiento de todos para arreglar el requisito de un solo equipo es la forma en que un túnel dividido se convierte en una interrupción.

Haga que el DNS siga el mismo camino

Una ruta hacia el resolutor no es una política de resolutor. En un cliente systemd-resolved el resultado semántico es un dominio de enrutamiento para el espacio de nombres privado que apunta al resolutor interno, y eso es lo que hace que solo esos nombres lo usen. Un cliente de Windows necesita en cambio su propio mecanismo de política de espacios de nombres. Una línea de servidor DNS en el perfil no instala ninguna de las dos cosas por sí sola.

Compruebe lo que ha seleccionado el sistema operativo en lugar de lo que ha pedido el perfil. En Linux, resolvectl status muestra el dominio y el servidor por enlace; en Windows, la tabla de políticas de espacios de nombres es la evidencia equivalente.

Mantenga el resolutor accesible a través del túnel, o la política apuntará a una dirección que no se puede consultar. Una dirección de resolutor a la que el túnel no llega convierte una política que funciona en un tiempo de espera agotado.

Verifique ambas mitades en una reconexión

Vuelva a conectar el cliente tras el cambio e inspeccione la ruta efectiva hacia una dirección privada y hacia una pública. Después resuelva un nombre privado y un nombre público y confirme que cada uno usó el resolutor previsto. Que un sitio web público cargue solo demuestra la segunda mitad, y esa es la mitad que suele funcionar por casualidad.

Registre la política terminada en una frase: estos prefijos y nombres usan esta conexión, todo lo demás sigue la ruta local. Después guárdela en el perfil en lugar de reparar los ajustes del adaptador tras cada inicio de sesión.