Por que bloquear todo o ICMP rompe unha ruta VPN que funciona

Un túnel que se autentica, transporta un ping e logo colga na primeira transferencia grande é a sinatura clásica dunha mensaxe ICMP ausente e non dunha VPN rota. O emisor nunca sabe que un paquete era demasiado grande, reintenta o mesmo tamaño e a aplicación espera. Arranxalo é unha decisión de política da devasa, non reinstalar o cliente. A orde importa: mida onde está o límite de tamaño e despois estreite a regra que tragou o informe.

Que transporta realmente ICMP nesta ruta

Descubrimento do MTU de ruta IPv4 depende de que un encamiñador informe de que un paquete co bit don't-fragment activado non puido reenviarse. Ese informe é unha mensaxe ICMP Fragmentation Needed e, sen ela, o emisor non ten motivo para reducir o tamaño do seu segmento. IPv6 é máis estrito: os encamiñadores non fragmentan en tránsito, así que unha mensaxe ICMPv6 Packet Too Big é o único sinal que fai encoller o emisor.

Ambas mensaxes son retroalimentación do plano de control e ningunha é un eco de diagnóstico. Unha política que bloquea ping e outra que bloquea todo o ICMP parecen iguais nunha lista de regras e compórtanse de forma moi distinta na rede. A segunda pode converter un túnel ben dimensionado nunha ruta dun só sentido para calquera cousa maior que a ligazón máis pequena da cadea.

Algúns transportes implementan o seu propio descubrimento con paquetes de sonda, como describe o RFC 4821, e dependen menos desta retroalimentación. Iso é un argumento para comprobar que transporte executa, non para supor que todo túnel é inmune.

O fallo depende do tamaño

Pregunte se o fallo se correlaciona co tamaño do paquete. Unha páxina de inicio de sesión, unha consulta DNS e unha chamada curta á API pasan, mentres que unha subida de ficheiro, unha resposta grande ou unha descarga de imaxe colgan. Ese patrón apunta a un límite de tamaño nalgún punto entre os dous extremos, non á autenticación nin ao encamiñamento. Un ping pequeno exitoso non di case nada sobre onde está esa fronteira.

Dentro dun túnel hai dúas capas que considerar: o paquete de carga útil e o paquete externo encapsulado. O emisor interno pode comportarse correctamente mentres a ruta externa é menor do que o túnel supón, e por iso importan tanto o axuste de MTU propio do túnel como a ligazón física que hai debaixo.

Mida antes de editar regras

Sondee co bit don't-fragment e un tamaño de carga útil que vostede elixa, desde o cliente afectado cara a un enderezo protexido:

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

Unha carga útil de 1472 bytes máis 28 bytes de cabeceiras forma un paquete de 1500 bytes. Se a sonda grande falla cun erro de fragmentación e a pequena pasa, atopou a fronteira; axuste pola sobrecarga do túnel e repita ata que o tamaño funcional sexa estable.

Despois confirme que o oco é o propio informe. Se a sonda falla en silencio, sen erro e sen resposta, a mensaxe probablemente descártase en lugar de entregarse, e a regra é a sospeitosa.

Estreite a regra e volva probar a tarefa

A corrección debe permitir as mensaxes de control concretas, non todo o protocolo. Nun host con iptables a forma é unha aceptación por tipo; adapte a sintaxe ao que xestione a devasa na súa 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 esa é a política local, xa que a ruta non as necesita. Despois volva probar a transferencia que fallou orixinalmente, desde unha conexión nova, e confirme que os contadores da regra mostran as mensaxes chegando.

Se a transferencia grande segue colgando despois de permitir as mensaxes, o límite restante está noutro sitio: un MTU de túnel demasiado alto, un proxy que reescribe paquetes ou un elemento intermedio que descarta en lugar de informar. A regra ICMP era necesaria, non suficiente.