Ping deur ’n VPN: waarom reëls vir eggo-antwoorde die terugpad mis

Ping ’n gasheer oor ’n VPN en die versoek vertrek as een ICMP-tipe en kom terug as ’n ander, wat genoeg is om enige reël wat in terme van poorte geskryf is, te verwar. Daar is geen bestemmingsdienspoort in ’n eggo-uitruiling om in die terugkeerreël te kopieer nie, en ’n filter wat simmetrie verwag, sal die antwoord laat val terwyl die versoek deurglip. Die regstelling begin deur die pakket te lees soos dit werklik is, en dan te besluit watter grens in die pad die besluit neem. Twee lae werk gewoonlik terwyl die derde die antwoord stilweg laat val. Die afdelings hieronder skei hulle in die orde waarin ’n pakket hulle teëkom.

Die pakket verander tipe, nie poort nie

’n Eggo-versoek is ICMP-tipe 8, kode 0, en dra ’n identifiseerder en ’n volgnommer. Die antwoord is tipe 0, kode 0, met dieselfde identifiseerder en volgnommer, en die IP-eindpunte omgeruil. RFC 792 definieer daardie velde, en dit is die identifiseerder wat ’n sender in staat stel om antwoorde by sy eie versoeke te pas.

Wat ontbreek, is net so belangrik: daar is geen TCP- of UDP-opskrif nie, dus is daar geen poort om toe te laat nie. ’n Reël wat ’n poort vir ’n eggo-antwoord noem, beskryf ’n pakket wat nooit sal bestaan nie. Dit is die enkele mees algemene fout in VPN-ping-tickets. Die reël lyk spesifiek, is op niks van toepassing nie, en laat die fout presies waar dit was.

Drie kontekste besluit oor die pakket

As die ping na ’n gasheer op die verre LAN gemik is, moet die versoek deur die poort aangestuur word. As dit na ’n adres gemik is wat aan die poort self behoort, eindig dit eerder in die plaaslike invoerpad. As die poort die ping begin, begin die pakket in sy eie uitvoerpad en kruis dit glad nie die aansturingsbesluit nie.

Daardie drie kontekste het verskillende reëlkettings en verskillende tellers, en om hulle as een te behandel is die rede waarom “die firewall laat ICMP toe” steeds ’n mislukte ping kan lewer. Die buitenste tonnel is ’n vierde konteks: om die VPN-luisteraar toe te laat, laat nie outomaties die gedekapsuleerde binneste versoek toe nie, en ’n binneste toelating sê niks oor of die buitenste tonnel op is nie.

Filters met en sonder toestand hanteer die antwoord verskillend

’n Firewall met toestand wat die versoek sien uitgaan het, kan die antwoord aan daardie vloei koppel en dit sonder ’n tweede reël toelaat. ’n Filter sonder toestand het nie so ’n geheue nie, so die terugrigting het sy eie uitdruklike toelating nodig, met die bron en bestemming omgeruil.

Kontroleer watter model die produk werklik implementeer voordat jy iets skryf. ’n Reël vir eggo-versoek dek nie noodwendig eggo-antwoord nie, en ’n produk wat ICMP-navrae volg, kan steeds ’n ander beleid toepas op antwoorde wat op ’n ander koppelvlak aankom.

Beperk wat jy toelaat. Om elke eggo-antwoord van enige plek toe te laat is nie dieselfde as om ’n toestandskoppeling te voltooi nie, en ’n tipe nommer verifieer nie die sender nie.

Vertaling verander ook die identifiseerder

As bronvertaling doelbewus is, pas die tuple aan die verre kant nie by die een wat die kliënt gestuur het nie. ’n NAT kan die ICMP-navraag-identifiseerder saam met die adresse vertaal, so om daarop aan te dring dat dieselfde nommer aan beide kante verskyn, lewer ’n valse wanpassing.

Korreleer eerder die kartering wat die vertaler rapporteer. ’n Vertaler wat die identifiseerder herskryf, sal nie die nommer behou wat jou kliënt gelog het nie, so behandel die kartering as die identiteit eerder as die nommer. Volg dan een identifiseerbare versoek deur die pad: bevestig dat dit die bestemming met die verwagte bron bereik, bevestig dat die bestemming ’n antwoord uitgestuur het, volg daardie antwoord se roete terug, en bevestig dat die kliënt dit ontvang het eerder as om net te kyk hoe ’n poortteller styg.

Moenie ICMP-foute in die eggobeleid in vou nie

’n Boodskap dat fragmentering nodig is, wat deur pad-MTU-ontdekking gebruik word, is nie ’n eggo-antwoord nie, en sy loonhawe haal die pakket aan wat dit veroorsaak het. ’n Slegs-eggo-toelating wat daardie foute stilweg weggooi, verander ’n grootteprobleem in ’n hangende verbinding, wat die teenoorgestelde van behulpsaam is.

Dieselfde versigtigheid geld vir adresfamilies. ICMPv6 gebruik ander boodskaptipes en dra noodsaaklike funksies wat IPv4 nie het nie, so om hierdie nommers in ’n IPv6-reël te kopieer is eenvoudig verkeerd.

Wanneer die eggo-uitruiling werk, toets die werklike toepassing afsonderlik. ’n Suksesvolle ping bewys een protokol se retoer by een grootte na een bestemming, en dit is nie ’n lisensie om te aanvaar dat HTTPS, SMB of elke ander vloei toegelaat word nie.