A sobrecarga do IPsec: o modo, o NAT-T e os algoritmos mudam tudo

Em algum lugar de um guia há um número, normalmente entre sessenta e oitenta bytes, que alguém subtraiu de 1500 para obter uma MTU de interface. Esse número descreve um encapsulamento específico num caminho específico. Mude o modo, a família de endereços exterior, a cifra ou a presença de NAT, e a aritmética já não se aplica ao seu túnel.

O número veio de outro túnel

A sobrecarga não é uma propriedade do IPsec em abstrato. É uma propriedade do pacote que realmente é construído: um modo negociado, um cabeçalho exterior, um cabeçalho de proteção, preenchimento, um campo de integridade e possivelmente um invólucro UDP adicional.

Uma cifra citada para o modo transporte com IPv4 e sem NAT descreve um pacote mais pequeno do que o modo túnel com IPv6 sob travessia de NAT. Ambas estão corretas para o seu próprio caso. Copiar qualquer delas para uma implementação diferente é como as pessoas acabam com uma MTU que quebra as transferências grandes. A falha é silenciosa porque os pedidos pequenos continuam a funcionar.

Some as camadas que realmente estão lá

Comece pelo cabeçalho IP exterior e avance para dentro. No modo túnel o pacote original está lá dentro, por isso o cabeçalho exterior é um acréscimo e não uma substituição. RFC 4303 descreve o cabeçalho ESP, o preenchimento e os dados de integridade que se seguem.

Nenhuma dessas linhas é constante entre implementações, e a linha do preenchimento não é constante nem dentro de uma única implementação. É essa a razão de uma única cifra publicada de sobrecarga dececionar.

Dois locais podem discordar sobre o mesmo túnel

O pacote protegido continua a ter de atravessar o caminho exterior, e o caminho exterior não é o mesmo em todo o lado. Uma ligação de acesso PPPoE transporta menos do que um segmento Ethernet limpo. Uma rede móvel pode encolher mais, e um fornecedor que encapsula o seu próprio tráfego acrescenta outro encapsulamento que ninguém mencionou. Um túnel que funciona numa ligação e falha noutra está a descrever a segunda ligação, não o protocolo.

As duas direções também podem diferir. Uma rota assimétrica pode dar-lhe um envio que funciona e uma receção bloqueada, o que se lê como um problema da aplicação até olhar para os tamanhos dos pacotes em vez da alcançabilidade. Um ping pequeno que passa prova muito pouco sobre uma resposta de tamanho completo.

Meça em vez de subtrair

Encontre o maior datagrama que sobrevive ao caminho. Depois compare-o com o valor que a interface reporta:

ip link show eth0 | grep -o 'mtu [0-9]*'
ip xfrm state list
ping -M do -s 1400 198.51.100.7
ping -M do -s 1372 198.51.100.7
tcpdump -ni any -c 20 'esp or udp port 4500'

Baixe o tamanho do ping até chegarem respostas, e trate o maior valor que funciona como o orçamento desse caminho. A saída do xfrm diz-lhe que modo e que algoritmos foram negociados, e é essa a entrada de qualquer cálculo honesto. A captura confirma se no cabo está ESP ou ESP encapsulado em UDP, e isso resolve a questão do NAT sem adivinhar.

Reserve também um valor para o plano de controlo. Os pacotes de aperto de mão do IKE têm uma estrutura diferente da dos pacotes de dados, por isso um tamanho derivado de uma captura de aperto de mão não é uma MTU do plano de dados.

Ponha o número onde ele pertence

Para TCP através de um túnel, um ajuste de MSS é muitas vezes o controlo menos invasivo, porque reduz o que os extremos enviam sem alterar o próprio túnel. Para um túnel baseado em rotas, defina a MTU da interface do túnel deliberadamente e documente porquê. Fazer as duas coisas ao mesmo tempo e depois medir não lhe diz nada sobre qual ajudou.

Mantenha juntos no ticket o modo negociado, a família exterior, a condição de NAT e o sintoma reproduzível. Um conjunto registado de quatro factos vence uma constante memorizada, e é a única versão disto que sobrevive à próxima atualização do cliente.