Por que bloquear todo o ICMP quebra um caminho VPN que funciona

Um túnel que se autentica, transporta um ping e depois trava na primeira transferência grande é a assinatura clássica de uma mensagem ICMP ausente, não de uma VPN quebrada. O emissor nunca descobre que um pacote era grande demais, repete o mesmo tamanho, e a aplicação espera. Corrigir isso é uma decisão de política do firewall, não reinstalar o cliente. A ordem importa: meça onde está o limite de tamanho e depois estreite a regra que engoliu o relatório.

O que o ICMP realmente transporta neste caminho

Descoberta de MTU do caminho IPv4 depende de um roteador informar que um pacote com o bit don't-fragment ativado não pôde ser encaminhado. Esse relatório é uma mensagem ICMP Fragmentation Needed e, sem ela, o emissor não tem motivo para reduzir o tamanho do segmento. IPv6 é mais rígido: os roteadores não fragmentam em trânsito, então uma mensagem ICMPv6 Packet Too Big é o único sinal que faz o emissor encolher.

Ambas as mensagens são retorno do plano de controle e nenhuma delas é um eco de diagnóstico. Uma política que bloqueia ping e outra que bloqueia todo o ICMP parecem iguais numa lista de regras mas se comportam de forma muito diferente na rede. A segunda pode transformar um túnel corretamente dimensionado num caminho de mão única para qualquer coisa maior que o menor elo da cadeia.

Alguns transportes implementam sua própria descoberta com pacotes de sondagem, como descreve a RFC 4821, e dependem menos desse retorno. Isso é um argumento para verificar qual transporte você executa, não para supor que todo túnel é imune.

A falha depende do tamanho

Pergunte se a falha se correlaciona com o tamanho do pacote. Uma página de login, uma consulta DNS e uma chamada curta de API passam, enquanto um upload de arquivo, uma resposta grande ou um download de imagem travam. Esse padrão aponta para um limite de tamanho em algum ponto entre as duas pontas, não para autenticação ou roteamento. Um ping pequeno bem-sucedido não diz quase nada sobre onde fica essa fronteira.

Dentro de um túnel há duas camadas a considerar: o pacote de carga útil e o pacote externo encapsulado. O emissor interno pode se comportar corretamente enquanto o caminho externo é menor do que o túnel supõe, e é por isso que tanto a configuração de MTU do próprio túnel quanto o enlace físico abaixo dele importam.

Meça antes de editar regras

Sonde com o bit don't-fragment e um tamanho de carga útil que você escolher, do cliente com problema em direção a um endereço protegido:

ping -M do -s 1472 10.20.5.7
ping -M do -s 1300 10.20.5.7

Uma carga útil de 1472 bytes mais 28 bytes de cabeçalhos forma um pacote de 1500 bytes. Se a sonda grande falhar com um erro de fragmentação e a menor passar, você encontrou a fronteira; ajuste para a sobrecarga do túnel e repita até o tamanho funcional ficar estável.

Depois confirme que a lacuna é o próprio relatório. Se a sonda falhar em silêncio, sem erro e sem resposta, a mensagem provavelmente está sendo descartada em vez de entregue, e a regra é a suspeita.

Estreite a regra e depois teste a tarefa novamente

A correção deve permitir as mensagens de controle específicas, não o protocolo inteiro. Num host com iptables a forma é uma aceitação por tipo; adapte a sintaxe ao que gerencia o firewall na sua plataforma:

iptables -I INPUT -p icmp --icmp-type fragmentation-needed -j ACCEPT
ip6tables -I INPUT -p icmpv6 --icmpv6-type packet-too-big -j ACCEPT

Deixe as respostas de eco bloqueadas se essa for a política local, já que o caminho não precisa delas. Depois teste novamente a transferência que falhou originalmente, a partir de uma conexão nova, e confirme que os contadores da regra mostram as mensagens chegando.

Se a transferência grande ainda travar depois de permitir as mensagens, o limite restante está em outro lugar: um MTU de túnel alto demais, um proxy que reescreve pacotes ou um elemento intermediário que descarta em vez de relatar. A regra de ICMP era necessária, não suficiente.