Túneis VPN aninhados: porque é que o interior encrava em pacotes grandes

O DNS resolve, a sessão SSH mantém-se e então um upload grande congela enquanto um ping ao mesmo host continua a responder. Essa divisão aponta para o tamanho do pacote e não para um túnel avariado. Os túneis aninhados chegam lá em tamanhos que nenhum dos dois alcançaria sozinho. A sessão interna está bem; está apenas a receber pacotes que já não cabem.

Para onde vai realmente a MTU do caminho

Cada encapsulamento gasta bytes antes de a camada seguinte ter a sua vez. Um caminho Ethernet oferece 1500 bytes ao pacote exterior, e o túnel exterior leva a sua parte antes de qualquer coisa lá dentro poder ser endereçada. Um único valor de sobrecarga estimado estará errado exatamente na quantidade que importa.

Enumere as camadas por ordem: caminho de acesso, transporte exterior, túnel exterior, transporte interior, túnel interior, aplicação. Conte cada cabeçalho uma vez e mantenha o UDP separado do cabeçalho e da etiqueta do próprio túnel.

Duas camadas WireGuard, contadas uma vez

Pegue num caminho de acesso IPv4 com um túnel WireGuard dentro de outro. A camada exterior custa 20 bytes de IPv4, 8 de UDP e 32 para o cabeçalho de dados do WireGuard mais a sua etiqueta de autenticação. Lá dentro, o túnel interior precisa do seu próprio cabeçalho IPv4 de 20 bytes e de um cabeçalho UDP de 8 bytes antes dos seus segundos 32 bytes de sobrecarga WireGuard. O que sobra contém um cabeçalho IPv4, um cabeçalho TCP e os dados. Um caminho exterior IPv6 custa 40 em vez de 20 e deixa 1320.

A aritmética chega aos 1340 bytes. Uma só camada com as mesmas regras deixa 1400 para a carga útil TCP, ou seja, 1500 menos 20, 8, 32, 20 e 20, e a diferença de 60 bytes é exatamente o encapsulamento interior que o segundo túnel acrescenta.

Aplique 1400 a um caminho aninhado e o túnel interior fica 60 bytes curto, invisível até um pacote ser grande o suficiente para precisar deles. O preenchimento e a opção de fragmentação do próprio protocolo voltam a mover os números, por isso confie na tabela.

MTU, MSS e fragmentação atuam em locais diferentes

A MTU da interface limita o que a interface emite, enquanto o clamping de MSS do TCP muda o que um par TCP está disposto a enviar. O clamping corrige as sessões TCP e não faz nada por um datagrama UDP grande, e é assim que uma correção parece bem-sucedida numa aplicação e falha em silêncio na seguinte. A opção de fragmentação do próprio protocolo é uma terceira alavanca com as suas próprias falhas. A MTU da interface é o primeiro movimento comum e o mais grosseiro.

Os túneis com ponte e encaminhados transportam tramas diferentes, por isso os números de outra implementação raramente se transferem. A descoberta de MTU do caminho, descrita na RFC 8201, só ajuda enquanto as mensagens ICMP de que depende forem deixadas passar.

Encontrar a camada que fica curta

Verifique cada túnel isoladamente antes de os aninhar, se os requisitos permitirem uma comparação. Uma sonda de tamanho fixo decide-o: ping -M do -s 1472 -c 3 10.8.0.1 envia um pacote IPv4 completo de 1500 bytes dentro dessa camada. Acrescente a segunda camada e repita a mesma sonda, para que qualquer falha pertença a uma alteração conhecida.

Quando uma transferência encrava, mude um parâmetro documentado de cada vez e registe o tamanho que falha. Verifique também o caminho de regresso, porque a recursão de rotas aninhada pode imitar um problema de tamanho de pacote suficientemente bem para custar uma tarde. Uma resposta ICMP filtrada pode esconder o limite real, por isso a sonda importa mais do que o raciocínio.

Escreva o orçamento onde a próxima pessoa o encontre

Uma tabela com uma linha por camada sobrevive a uma regra prática. Mantenha-a ao lado do diagrama do túnel para que ninguém refaça a aritmética sob pressão.

Mais túneis significam mais dependências, por isso um plano de reversão merece o seu lugar ao lado do orçamento. Se os números ainda não baterem certo, meça o caminho em vez de voltar a adivinhar. O objetivo é uma cifra que possa defender, não memorizar.