Descoberta do MTU do caminho através de uma VPN: dimensionamento e a lacuna do ICMP

Um túnel conclui o handshake, pedidos pequenos voltam, e a primeira transferência grande trava. Esse padrão aponta para o MTU do caminho muito antes de apontar para a taxa de transferência. Cada enlace ao longo da rota limita o tamanho do pacote, e a encapsulação gasta parte dessa margem em cabeçalhos externos, portanto o pacote interno precisa ser menor do que a rota bruta sugeriria. A falha é silenciosa, e é isso que a torna cara de diagnosticar.

O que o MTU do caminho realmente mede

O MTU do caminho é o menor MTU de enlace na rota entre dois hosts, não o MTU impresso na sua interface local. O valor local é onde a estimativa começa, e o caminho decide onde ela deve terminar. É por isso que um túnel idêntico pode funcionar em uma rede de acesso e travar em outra: a rota mudou, não a configuração. Medir uma vez e assumir em todo lugar é o erro que mantém esse problema vivo.

Para um túnel, o número que importa é o MTU interno, que é a margem do caminho externo menos o que a encapsulação consome. O WireGuard acrescenta um cabeçalho IP externo e um cabeçalho UDP; outros transportes acrescentam os seus. Defina o tamanho interno alto demais e cada pacote de tamanho cheio precisará de fragmentação que talvez nunca aconteça.

Por que um túnel reduz o pacote utilizável

Se a interface do túnel mantém o MTU do enlace físico, cada pacote grande depende de alguém adiante disposto a fragmentá-lo. O IPv4 permite isso em princípio, mas um roteador instruído a não fragmentar devolve um erro. Roteadores IPv6 nunca fragmentam em trânsito, então a mesma configuração se comporta de forma diferente conforme a família de endereços. De qualquer forma, o remetente não aprende nada até que algo reporte de volta.

A consequência prática é um tamanho que cabe no handshake e não na carga útil. Um TLS ClientHello ou uma consulta DNS são pequenos o bastante para atravessar um caminho reduzido sem tocar, enquanto uma transferência em massa não é. Por isso os sintomas se agrupam em torno de operações específicas, e não de hosts específicos.

A descoberta só funciona quando o retorno chega

A descoberta IPv4 depende do bit don't-fragment: um roteador que não consegue encaminhar o pacote devolve ICMP fragmentation-needed com o MTU do próximo salto, e o remetente reduz sua estimativa. O IPv6 usa mensagens Packet Too Big, porque roteadores não fragmentam em trânsito. Ambos os mecanismos supõem que a mensagem encontre o caminho de volta ao remetente, através do túnel e além de qualquer firewall na rota de retorno. Quando essa suposição falha, o remetente continua a repetir um tamanho que o caminho não consegue transportar.

Um firewall que permite echo request e echo reply não necessariamente permitiu esses tipos de erro. O ICMP é uma família, e os membros que importam aqui são os erros, não o par de eco. Verifique a política de tráfego de controle nas duas pontas do túnel e na rota entre elas, e siga a orientação suportada pela plataforma em vez de permitir todos os tipos de ICMP em toda parte.

A mesma filtragem pode estar dentro do túnel. Se o caminho interno descarta o erro mas o externo o transporta, o remetente pode se adaptar a um limite que o tráfego encapsulado nunca vê de fato.

Teste o caminho em vez de adivinhar um número

Mantenha o destino, a rede de acesso e o túnel fixos, e varie apenas o tamanho do pacote. Um teste don't-fragment que falha com uma dica de MTU dá o limite do próximo salto; repita até um tamanho passar, e registre tanto o tamanho quanto a família de endereços.

ping -M do -s 1400 10.60.20.10
ping -M do -s 1300 10.60.20.10
ping -6 -M do -s 1300 2001:db8::10

Um ping que cabe não prova que os segmentos de tamanho cheio de um aplicativo real cabem, então repita o teste com a transferência que realmente falhou. Compare o maior teste que funcionou com o MTU do túnel que você configurou, e mantenha os dois números separados nas suas anotações. Se eles diferirem em cerca de um cabeçalho, você encontrou a sobrecarga da encapsulação, não um defeito.

O PLPMTUD, descrito na RFC 4821, testa para cima e usa confirmações de transporte em vez de confiar nos erros entregues. Ajuda em caminhos que filtram ICMP, mas o suporte varia por pilha e por aplicação. Um fluxo TCP pode se recuperar sozinho enquanto uma aplicação UDP com tamanho de datagrama fixo continua falhando.

Escolha um valor e registre o raciocínio

Baixar o MTU do túnel é tanto um diagnóstico quanto uma correção legítima depois que você conhece o caminho. Não substitui saber qual caminho e qual mecanismo de retorno estavam envolvidos, porque um valor ajustado para um enlace móvel será desnecessariamente pequeno em uma conexão de fibra. Registre o tamanho escolhido, o teste que o justificou e o passo de reversão.

O mecanismo IPv4 está descrito na RFC 1191 e a orientação de pacotização IPv6 na RFC 8201; nomear ambos evita que o próximo engenheiro derive a suposição de novo. Se a transferência ainda trava no tamanho escolhido, pare de baixar o número e olhe para a próxima camada. Um caminho que falha em todos os tamanhos não é um problema de MTU.