Ping a través dunha VPN: por que as regras de resposta de eco perden a volta

Facede ping a un host a través dunha VPN e a petición sae cun tipo ICMP e volve con outro, o que abonda para confundir calquera regra escrita en termos de portos. Non hai ningún porto de servizo de destino nun intercambio de eco que copiar na regra de volta, e un filtro que espera simetría descartará a resposta mentres a petición pasa sen atrancos. A corrección comeza lendo o paquete tal como é e despois decidindo que fronteira do camiño toma a decisión. Normalmente traballan dúas capas mentres a terceira descarta a resposta en silencio. As seccións seguintes sepáranas na orde en que un paquete as atopa.

O paquete cambia de tipo, non de porto

Unha petición de eco é ICMP de tipo 8, código 0, e leva un identificador e un número de secuencia. A resposta é de tipo 0, código 0, co mesmo identificador e a mesma secuencia, e os extremos IP intercambiados. RFC 792 define eses campos, e o identificador é o que permite a un emisor emparellar as respostas coas súas propias peticións.

O que falta é igual de importante: non hai cabeceira TCP nin UDP, así que non hai porto que permitir. Unha regra que nomea un porto para unha resposta de eco describe un paquete que nunca existirá. É o erro máis común nos tíquets de ping por VPN. A regra parece específica, non se aplica a nada e deixa o fallo exactamente onde estaba.

Tres contextos deciden o paquete

Se o ping apunta a un host da LAN remota, a pasarela debe reenviar a petición. Se apunta a un enderezo que pertence á propia pasarela, remata na ruta de entrada local. Se a pasarela orixina o ping, o paquete comeza na súa propia ruta de saída e nunca cruza a decisión de reenvío.

Eses tres contextos teñen cadeas de regras e contadores distintos, e tratalos como un só é a razón pola que «a devasa permite ICMP» pode seguir producindo un ping fallido. O túnel exterior é un cuarto contexto: permitir o escoitador da VPN non permite automaticamente a petición interna desencapsulada, e un permiso interno non di nada sobre se o túnel exterior está levantado.

Os filtros con estado e sen estado tratan a resposta de forma distinta

Unha devasa con estado que viu saír a petición pode asociar a resposta a ese fluxo e admitila sen unha segunda regra. Un filtro sen estado non ten esa memoria, así que a dirección de volta necesita o seu propio permiso explícito, coa orixe e o destino invertidos.

Comprobade que modelo implementa realmente o produto antes de escribir nada. Unha regra para a petición de eco non cobre necesariamente a resposta de eco, e un produto que segue consultas ICMP pode aplicar outra política ás respostas que chegan por outra interface.

Limitade o que permitides. Permitir todas as respostas de eco desde calquera lugar non é o mesmo que completar unha asociación con estado, e un número de tipo non autentica o emisor.

A tradución tamén cambia o identificador

Se a tradución de orixe é intencionada, a tupla do extremo remoto non coincide coa que enviou o cliente. Un NAT pode traducir o identificador da consulta ICMP xunto cos enderezos, así que insistir en que o mesmo número apareza nos dous lados produce unha discrepancia falsa.

Correlacionade en cambio a correspondencia que informa o tradutor. Un tradutor que reescribe o identificador non conservará o número que rexistrou o voso cliente, así que tratade a correspondencia como a identidade e non o número. Despois seguiu unha petición identificable polo camiño: confirmade que chega ao destino coa orixe esperada, confirmade que o destino emitiu unha resposta, seguide a ruta desa resposta de volta, e confirmade que o cliente a recibiu en vez de só mirar como sobe un contador da pasarela.

Non mesturedes os erros ICMP coa política de eco

A mensaxe «cómpre fragmentación» que usa o descubrimento de MTU do camiño non é unha resposta de eco, e a súa carga útil cita o paquete que a provocou. Un permiso só de eco que descarta eses erros en silencio converte un problema de tamaño nunha conexión pendurada, que é o contrario de útil.

A mesma precaución vale para as familias de enderezos. ICMPv6 usa tipos de mensaxe distintos e leva funcións esenciais que IPv4 non ten, así que copiar estes números nunha regra IPv6 é simplemente un erro.

Cando o intercambio de eco funcione, probade a aplicación real por separado. Un ping correcto demostra a ida e volta dun protocolo, nun tamaño e a un destino, e non é unha licenza para supor que HTTPS, SMB ou calquera outro fluxo está permitido.