Qué añade realmente bypass-dhcp a un plan de rutas de OpenVPN

Un perfil con redirect-gateway def1 bypass-dhcp combina una sustitución de la ruta IPv4 predeterminada con una excepción muy estrecha. La gente lee la última palabra y espera una solución general para conexiones móviles, y luego dedica una tarde a una teoría de DHCP que el indicador nunca respaldó. Cada parte hace una sola cosa, y la excepción es mucho menor que su reputación.

Separe los indicadores antes de atribuir un fallo que solo ocurre con datos móviles a la asignación de direcciones. Las dos mitades de esa cadena no tienen nada que ver entre sí.

Dos indicadores, dos tareas sin relación

Con def1, el cliente añade dos medias rutas IPv4 predeterminadas en lugar de sustituir la ruta predeterminada que ya existe. 0.0.0.0/1 cubre la mitad inferior del espacio de direcciones y 128.0.0.0/1 la mitad superior, así que juntas alcanzan cualquier destino mientras cada una sigue siendo más específica que 0.0.0.0/0. La ruta predeterminada original permanece por tanto en la tabla sin ganar esas consultas, lo que mantiene accesible la puerta de enlace antigua para todo lo que el cliente enruta de forma explícita. También deja dos rutas predeterminadas superpuestas en la tabla, y por eso un volcado de rutas puede parecer más extraño de lo que sugiere el perfil.

bypass-dhcp es aparte y no toca la ruta predeterminada en absoluto. El manual de OpenVPN 2.6 lo documenta como la adición de una ruta directa hacia un servidor DHCP que no está en la subred local, de modo que el tráfico de concesión sale fuera del túnel, y señala que el comportamiento se implementa en clientes Windows y puede no estar disponible en otros lugares.

La razón de que exista es mecánica. Una vez que las medias rutas predeterminadas capturan el tráfico saliente, una renovación de DHCP dirigida a un servidor de la red física se enrutaría dentro del túnel a menos que algo fije esa dirección a la interfaz real. El indicador la fija.

A qué se limita realmente la excepción

Una tabla ilustrativa tras una conexión correcta muestra la forma: dos medias rutas predeterminadas por el túnel y una ruta de host para el servidor DHCP por la puerta de enlace física. Léala como una forma, no como sus propias direcciones.

0.0.0.0/1        via 10.8.0.1      dev tun0
128.0.0.0/1      via 10.8.0.1      dev tun0
192.168.1.1/32   via 192.168.1.254 dev wlan0

Esa tercera línea nombra un solo destino. No es un ajuste del resolutor, no es un permiso general para la red local y no es una regla de salida en el servidor. Un teléfono con un operador móvil puede no tener ningún servidor DHCP que el cliente pueda identificar de esta manera, y por eso el indicador no cambia nada ahí.

Compruebe qué instaló realmente el cliente

Distinga entre una opción escrita en un perfil, una opción ofrecida por el servidor y una ruta que el propietario de la conexión aplicó de verdad. Un cliente que rechaza un indicador no admitido puede conservar el resto de la configuración, así que el túnel se levanta y la excepción simplemente falta. Lea el registro propio del cliente y la tabla de enrutamiento resultante en lugar de suponer que la línea del archivo surtió efecto. Tres de esas cosas pueden ser ciertas a la vez, y solo la última cambia adónde van realmente los paquetes.

Mantenga utilizable al mismo tiempo la ruta hacia el extremo de la VPN. Esa excepción del extremo es un requisito distinto de la excepción de DHCP, y sin ella el túnel puede capturar el transporte que lo mantiene.

Para un destino de aplicación, examine la consulta efectiva en el contexto en el que falla. Rutas locales más específicas, el enrutamiento por políticas y las exclusiones por aplicación cambian todas la respuesta, así que la presencia de dos medias rutas predeterminadas no es un inventario de cada flujo.

El resto del camino no está en este indicador

El servidor sigue necesitando permiso para reenviar el tráfico de internet del cliente y una disposición de salida que pueda devolverlo. Ninguna ruta del lado del cliente crea un reenvío ni una traducción de origen que falten en el servidor, y ningún indicador sustituye un camino de vuelta que funcione.

La resolución de nombres y IPv6 necesitan cada una su propia política. Una sustitución de IPv4 ni apunta el resolutor a un servidor del lado del túnel ni establece cobertura IPv6, y un cliente que solo redirige v4 deja intacto el camino v6.

Compare una petición inocua aprobada por un camino de acceso que funciona y otro que falla, con el perfil y el destino fijos. Anote si la diferencia está en la resolución de nombres, en el establecimiento del túnel, en la selección de rutas o en el tráfico reenviado, y guarde la respuesta junto al perfil. Ese registro es lo que impide que la siguiente persona culpe al DHCP de un problema que no puede alcanzar.