Por qué las páginas de OpenConnect se cuelgan hasta que bajas la MTU del túnel

El inicio de sesión funciona, la página principal del portal se pinta y entonces un widget del panel o un informe se queda en waiting for host hasta que el navegador se rinde. Los sitios públicos cargan con normalidad todo el tiempo y ninguna credencial ha cambiado. Que lleguen respuestas pequeñas mientras las grandes se atascan es la firma de un techo de tamaño de paquete y no de una regla de acceso. Confirma esa lectura antes de tocar cualquier otra cosa del perfil.

Separa un problema de tamaño de un problema de política

Empieza descartando un rechazo. Si la puerta de enlace te hubiera rechazado, la conexión habría fallado de inmediato en lugar de cargar media página. Un túnel que se levanta y luego se atasca solo en transferencias grandes te dice que la ruta exterior no puede llevar el paquete interior.

El mecanismo es la encapsulación. Cada paquete interior gana cabeceras de túnel, así que una carga útil que cabía en el enlace físico se convierte en un paquete exterior que ya no cabe, y todo lo que lleva el bit do-not-fragment se descarta sin una respuesta que el navegador pueda interpretar.

Mide el techo con sondas do-not-fragment

Mide el techo en lugar de adivinarlo. Envía sondas que rechacen la fragmentación y baja la carga útil paso a paso hasta que vuelva una respuesta, empezando por un comando como ping -M do -s 1472 host. Una respuesta que se queja de que hace falta fragmentación mientras DF está activo significa que el valor sigue siendo demasiado alto. Repite en 1462, luego en 1452, y detente en el primer tamaño que devuelva respuesta. Anota el número junto con el host que has sondeado, porque la respuesta pertenece a esa ruta y no al protocolo en general.

Sondea la dirección a la que el túnel envía tráfico de verdad. Una sonda exterior contra el nombre público de la puerta de enlace y una sonda interior contra un servidor interno miden saltos distintos, y el filtrado ICMP en cualquiera de las dos puede hacer que una ruta sana parezca rota.

Aplica el valor al dispositivo del túnel

Aplica el resultado a la interfaz que creó el cliente, no al adaptador Wi-Fi. En un cliente Linux eso es ip link set dev tun0 mtu 1300 seguido de ip link show tun0 para confirmar que el valor se aplicó. Usa el nombre de dispositivo que reporte el cliente, porque varía según la implementación y según cómo se construyó el túnel.

Bajar la MTU del túnel reduce la carga útil que lleva cada paquete, así que el caudal masivo cae un poco, y ese es el precio de no mandar las respuestas grandes a un agujero negro. Un número más pequeño no es automáticamente más seguro. Cambiar el adaptador físico en su lugar reparte el daño por todas las conexiones de ese enlace mientras deja los paquetes interiores sobredimensionados igual de sobredimensionados.

Usa primero las peticiones de MTU del propio cliente

Cuando controlas la invocación, el cliente puede pedir un tamaño en lugar de recibir un parche después. --mtu pide al servidor una MTU de túnel, y --base-mtu declara la MTU de la ruta subyacente para que la puerta de enlace pueda derivar la cifra del túnel. Ambas son peticiones, y el manual del cliente no promete que la puerta de enlace vaya a atender ninguna.

Esa distinción fija tu orden de trabajo. Prueba primero la petición e inspecciona la interfaz que produce, y luego vuelve a fijar el dispositivo en local si el valor que eligió la puerta de enlace sigue atascándose.

Verifica con la transferencia que falló y luego hazlo persistente

Un cambio local de ip link dura hasta que el cliente reconstruya el túnel, cosa que ocurre en la siguiente reconexión o reanudación. Pon el valor donde empieza la conexión: un envoltorio que ejecuta el cliente y luego ajusta el dispositivo, una unidad systemd con un paso ExecStartPost, o la opción del cliente cuando la puerta de enlace la acepta. Tenlo junto al perfil en el control de versiones para que la siguiente persona vea por qué está el número.

Prueba con la petición que falló, no con la página principal. Abre el informe, descarga el adjunto o ejecuta la obtención del repositorio que se colgó, y anota exactamente dónde se detiene si sigue deteniéndose. Una página que se pinta después del cambio demuestra poco, porque antes también se pintaba.

Si la misma transferencia se atasca en el mismo punto, la teoría de la MTU no está demostrada. Captura el tráfico en el túnel y comprueba qué lado deja de enviar antes de cambiar el número otra vez, y ten el valor anterior anotado para que la reversión siga siendo un solo comando.