Ping door een VPN: waarom regels voor echo-antwoorden de terugweg missen

Ping een host door een VPN en het verzoek vertrekt met het ene ICMP-type en komt terug met het andere, wat genoeg is om elke regel die in poorten is geschreven in de war te brengen. In een echowisseling is er geen doelservicepoort om in de terugregel te kopiëren, en een filter dat symmetrie verwacht, laat het antwoord vallen terwijl het verzoek ongehinderd passeert. De correctie begint met het pakket te lezen zoals het werkelijk is, en daarna te bepalen welke grens op het pad de beslissing neemt. Meestal werken twee lagen terwijl de derde het antwoord stil laat vallen. De secties hieronder scheiden ze in de volgorde waarin een pakket ze tegenkomt.

Het pakket wisselt van type, niet van poort

Een echo-verzoek is ICMP-type 8, code 0, en draagt een identificatie en een volgnummer. Het antwoord is type 0, code 0, met dezelfde identificatie en hetzelfde volgnummer, en de IP-eindpunten omgewisseld. RFC 792 definieert die velden, en de identificatie is wat een afzender in staat stelt antwoorden aan zijn eigen verzoeken te koppelen.

Wat ontbreekt is even belangrijk: er is geen TCP- of UDP-header, dus er is geen poort om toe te staan. Een regel die een poort noemt voor een echo-antwoord beschrijft een pakket dat nooit zal bestaan. Dit is de meest voorkomende fout in VPN-pingtickets. De regel lijkt specifiek, geldt voor niets en laat de storing precies waar die was.

Drie contexten beslissen over het pakket

Als de ping een host op de verre LAN als doel heeft, moet de gateway het verzoek doorsturen. Als hij een adres als doel heeft dat bij de gateway zelf hoort, eindigt het in het lokale invoerpad. Als de gateway de ping zelf start, begint het pakket in zijn eigen uitvoerpad en kruist het de doorstuur beslissing helemaal niet.

Die drie contexten hebben verschillende regelketens en verschillende tellers, en ze als één behandelen is de reden dat „de firewall staat ICMP toe” toch een mislukte ping kan opleveren. De buitenste tunnel is een vierde context: de VPN-listener toestaan staat het gedekapsuleerde binnenste verzoek niet automatisch toe, en een binnenste toestemming zegt niets over of de buitenste tunnel actief is.

Stateful en stateless filters behandelen het antwoord verschillend

Een stateful firewall die het verzoek zag vertrekken, kan het antwoord aan die stroom koppelen en het zonder tweede regel doorlaten. Een stateless filter heeft zo’n geheugen niet, dus de terugrichting heeft zijn eigen uitdrukkelijke toestemming nodig, met bron en bestemming omgewisseld.

Controleer welk model het product werkelijk implementeert voordat u iets schrijft. Een regel voor echo-verzoek dekt niet noodzakelijk echo-antwoord, en een product dat ICMP-query’s volgt, kan op antwoorden die op een andere interface aankomen nog steeds een ander beleid toepassen.

Beperk wat u toestaat. Elk echo-antwoord van waar dan ook toestaan is niet hetzelfde als een stateful koppeling voltooien, en een typenummer authenticeert de afzender niet.

Vertaling verandert ook de identificatie

Als bronvertaling opzettelijk is, past de tuple aan de verre kant niet bij die de client heeft verzonden. Een NAT kan de identificatie van de ICMP-query samen met de adressen vertalen, dus aandringen op hetzelfde nummer aan beide kanten levert een valse afwijking op.

Koppel in plaats daarvan de mapping die de vertaler rapporteert. Een vertaler die de identificatie herschrijft, bewaart niet het nummer dat uw client heeft gelogd, dus behandel de mapping als de identiteit en niet het nummer. Volg daarna één herkenbaar verzoek door het pad: bevestig dat het de bestemming met de verwachte bron bereikt, bevestig dat de bestemming een antwoord heeft uitgezonden, volg de route van dat antwoord terug, en bevestig dat de client het heeft ontvangen in plaats van alleen te kijken hoe een gateway-teller stijgt.

Vouw ICMP-fouten niet in het echobeleid

Het bericht „fragmentatie nodig” dat pad-MTU-detectie gebruikt, is geen echo-antwoord, en de payload citeert het pakket dat het heeft veroorzaakt. Een toestemming alleen voor echo die die fouten stil weggooit, verandert een grootteprobleem in een hangende verbinding, wat het tegenovergestelde van nuttig is.

Dezelfde voorzichtigheid geldt voor adresfamilies. ICMPv6 gebruikt andere berichttypen en draagt essentiële functies die IPv4 niet heeft, dus deze nummers in een IPv6-regel kopiëren is simpelweg fout.

Als de echowisseling werkt, test dan de echte toepassing apart. Een geslaagde ping bewijst de heen- en terugweg van één protocol bij één grootte naar één bestemming, en het is geen licentie om aan te nemen dat HTTPS, SMB of elke andere stroom is toegestaan.