Por qué una respuesta UDP de OpenVPN sale de una dirección incorrecta

Un cliente de OpenVPN marca una dirección, el servidor responde desde otra y el túnel nunca se levanta. El registro del servidor muestra que el paquete llega y una captura muestra que la respuesta sale, así que el fallo se atribuye al cliente. En un equipo con varias interfaces, o con varias direcciones en una sola interfaz, las dos partes simplemente no coinciden sobre qué dirección está en uso. La respuesta es válida en la capa IP, pero muchos clientes descartan un datagrama cuya origen no es la dirección a la que se conectaron.

Qué ve el cliente cuando cambia el origen

Un socket UDP no ligado a una dirección local concreta no tiene un origen fijo, así que el núcleo elige uno al enviar. Esa elección proviene de una consulta de ruta hacia la dirección del cliente, y el origen pasa a ser la dirección de la interfaz que selecciona la consulta. En una máquina con una sola interfaz la elección es invisible; en un equipo con una dirección de gestión, una dirección pública y una dirección secundaria en la misma tarjeta de red, depende de las métricas y la política de enrutamiento. El enrutamiento por políticas hace la discrepancia más probable en lugar de menos, porque una regla puede seleccionar un enlace ascendente al que el cliente nunca llegó. Una ruta predeterminada aprendida de un proveedor más una regla de origen que apunta a otro basta para producirla.

Los clientes que filtran respuestas, y el seguimiento de conexiones que espera la cuádrupla exacta y el origen, descartarán la respuesta sin un mensaje útil. Entonces el túnel expira como si no hubiera llegado nada, y por eso esto se confunde con un problema de cortafuegos en el lado del cliente. Una captura tomada solo en el servidor confirma el error en lugar de explicarlo, porque la respuesta sí sale. Compare el origen de la respuesta con la dirección a la que marcó el cliente antes de cambiar cualquier otra cosa.

Qué hace realmente la opción multihome

La directiva se escribe multihome en un archivo de configuración y --multihome en la línea de órdenes, y hace que un servidor UDP responda desde la dirección a la que llegó el paquete del cliente. El núcleo entrega la dirección de destino original como datos auxiliares al recibir, y OpenVPN usa ese valor como origen de la respuesta. Así, un servidor que escucha en una dirección comodín, local 0.0.0.0 para IPv4 o su equivalente IPv6, se comporta como si cada cliente hubiera llegado a un oyente dedicado. Los clientes que entraron por la dirección pública reciben respuestas desde la dirección pública, y los clientes en una dirección interna las reciben desde esa. Nada más en la ruta del paquete se mueve: la ruta, las reglas de filtro y la configuración del túnel quedan exactamente como estaban.

Esa última propiedad es la razón por la que la opción es segura de añadir a un servidor que ya funciona, y también la razón por la que no puede reparar un filtro que solo permite una dirección. El paquete todavía tiene que aceptarse en la ruta que sigue, así que la corrección del origen cambia el origen de la respuesta y nada más. También es solo para UDP: un oyente TCP no tiene este problema en la misma forma, porque la conexión se identifica por la cuádrupla y no por la dirección de origen de la respuesta.

Cuándo una dirección local fija es el valor predeterminado incorrecto

Antes de recurrir a la opción, compruebe si el servidor liga una dirección local concreta, porque un oyente ligado siempre responde desde esa dirección. Eso es correcto para un despliegue de una sola interfaz e incorrecto en cuanto los clientes usan legítimamente más de una dirección. Si la ligadura fue deliberada, decida si el servidor debe aceptar tráfico en direcciones adicionales. Quitar la ligadura aumenta la exposición, así que las interfaces y las redes de origen permitidas tienen que imponerlas el servicio y el filtro, no solo la dirección de ligadura.

La referencia de OpenVPN limita la opción a servidores UDP, anota el procesamiento adicional en la ruta del paquete y registra qué plataformas la admiten. Confírmelo en la versión instalada antes de planificar en torno a ella. Donde no se admite, la alternativa es ligar la dirección concreta o corregir el enrutamiento de retorno, y ambos son cambios más estrechos de lo que parecen a primera vista. Escuchar en comodín también tiene consecuencias más allá de las respuestas: un servidor en todas las direcciones es alcanzable desde cada red a la que está conectado el equipo, y puede que esa no sea la exposición que alguien pretendía.

Demuestre el origen de la respuesta desde fuera

Pruebe desde fuera del servidor y anote la dirección y el transporte exactos que usó el cliente antes de capturar nada. Las tres pruebas de abajo responden a tres preguntas distintas, y el orden importa.

tcpdump -ni any udp port 1194
ss -lunp 'sport = :1194'
ip route get 203.0.113.10 from 198.51.100.20

La captura muestra la dirección de origen en la respuesta, que es el hecho sobre el que gira todo el artículo. El listado de sockets muestra qué ligó realmente el servidor, porque un oyente comodín y uno concreto se ven idénticos en un archivo de configuración y se comportan distinto en la red. La consulta de ruta muestra el origen que el núcleo elegiría para ese flujo, lo que explica la captura antes de que cambie nada. Repita las tres para IPv4 e IPv6 por separado, porque son oyentes separados y consultas separadas, y una entrada comodín para una familia no dice nada de la otra.

Enrutamiento, descubrimiento y filtrado siguen separados

Preservar el origen de la respuesta no instala una ruta de salida, no actualiza el DNS dinámico ni hace que una familia de direcciones acepte la otra. En un servidor con varios enlaces ascendentes, la ruta de retorno de cada origen tiene que acordarse deliberadamente, o las respuestas salen por una interfaz que el filtro del cliente nunca permitió. Del mismo modo, una dirección nueva tras un cambio de prefijo tiene que llegar a los clientes mediante el descubrimiento y el flujo de reconexión admitido, no mediante el registro antiguo.

Deje las comprobaciones de identidad del servidor y la verificación de certificados exactamente como están, porque una dirección cambiada no justifica aceptar un par no verificado. Si la respuesta ahora sale del origen previsto y el túnel sigue fallando, dé por resuelto el problema del origen y siga adelante. El siguiente error observado pertenece al enrutamiento, al filtrado o a la autenticación, y volver a cambiar el oyente no llegará a él. Escriba el origen de la respuesta en el ticket junto a la dirección a la que marcó el cliente, para que la siguiente persona pueda comprobar el mismo hecho con una orden.