Os pings funcionam, as transferências grandes travam e o túnel se declara saudável. Alguém baixa a MTU da interface, outro ajusta a MSS e, de vez em quando, o problema desaparece por motivos que ninguém registra. Os dois números descrevem objetos diferentes, então mudar o errado produz uma correção que parece sorte. Este é o procedimento: identifique a camada, aplique o ajuste correspondente e depois teste numa conexão nova.

Dois números, dois objetos

A MTU pertence a um link ou a uma interface: é o maior pacote que pode ser entregue sem ser dividido. A MSS pertence ao TCP: é a maior quantidade de carga TCP que um segmento pode carregar, e exclui tanto o cabeçalho TCP quanto o IP. Num link Ethernet comum com IPv4, uma MTU de 1500 bytes dá a conhecida MSS de 1460 bytes. Esses números descrevem camadas diferentes e são trocados por mecanismos diferentes. Confundi-los é fácil porque ambos são medidos em bytes e ambos ficam perto de 1500.

Um chega como ajuste da interface. O outro chega como opção dentro de um segmento SYN, negociada entre extremos que nunca veem a sua interface.

Onde a sobrecarga externa aterrissa

Uma VPN coloca o pacote interno dentro de outro, e o pacote externo precisa caber no caminho físico. Os cabeçalhos de encapsulamento, o cabeçalho IP externo, o cabeçalho de transporte e qualquer etiqueta de autenticação consomem bytes que o pacote interno não pode usar. Deixe a interface do túnel em 1500 e o pacote externo rotineiramente excede o que o caminho consegue transportar. Com o bit 'não fragmentar' definido, o roteador o descarta e deveria devolver um erro ICMP; se esse erro for filtrado, o emissor nunca fica sabendo.

É por isso que a falha parece seletiva. Pedidos pequenos concluem e tudo o que enche um segmento engasga, porque só os pacotes grandes são descartados. Um túnel que passa um ping não é um túnel que transporta dados.

Ajustar a MSS, e onde isso se aplica

O ajuste da MSS reescreve o valor no segmento SYN quando ele atravessa um ponto escolhido, o que faz os dois extremos escolherem uma carga menor sem que nenhum saiba por quê. No Linux é um alvo da tabela mangle aplicado por uma regra explícita, e precisa atingir os pacotes SYN na direção que você pretende. Limite-o à interface do túnel e à faixa de endereços, porque uma regra ampla muda o comportamento de tráfego que nunca entra no túnel.

O efeito é só no TCP. Uma aplicação UDP, uma sessão QUIC e qualquer protocolo que construa os próprios datagramas não são afetados.

Diagnostique com um caminho fixo

Mantenha uma variável de cada vez. Teste com um pacote cujo tamanho você escolhe, e defina o sinalizador 'não fragmentar' para que o kernel informe o resultado em vez de escondê-lo.

Anote onde a falha começa: dentro do túnel, na interface do túnel ou no caminho físico após a encapsulação. Depois mude um número e repita o mesmo teste, não outro. As conexões existentes mantêm a MSS negociada, então uma mudança de política só é visível numa conexão nova, e por isso uma página em cache não prova nada em nenhuma direção. Se um envio grande começar a funcionar, você aprendeu sobre aquele caminho e não sobre cada protocolo nele.

O que cada mudança não corrige

Baixar a MTU da interface não altera a MSS de uma sessão já estabelecida. Ajustar a MSS não ajuda um fluxo UDP e não conserta um caminho onde os erros ICMP são filtrados numa única direção. Cada mudança corrige uma classe de problema e deixa o resto exatamente como estava.

Anote qual ajuste você aplicou, onde e qual teste mostrou a diferença, porque senão o próximo engenheiro aplica os dois e perde a capacidade de dizer qual importava. Se a restrição for real e permanente, prefira uma MTU de túnel que a reflita a um ajuste que a esconda. Se precisar ajustar, deixe a regra limitada e comentada, já que uma regra mangle sem explicação se torna permanente por padrão.

Artigos relacionados