Mitos do MTU na VPN: por que os seus pacotes encolhem e para onde vai o espaço

Alguém lhe diz que a VPN "está a perder pacotes por causa do MTU", você põe o túnel em 1400 e a transferência volta a funcionar. Esse resultado parece um diagnóstico. Normalmente é uma coincidência aritmética: escolheu um número suficientemente pequeno para caber debaixo de um limite que nunca identificou, e vai encontrar o mesmo limite na próxima rede com um orçamento diferente.

Dois mitos causam a maior parte disto. O primeiro é que o MTU da interface do túnel é o MTU do caminho. O segundo é que o encapsulamento custa "um cabeçalho" e que o PPPoE não custa nada que valha a pena contar. Ambos estão errados de formas que fazem o número escolhido parecer arbitrário quando na verdade é determinado.

Mito um: o MTU do túnel é o MTU do caminho

O valor que define numa interface de túnel é uma promessa local sobre o maior pacote interno que a implementação vai entregar para baixo. A capacidade real do caminho é uma propriedade de cada ligação entre você e o extremo remoto, e pode mudar quando uma rota muda, quando uma ligação móvel é transferida ou quando o tráfego toma outro peering. Um 1500 configurado diz-lhe o que o seu host vai construir, não o que a rede vai transportar.

A descoberta do MTU do caminho existe para reconciliar os dois, e depende de feedback. Em IPv4, um router que não consegue encaminhar um pacote de tamanho completo deve enviar uma mensagem ICMP "fragmentation needed", e o emissor baixa a sua estimativa. Em IPv6, o equivalente é uma mensagem Packet Too Big, e os routers não fragmentam nada em trânsito. Quando esse feedback é filtrado, o emissor continua a produzir pacotes que o caminho não consegue transportar, e nada lhe diz porquê.

Mito dois: o encapsulamento custa um cabeçalho

Conte as camadas externas com honestidade. Um cabeçalho IP externo tem 20 bytes em IPv4 ou 40 em IPv6. O encapsulamento UDP para atravessar NAT acrescenta 8. O protocolo do túnel acrescenta o seu próprio cabeçalho, um vetor de inicialização ou nonce, preenchimento até ao limite de bloco ou alinhamento da cifra, um trailer e um valor de verificação de integridade. Consoante o protocolo e a cifra, o total fica confortavelmente nas dezenas de bytes antes de o pacote interno sequer começar.

Depois subtraia novamente os cabeçalhos do próprio pacote interno. Um segmento TCP dentro do túnel transporta o seu próprio cabeçalho IP de 20 bytes e cabeçalho TCP de 20 bytes, e o MSS do TCP deriva do MTU, não da carga útil nominal do túnel. É por isso que ping com uma carga menor pode ter sucesso enquanto uma transferência de ficheiro encrava: as ferramentas testam coisas diferentes, e só uma delas exercita um segmento TCP de tamanho completo.

ip link show tun0
ping -M do -s 1472 192.0.2.10
ping -M do -s 1400 192.0.2.10

O primeiro comando reporta o MTU configurado do túnel. As duas sondas enviam uma carga de 1472 bytes, que com 28 bytes de cabeçalhos IPv4 e ICMP é um pacote de 1500 bytes, e depois uma menor. Se a sonda grande falhar por completo e a pequena tiver sucesso, tem uma falha dependente do tamanho e não um problema geral de encaminhamento.

Mito três: o PPPoE ainda lhe dá 1500 limpos

Uma ligação de acesso PPPoE convencional não transporta um pacote IP de 1500 bytes. O cabeçalho PPPoE mais o campo de protocolo PPP ocupam 8 bytes dentro da trama Ethernet, deixando 1492 para o pacote IP. Esse é o limite tradicional descrito na RFC 2516. Se correr uma VPN sobre essa ligação, a sobrecarga do túnel vem desses 1492, não de 1500.

A RFC 4638 define uma forma de negociar uma carga PPP maior quando tanto o concentrador de acesso como o equipamento do cliente o suportam, e por isso "esta ligação usa PPPoE" sozinho não prova um número concreto. Uma definição local não pode obrigar um dispositivo intermédio a aceitar um pacote para o qual nunca foi configurado, pelo que a pergunta útil é o que a ligação negociou de facto, não o que diz a etiqueta.

Porque a falha parece seletiva

Que os pedidos pequenos tenham sucesso e as transferências grandes encravem é a assinatura clássica de um buraco negro de MTU do caminho. O aperto de mão, a consulta DNS e a chamada API cabem todos; a transferência massiva produz segmentos de tamanho completo que morrem numa ligação, e a mensagem ICMP que devia ter reportado o problema nunca chega. A ligação parece bem e a descarga pendura, o que leva as pessoas a olhar para o servidor em vez do caminho.

Um segundo erro relacionado é confundir três números: o MTU da interface, o MSS do TCP e a definição de fragmentação ou preenchimento do próprio protocolo. O aperto de MSS num router reescreve o MSS anunciado para que o emissor construa segmentos menores; não muda o MTU do túnel e não ajuda o tráfego UDP. Dar o mesmo número aos três porque parecem relacionados é como uma configuração que funciona se estraga por uma alteração bem-intencionada.

O que alterar e em que ordem

Comece por provas. Confirme com as sondas acima que a falha depende do tamanho e depois encontre o tamanho mais pequeno que passa e o maior que falha. Verifique o MTU real da ligação de acesso antes de culpar o túnel; uma ligação PPPoE limita o orçamento antes de a VPN lhe tocar. Anote os valores originais para que a alteração possa ser revertida.

Depois aplique o ajuste mais pequeno que o cliente documenta. Muitos clientes oferecem um MTU de túnel mais uma opção de correção de MSS, e a opção MSS é muitas vezes a melhor alavanca para TCP porque chega ao emissor sem reduzir cada pacote. Teste de novo o mesmo destino e a mesma transferência, e anote os números com que ficou. Um valor de túnel que funciona numa rede de acesso não é uma constante universal, e o próximo local terá o seu próprio orçamento.