Ajuste de MSS de TCP num gateway Linux IPsec: o que corrige

O ping funciona, o SSH funciona, uma página pequena carrega e, então, cada resposta grande fica presa até esgotar o tempo. O padrão clássico aponta para o tamanho do pacote e não para a acessibilidade: o caminho transporta o handshake e os primeiros kilobytes, e depois um segmento de tamanho completo desaparece. Num gateway Linux IPsec, uma regra TCP MSS costuma ser a solução, mas só se compreender o que ela altera e onde está realmente o pacote que toca. A ordem abaixo segue o pacote do sintoma até à colocação da regra, para que possa parar assim que a explicação deixar de encaixar.

O sintoma que sugere MSS

O TCP negocia um tamanho máximo de segmento no handshake. Se esse valor for maior do que o caminho consegue transportar após a encapsulamento, o emissor continua a produzir segmentos que nunca chegam, e a ligação fica presa após a primeira ronda. As respostas pequenas cabem; as grandes não.

O feedback ICMP pode salvar a ligação através da descoberta do MTU do caminho, e uma firewall que descarta essas mensagens transforma o bloqueio num buraco negro silencioso. É por isso que o mesmo túnel funciona para uma aplicação e falha para outra sem qualquer diferença evidente na configuração.

O que uma regra TCPMSS faz e o que não faz

A regra reescreve a opção MSS nos pacotes de handshake TCP à medida que passam. Não define o MTU da interface do túnel, não altera a política IPsec e, nos kernels atuais, apenas baixa um valor anunciado em vez de subir um que já é menor. Também só toca no TCP; as cargas UDP, o comportamento do DNS e os seletores de tráfego negociados ficam fora do seu alcance.

Como a alteração acontece durante o handshake, uma ligação existente estabelecida antes da regra mantém o valor antigo. Teste com uma ligação nova e espere que a primeira tentativa após a alteração seja a que lhe diz algo. Nada na regra chega a uma ligação que já está aberta. É por isso que uma correção aplicada a meio de um incidente pode parecer que não fez absolutamente nada.

Coloque a regra no caminho TCP interno

Num gateway Linux baseado em políticas, o pacote reencaminhado ainda parece TCP normal quando a firewall o vê. A política IPsec decide que o pacote será protegido; a firewall não vê um cabeçalho ESP para o fluxo interno, por isso corresponder a ESP aqui descreve um pacote completamente diferente. É essa discrepância que faz com que algumas regras pareçam corretas e nunca correspondam.

Em termos de iptables, a regra pertence à tabela mangle no caminho de reencaminhamento, restrita aos pacotes de handshake: iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1270. O número é um exemplo, não uma constante universal; deduza-o do custo de encapsulamento e do MTU real do caminho. Um equivalente em nftables define o tamanho máximo do segmento numa cadeia forward ou postrouting.

Mantenha as regras de escuta externas para IKE e ESP separadas das regras de reencaminhamento internas. Uma única regra que tenta autorizar tanto o fluxo da aplicação como o protocolo externo acaba por não corresponder de forma fiável a nenhum dos dois.

Respeite o proprietário da firewall e a ordem do NAT

Se o UFW gere a firewall do anfitrião, adicione as alterações de mangle e reencaminhamento através da sua configuração persistente suportada em vez de escrever um comando que desaparece no próximo recarregamento. Uma regra inserida na tabela errada ou depois de uma regra terminal não tem efeito, e a tabela ativa esconde isso de si.

A tradução de origem é uma decisão separada que frequentemente interage com esta. Uma exceção colocada antes de uma regra geral de masquerade impede que o tráfego protegido perca a origem que a sua política exige; não repara um problema de tamanho, e uma regra de tamanho não repara um problema de tradução.

Verifique de forma estreita e depois pare

Abra uma ligação nova ao serviço que falha e observe tanto a aplicação como os contadores da regra. Se o bloqueio desaparecer, tem provas sobre esse caminho TCP com essa encapsulamento. Não tem provas de que todos os protocolos VPN se adaptam, de que todas as aplicações UDP estão corrigidas ou de que um serviço específico a montante era a causa original.

Deixe o feedback de tamanho ICMP funcionar onde a política o permite, e trate com cuidado o ajuste automático baseado no MTU da rota quando o caminho IPsec externo não está representado pela rota interna. Quanto mais estreita for a conclusão, mais fácil será diagnosticar o próximo incidente.