Por que as páginas do OpenConnect travam até você baixar a MTU do túnel

O login funciona, a página inicial do portal é desenhada e então um widget do painel ou um relatório fica em waiting for host até o navegador desistir. Os sites públicos carregam normalmente o tempo todo, e nenhuma credencial mudou. Chegarem respostas pequenas enquanto as grandes travam é a assinatura de um teto de tamanho de pacote e não de uma regra de acesso. Confirme essa leitura antes de alterar qualquer outra coisa no perfil.

Separe um problema de tamanho de um problema de política

Comece descartando uma recusa. Se o gateway tivesse recusado você, a conexão falharia de imediato em vez de carregar meia página. Um túnel que sobe e depois trava só nas transferências maiores está dizendo que o caminho externo não consegue carregar o pacote interno.

O mecanismo é a encapsulação. Cada pacote interno ganha cabeçalhos de túnel, então uma carga útil que cabia no link físico se torna um pacote externo que já não cabe, e tudo o que carrega o bit do-not-fragment é descartado sem uma resposta que o navegador consiga interpretar.

Meça o teto com sondas do-not-fragment

Meça o teto em vez de adivinhá-lo. Envie sondas que recusam a fragmentação e baixe a carga útil passo a passo até voltar uma resposta, começando por um comando como ping -M do -s 1472 host. Uma resposta que reclama que é preciso fragmentar enquanto o DF está ativo significa que o valor ainda está alto demais. Repita em 1462, depois em 1452, e pare no primeiro tamanho que responder. Anote o número junto com o host que você testou, porque a resposta pertence a esse caminho e não ao protocolo em geral.

Teste o endereço para o qual o túnel realmente envia tráfego. Uma sonda externa contra o nome público do gateway e uma sonda interna contra um servidor interno medem saltos diferentes, e a filtragem de ICMP em qualquer uma delas pode fazer um caminho saudável parecer quebrado.

Aplique o valor ao dispositivo do túnel

Aplique o resultado à interface que o cliente criou, não ao adaptador Wi-Fi. Num cliente Linux isso é ip link set dev tun0 mtu 1300 seguido de ip link show tun0 para confirmar que o valor foi aplicado. Use o nome de dispositivo que o cliente informar, porque ele varia conforme a implementação e conforme o modo como o túnel foi construído.

Baixar a MTU do túnel reduz a carga útil que cada pacote carrega, então a vazão bruta cai um pouco, e esse é o preço de não jogar as respostas grandes num buraco negro. Um número menor não é automaticamente mais seguro. Trocar o adaptador físico, em vez disso, espalha o dano por todas as conexões desse link enquanto deixa os pacotes internos grandes demais igualmente grandes.

Use primeiro os pedidos de MTU do próprio cliente

Quando você controla a invocação, o cliente pode pedir um tamanho em vez de ser corrigido depois. --mtu pede ao servidor uma MTU de túnel, e --base-mtu declara a MTU do caminho subjacente para que o gateway possa derivar o número do túnel. Ambos são pedidos, e o manual do cliente não promete que o gateway atenderá nenhum deles.

Essa distinção define a sua ordem de trabalho. Tente o pedido primeiro e inspecione a interface que ele produz, e depois volte a definir o dispositivo localmente se o valor escolhido pelo gateway ainda travar.

Verifique com a transferência que falhou e depois torne isso permanente

Uma alteração local de ip link dura até o cliente reconstruir o túnel, o que acontece na próxima reconexão ou retomada. Coloque o valor onde a conexão começa: um wrapper que executa o cliente e depois ajusta o dispositivo, uma unidade systemd com um passo ExecStartPost, ou a opção do cliente quando o gateway a aceita. Mantenha-o junto ao perfil no controle de versão para que a próxima pessoa veja por que o número está ali.

Teste com o pedido que falhou, não com a página inicial. Abra o relatório, baixe o anexo ou execute a busca do repositório que travou, e anote exatamente onde ela para se ainda parar. Uma página que é desenhada depois da alteração prova pouco, porque antes também era desenhada.

Se a mesma transferência trava no mesmo ponto, a teoria da MTU não está provada. Capture o tráfego no túnel e verifique qual lado para de enviar antes de mudar o número outra vez, e mantenha o valor anterior anotado para que a reversão continue sendo um único comando.