Pacote IPv6 grande demais: por que transferências grandes pela VPN travam

O ping funciona, o navegador carrega uma página pequena e a transferência de arquivo trava, tudo por IPv6 no mesmo túnel. Esse padrão costuma significar que o emissor nunca aprendeu o tamanho real do caminho, e não que o túnel seja lento. O IPv6 espera que os roteadores relatem o problema com uma mensagem Packet Too Big, e a encapsulação adiciona sobrecarga antes de um pacote chegar à rede externa. Se essa mensagem for filtrada, o emissor continua repetindo um tamanho que não passa.

Solicitações pequenas, travamentos grandes

Um túnel envolve cada pacote em outro cabeçalho, então o tamanho utilizável dentro é menor que o tamanho fora. Um pacote dimensionado para o enlace físico antes da encapsulação fica grande demais depois. Os roteadores IPv4 podem fragmentar no caminho, enquanto os roteadores IPv6 não fazem isso em nome do emissor, então o emissor precisa se ajustar sozinho. E esse ajuste depende inteiramente de receber o retorno.

Uma única mensagem perdida basta para produzir o sintoma clássico: os handshakes e as respostas pequenas funcionam, e uma listagem de diretório ou um envio trava sempre no mesmo ponto. Os usuários descrevem como VPN lenta, e os registros não mostram nada errado na autenticação. As duas observações estão corretas e nenhuma delas localiza a falha.

Packet Too Big é retorno, não tráfego

Uma mensagem ICMPv6 Packet Too Big carrega o tamanho que o próximo salto pode aceitar, e o emissor a usa para baixar sua estimativa. Filtrá-la equivale a remover uma placa de trânsito e depois culpar os motoristas. Uma regra que descarta todo o ICMPv6 parece rígida e ao mesmo tempo quebra a descoberta de caminho em cada enlace que precisa dela. A mensagem é informação de controle sobre o caminho, não carga útil da aplicação.

A filtragem seletiva continua razoável. As solicitações de eco e a descoberta de vizinhos têm papel diferente das mensagens de erro, e uma política pode tratá-las de forma diferente. Siga as orientações de filtragem documentadas da plataforma em vez de aceitar ou descartar todo o protocolo, porque RFC 8201 define como esse retorno impulsiona a descoberta.

Teste as duas famílias de endereços separadamente

Teste o IPv6 isoladamente, porque uma transferência IPv4 bem-sucedida não prova nada sobre o caminho IPv6. Depois capture mensagens de controle enquanto a transferência grande trava. Os dois registros juntos mostram que o retorno está saindo, ou provam que ele nunca chegou.

ping -6 -M do -s 1400 host.internal
ip -6 route get 2001:db8:2::10
sudo tcpdump -ni any 'icmp6 and ip6[40] == 2'

A sonda envia um pacote com o bit do-not-fragment definido e relata o tamanho em que falha, que é o número que o túnel precisa acomodar. A consulta de rota nomeia a interface que levaria o destino, então você sabe qual MTU do enlace se aplica. A captura filtra ICMPv6 tipo 2, a mensagem Packet Too Big, e mostra se ela chega a este host. Se a mensagem aparece na captura e a transferência ainda trava, o emissor a ignora, o que desloca a investigação para a pilha em vez da rede.

Ajuste o tamanho do túnel só depois das evidências

Baixar o MTU do túnel pode esconder uma mensagem filtrada e fazer o sintoma desaparecer, ao custo de mais sobrecarga em cada pacote. É um contorno e não um diagnóstico, e deve seguir a captura em vez de substituí-la. Um valor baixo arbitrário também não quebra nada visível, e é por isso que sobrevive anos nas configurações. Mude-o deliberadamente, registre o valor e anote qual medição o justificou.

Quando você controla o gateway, examine a regra que descarta a mensagem em vez de desativar o firewall. Uma regra corrigida é mais estreita que uma exceção de política e muito mais fácil de defender depois. O mesmo raciocínio vale para os tempos limite: nem toda parada é um problema de tamanho, e a captura é o que separa os dois.