Ping a través de una VPN: por qué las reglas de respuesta de eco se pierden la vuelta

Haga ping a un host a través de una VPN y la petición sale con un tipo ICMP y vuelve con otro, lo que basta para confundir cualquier regla escrita en términos de puertos. No hay ningún puerto de servicio de destino en un intercambio de eco que copiar en la regla de vuelta, y un filtro que espera simetría descartará la respuesta mientras la petición pasa sin obstáculos. La corrección empieza por leer el paquete tal como es y luego decidir qué frontera del camino toma la decisión. Normalmente trabajan dos capas mientras la tercera descarta la respuesta en silencio. Las secciones siguientes las separan en el orden en que un paquete las encuentra.

El paquete cambia de tipo, no de puerto

Una petición de eco es ICMP de tipo 8, código 0, y lleva un identificador y un número de secuencia. La respuesta es de tipo 0, código 0, con el mismo identificador y la misma secuencia, y los extremos IP intercambiados. RFC 792 define esos campos, y el identificador es lo que permite a un emisor emparejar las respuestas con sus propias peticiones.

Lo que falta es igual de importante: no hay cabecera TCP ni UDP, así que no hay puerto que permitir. Una regla que nombra un puerto para una respuesta de eco describe un paquete que nunca existirá. Es el error más común en los tiques de ping por VPN. La regla parece específica, no se aplica a nada y deja el fallo exactamente donde estaba.

Tres contextos deciden el paquete

Si el ping apunta a un host de la LAN remota, la pasarela debe reenviar la petición. Si apunta a una dirección que pertenece a la propia pasarela, termina en la ruta de entrada local. Si la pasarela origina el ping, el paquete comienza en su propia ruta de salida y nunca cruza la decisión de reenvío.

Esos tres contextos tienen cadenas de reglas y contadores distintos, y tratarlos como uno solo es la razón por la que «el cortafuegos permite ICMP» puede seguir produciendo un ping fallido. El túnel exterior es un cuarto contexto: permitir el escucha de la VPN no permite automáticamente la petición interna desencapsulada, y un permiso interno no dice nada sobre si el túnel exterior está levantado.

Los filtros con estado y sin estado tratan la respuesta de forma distinta

Un cortafuegos con estado que vio salir la petición puede asociar la respuesta a ese flujo y admitirla sin una segunda regla. Un filtro sin estado no tiene esa memoria, así que la dirección de vuelta necesita su propio permiso explícito, con el origen y el destino invertidos.

Compruebe qué modelo implementa realmente el producto antes de escribir nada. Una regla para la petición de eco no cubre necesariamente la respuesta de eco, y un producto que sigue consultas ICMP puede aplicar otra política a las respuestas que llegan por otra interfaz.

Limite lo que permite. Permitir todas las respuestas de eco desde cualquier lugar no es lo mismo que completar una asociación con estado, y un número de tipo no autentica al emisor.

La traducción también cambia el identificador

Si la traducción de origen es intencionada, la tupla del extremo remoto no coincide con la que envió el cliente. Un NAT puede traducir el identificador de la consulta ICMP junto con las direcciones, así que insistir en que el mismo número aparezca en ambos lados produce una discrepancia falsa.

Correlacione en cambio la correspondencia que informa el traductor. Un traductor que reescribe el identificador no conservará el número que registró su cliente, así que trate la correspondencia como la identidad y no el número. Luego siga una petición identificable por el camino: confirme que llega al destino con el origen esperado, confirme que el destino emitió una respuesta, siga la ruta de esa respuesta de vuelta, y confirme que el cliente la recibió en lugar de limitarse a ver subir un contador de la pasarela.

No mezcle los errores ICMP con la política de eco

El mensaje «se necesita fragmentación» que usa el descubrimiento de MTU de camino no es una respuesta de eco, y su carga útil cita el paquete que lo provocó. Un permiso solo de eco que descarta esos errores en silencio convierte un problema de tamaño en una conexión colgada, que es lo contrario de útil.

La misma precaución vale para las familias de direcciones. ICMPv6 usa tipos de mensaje distintos y transporta funciones esenciales que IPv4 no tiene, así que copiar estos números en una regla IPv6 es sencillamente un error.

Cuando el intercambio de eco funcione, pruebe la aplicación real por separado. Un ping correcto demuestra la ida y vuelta de un protocolo, a un tamaño y a un destino, y no es una licencia para suponer que HTTPS, SMB o cualquier otro flujo esté permitido.