Ping per una VPN: per què les regles de resposta d’eco es perden el camí de tornada

Feu ping a un amfitrió a través d’una VPN i la petició surt amb un tipus ICMP i torna amb un altre, cosa que n’hi ha prou per confondre qualsevol regla escrita en termes de ports. No hi ha cap port de servei de destinació en un intercanvi d’eco que es pugui copiar a la regla de tornada, i un filtre que espera simetria descartarà la resposta mentre la petició passa sense entrebancs. La correcció comença llegint el paquet tal com és i després decidint quina frontera del camí pren la decisió. Normalment funcionen dues capes mentre la tercera descarta la resposta en silenci. Les seccions següents les separen en l’ordre en què un paquet les troba.

El paquet canvia de tipus, no de port

Una petició d’eco és ICMP tipus 8, codi 0, i porta un identificador i un número de seqüència. La resposta és tipus 0, codi 0, amb el mateix identificador i la mateixa seqüència, i els extrems IP intercanviats. L’RFC 792 defineix aquests camps, i l’identificador és el que permet a l’emissor aparellar les respostes amb les seves pròpies peticions.

El que hi falta és igual d’important: no hi ha cap capçalera TCP ni UDP, així que no hi ha cap port a permetre. Una regla que anomena un port per a una resposta d’eco descriu un paquet que no existirà mai. És l’error més habitual en els tiquets de ping per VPN. La regla sembla específica, no s’aplica a res i deixa la fallada exactament on era.

Tres contextos decideixen el paquet

Si el ping apunta a un amfitrió de la LAN remota, la petició l’ha de reenviar la passarel·la. Si apunta a una adreça que pertany a la mateixa passarel·la, acaba al camí d’entrada local. Si és la passarel·la qui origina el ping, el paquet comença al seu propi camí de sortida i no travessa mai la decisió de reenviament.

Aquests tres contextos tenen cadenes de regles i comptadors diferents, i tractar-los com un de sol és la raó per la qual «el tallafoc permet ICMP» encara pot produir un ping fallit. El túnel exterior és un quart context: permetre l’oient de la VPN no permet automàticament la petició interna desencapsulada, i un permís intern no diu res sobre si el túnel exterior està actiu.

Els filtres amb estat i sense estat tracten la resposta de manera diferent

Un tallafoc amb estat que ha vist sortir la petició pot associar la resposta amb aquell flux i admetre-la sense una segona regla. Un filtre sense estat no té aquesta memòria, així que la direcció de tornada necessita la seva pròpia autorització explícita, amb l’origen i la destinació invertits.

Comproveu quin model implementa realment el producte abans d’escriure res. Una regla per a la petició d’eco no cobreix necessàriament la resposta d’eco, i un producte que segueix consultes ICMP pot aplicar una política diferent a les respostes que arriben per una altra interfície.

Limiteu allò que permeteu. Permetre totes les respostes d’eco de qualsevol lloc no és el mateix que completar una associació amb estat, i un número de tipus no autentica l’emissor.

La traducció també canvia l’identificador

Si la traducció d’origen és intencionada, la tupla de l’extrem remot no coincideix amb la que va enviar el client. Un NAT pot traduir l’identificador de consulta ICMP juntament amb les adreces, així que insistir que el mateix número aparegui als dos costats produeix una discrepància falsa.

Correlacioneu en canvi la correspondència que informa el traductor. Un traductor que reescriu l’identificador no conservarà el número que el vostre client va registrar, així que tracteu la correspondència com la identitat i no el número. Després seguiu una petició identificable pel camí: confirmeu que arriba a la destinació amb l’origen esperat, confirmeu que la destinació ha emès una resposta, seguiu la ruta d’aquesta resposta de tornada, i confirmeu que el client l’ha rebuda en lloc de només mirar com puja un comptador de la passarel·la.

No barregeu els errors ICMP amb la política d’eco

El missatge «cal fragmentació» que fa servir el descobriment de MTU del camí no és una resposta d’eco, i la seva càrrega cita el paquet que el va provocar. Un permís només per a l’eco que descarta silenciosament aquests errors converteix un problema de mida en una connexió penjada, que és el contrari d’útil.

La mateixa precaució val per a les famílies d’adreces. ICMPv6 fa servir tipus de missatge diferents i porta funcions essencials que IPv4 no té, així que copiar aquests números en una regla IPv6 és simplement un error.

Quan l’intercanvi d’eco funcioni, proveu l’aplicació real per separat. Un ping correcte demostra l’anada i tornada d’un protocol, a una mida i a una destinació, i no és cap llicència per suposar que HTTPS, SMB o qualsevol altre flux estigui permès.