Por qué bloquear todo el ICMP rompe una ruta VPN que funciona

Un túnel que se autentica, transporta un ping y luego se cuelga en la primera transferencia grande es la firma clásica de un mensaje ICMP ausente y no de una VPN rota. El emisor nunca se entera de que un paquete era demasiado grande, reintenta el mismo tamaño y la aplicación espera. Arreglarlo es una decisión de política del cortafuegos, no reinstalar el cliente. El orden importa: mida dónde está el límite de tamaño y luego estreche la regla que se tragó el informe.

Qué transporta realmente ICMP en esta ruta

Detección de MTU de ruta IPv4 depende de que un enrutador informe de que un paquete con el bit don't-fragment activado no pudo reenviarse. Ese informe es un mensaje ICMP Fragmentation Needed y, sin él, el emisor no tiene motivo para reducir el tamaño de su segmento. IPv6 es más estricto: los enrutadores no fragmentan en tránsito, así que un mensaje ICMPv6 Packet Too Big es la única señal que hace encogerse al emisor.

Ambos mensajes son retroalimentación del plano de control y ninguno es un eco de diagnóstico. Una política que bloquea ping y otra que bloquea todo el ICMP se parecen en una lista de reglas y se comportan de forma muy distinta en la red. La segunda puede convertir un túnel bien dimensionado en una ruta de un solo sentido para cualquier cosa mayor que el enlace más pequeño de la cadena.

Algunos transportes implementan su propia detección con paquetes de sonda, como describe el RFC 4821, y dependen menos de esta retroalimentación. Eso es un argumento para comprobar qué transporte ejecuta, no para suponer que todo túnel es inmune.

El fallo depende del tamaño

Pregunte si el fallo se correlaciona con el tamaño del paquete. Una página de inicio de sesión, una consulta DNS y una llamada corta a la API pasan, mientras que una subida de archivo, una respuesta grande o una descarga de imagen se cuelgan. Ese patrón apunta a un límite de tamaño en algún punto entre los dos extremos, no a la autenticación ni al enrutamiento. Un ping pequeño exitoso no dice casi nada sobre dónde está esa frontera.

Dentro de un túnel hay dos capas que considerar: el paquete de carga útil y el paquete externo encapsulado. El emisor interno puede comportarse correctamente mientras la ruta externa es menor de lo que el túnel supone, y por eso importan tanto el ajuste de MTU propio del túnel como el enlace físico que hay debajo.

Mida antes de editar reglas

Sondee con el bit don't-fragment y un tamaño de carga útil que usted elija, desde el cliente afectado hacia una dirección protegida:

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

Una carga útil de 1472 bytes más 28 bytes de cabeceras forma un paquete de 1500 bytes. Si la sonda grande falla con un error de fragmentación y la pequeña pasa, ha encontrado la frontera; ajuste por la sobrecarga del túnel y repita hasta que el tamaño funcional sea estable.

Luego confirme que el hueco es el informe mismo. Si la sonda falla en silencio, sin error y sin respuesta, el mensaje probablemente se descarta en lugar de entregarse, y la regla es la sospechosa.

Estreche la regla y vuelva a probar la tarea

La corrección debe permitir los mensajes de control concretos, no todo el protocolo. En un host con iptables la forma es una aceptación por tipo; adapte la sintaxis a lo que gestione el cortafuegos en su plataforma:

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

Deje las respuestas de eco bloqueadas si esa es la política local, ya que la ruta no las necesita. Luego vuelva a probar la transferencia que falló originalmente, desde una conexión nueva, y confirme que los contadores de la regla muestran los mensajes llegando.

Si la transferencia grande sigue colgándose después de permitir los mensajes, el límite restante está en otro sitio: un MTU de túnel demasiado alto, un proxy que reescribe paquetes o un elemento intermedio que descarta en lugar de informar. La regla ICMP era necesaria, no suficiente.