Por que as páxinas de OpenConnect se colgan ata que baixas o MTU do túnel

O inicio de sesión funciona, a páxina principal do portal píntase e entón un widget do panel ou un informe queda en waiting for host ata que o navegador se rende. Os sitios públicos cargan con normalidade todo o tempo e ningunha credencial cambiou. Que cheguen respostas pequenas mentres as grandes se atascan é a sinatura dun teito de tamaño de paquete e non dunha regra de acceso. Confirma esa lectura antes de tocar calquera outra cousa do perfil.

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

Comeza descartando un rexeitamento. Se a pasarela te rexeitase, a conexión fallaría de inmediato en lugar de cargar media páxina. Un túnel que se levanta e logo se atasca só nas transferencias grandes diche que a ruta exterior non pode levar o paquete interior.

O mecanismo é a encapsulación. Cada paquete interior gaña cabeceiras de túnel, así que unha carga útil que cabía na ligazón física convértese nun paquete exterior que xa non cabe, e todo o que leva o bit do-not-fragment descártase sen unha resposta que o navegador poida interpretar.

Mide o teito con sondas do-not-fragment

Mide o teito en lugar de adiviñalo. Envía sondas que rexeiten a fragmentación e baixa a carga útil paso a paso ata que volva unha resposta, comezando por un comando como ping -M do -s 1472 host. Unha resposta que se queixa de que fai falta fragmentación mentres DF está activo significa que o valor segue sendo demasiado alto. Repite en 1462, logo en 1452, e detente no primeiro tamaño que devolva resposta. Anota o número xunto co host que sondaches, porque a resposta pertence a esa ruta e non ao protocolo en xeral.

Sondea o enderezo ao que o túnel envía tráfico de verdade. Unha sonda exterior contra o nome público da pasarela e unha sonda interior contra un servidor interno miden saltos distintos, e o filtrado ICMP en calquera das dúas pode facer que unha ruta sa pareza rota.

Aplica o valor ao dispositivo do túnel

Aplica o resultado á interface que creou o cliente, non ao adaptador Wi-Fi. Nun cliente Linux iso é ip link set dev tun0 mtu 1300 seguido de ip link show tun0 para confirmar que o valor se aplicou. Usa o nome de dispositivo que informe o cliente, porque varía segundo a implementación e segundo como se construíu o túnel.

Baixar o MTU do túnel reduce a carga útil que leva cada paquete, así que o caudal masivo cae un pouco, e ese é o prezo de non mandar as respostas grandes a un burato negro. Un número máis pequeno non é automaticamente máis seguro. Cambiar o adaptador físico no seu lugar reparte o dano por todas as conexións desa ligazón mentres deixa os paquetes interiores sobredimensionados igual de sobredimensionados.

Usa primeiro as peticións de MTU do propio cliente

Cando controlas a invocación, o cliente pode pedir un tamaño en lugar de recibir un parche despois. --mtu pide ao servidor un MTU de túnel, e --base-mtu declara o MTU da ruta subxacente para que a pasarela poida derivar a cifra do túnel. Ambas son peticións, e o manual do cliente non promete que a pasarela vaia atender ningunha.

Esa distinción fixa a túa orde de traballo. Proba primeiro a petición e inspecciona a interface que produce, e despois volve fixar o dispositivo en local se o valor que escolleu a pasarela segue atascándose.

Verifica coa transferencia que fallou e despois fai que persista

Un cambio local de ip link dura ata que o cliente reconstrua o túnel, cousa que ocorre na seguinte reconexión ou reanudación. Pon o valor onde comeza a conexión: un envoltorio que executa o cliente e logo axusta o dispositivo, unha unidade systemd cun paso ExecStartPost, ou a opción do cliente cando a pasarela a acepta. Téneo xunto ao perfil no control de versións para que a seguinte persoa vexa por que está o número.

Proba coa petición que fallou, non coa páxina principal. Abre o informe, descarga o anexo ou executa a obtención do repositorio que se colgou, e anota exactamente onde se detén se segue deténdose. Unha páxina que se pinta despois do cambio demostra pouco, porque antes tamén se pintaba.

Se a mesma transferencia se atasca no mesmo punto, a teoría do MTU non está demostrada. Captura o tráfico no túnel e comproba que lado deixa de enviar antes de cambiar o número outra vez, e ten o valor anterior anotado para que a reversión siga sendo un só comando.