¿El HTTPS del contenedor se cuelga en una VPN corporativa? Prueba la pata DTLS

Dentro de un contenedor detrás de una VPN corporativa, el DNS resuelve, la página de inicio de sesión carga, un endpoint de salud responde y luego una petición HTTPS se cuelga hasta agotar el tiempo de espera. Reconstruir la imagen y cambiar las variables del proxy no cambia nada, porque la parte que falla no está en la imagen. El cliente se autentica por un transporte y mueve datos masivos por otro, y solo el segundo está roto.

Dos transportes, un síntoma confuso

Un cliente corporativo basado en TLS suele autenticarse por una conexión TLS normal y después negocia un segundo canal de datos basado en UDP para la sesión. Cuando esa segunda pata funciona, mejoran el rendimiento y la latencia. Cuando se filtra o no cabe por la ruta, todo lo anterior a la transferencia masiva tiene éxito y la transferencia misma se detiene, que es exactamente el patrón anterior.

Un contenedor no cambia esa negociación; cambia la ruta que toman los paquetes exteriores. El host traduce el flujo del contenedor, así que los datagramas UDP salen desde un puerto de origen distinto al socket local del cliente y vuelven por una entrada de traducción que caduca con un temporizador mucho más corto que un flujo TCP establecido. Si el túnel funciona en el host y falla en el contenedor, compara esos dos flujos antes de culpar a la aplicación. Esa comparación aclara más que cualquier reconstrucción de la imagen.

Decide con experimentos, no con intuición

El experimento más barato desactiva el canal de datos UDP y repite la petición. Usa el cliente de línea de comandos en lugar del envoltorio de escritorio, para que la opción se aplique de verdad: openconnect vpn.example.net --user=you --interface=tun0 --no-dtls. Si la petición que se colgaba ahora se completa, la pata DTLS era el problema y el resto era ruido.

Confirma el resultado en ambos sentidos desde el mismo contenedor: una petición masiva con la opción y otra sin ella. Un cambio de comportamiento que sigue a la opción es evidencia; una página que acaba cargando no lo es.

Si la opción lo arregla, decide por qué

Tres condiciones producen el mismo síntoma y exigen respuestas distintas. La ruta puede filtrar UDP por completo, lo que convierte la opción en la respuesta permanente correcta para esa red. La ruta puede permitir UDP pero descartar datagramas grandes, lo que apunta al MTU y no al filtrado. O la ruta puede tener suficientes pérdidas como para que la pata UDP rinda peor que TCP, lo que es una decisión de capacidad y no de alcanzabilidad.

Distínguelas antes de documentar un apaño. El filtrado sobrevive a cualquier tamaño de paquete, los problemas de MTU solo aparecen por encima de un umbral y la pérdida se manifiesta como retransmisión y retraso variable, no como un cuelgue limpio. Cada prueba acota la causa sin cambiar la configuración del cliente.

Comprueba el tamaño de paquete antes de mantener el apaño

Si la causa es el tamaño, la interfaz del túnel acepta paquetes que la ruta no puede llevar, y el problema vuelve en cualquier transporte en cuanto crecen las cargas útiles. Compara las interfaces: ip link show tun0 en el host, luego docker network inspect bridge para leer el MTU registrado en las opciones de red. Un puente de contenedor que sigue en 1500 bytes bajo un túnel que lleva menos es el hallazgo habitual.

Sondea hacia arriba desde un tamaño bueno conocido con una prueba de no fragmentación dentro del túnel, y luego baja el MTU de la red del contenedor o limita el MSS de TCP en el túnel. Cualquiera de las dos correcciones suele volver a hacer utilizable la ruta UDP y elimina la necesidad de la opción, que es el mejor resultado cuando el filtrado no es la causa.

Decide qué estás dispuesto a intercambiar

Con el canal de datos desactivado, el túnel lleva su carga dentro de una conexión TCP. En una ruta limpia eso es solo más lento; en una con pérdidas, un solo segmento perdido retrasa todo lo que va detrás y la retransmisión exterior compite con la interior. Ese intercambio encaja con el desarrollo interactivo y las llamadas de API pequeñas, y encaja mal con transferencias masivas o sesiones largas por enlaces móviles.

Cualquiera que sea la opción que elijas, anota qué transporte acabó usando el túnel y por qué. Un contenedor que depende en silencio de una opción que alguien añadió hace meses es la próxima caída, y quien la depure no sabrá si la opción era un apaño para el filtrado o un resto de un experimento de MTU.