Ping përmes një VPN: pse rregullat e përgjigjes së jehonës humbin rrugën e kthimit

Bëni ping drejt një hosti përmes një VPN dhe kërkesa del me një tip ICMP dhe kthehet me një tjetër, gjë që mjafton për të ngatërruar çdo rregull të shkruar në terma portash. Në shkëmbimin e jehonës nuk ka port shërbimi destinacioni që të kopjohet në rregullin e kthimit, dhe një filtër që pret simetri do ta hedhë poshtë përgjigjen ndërsa kërkesa kalon pa pengesa. Rregullimi fillon me leximin e paketës ashtu siç është në të vërtetë, dhe më pas me vendimin se cila kufi në rrugë e merr vendimin. Zakonisht punojnë dy shtresa ndërsa e treta e hedh përgjigjen në heshtje. Seksionet më poshtë i ndajnë ato në rendin që një paketë i takon.

Paketa ndryshon tipin, jo portën

Kërkesa e jehonës është ICMP tip 8, kod 0, dhe mbart një identifikues dhe një numër sekuence. Përgjigja është tip 0, kod 0, me të njëjtin identifikues dhe sekuencë, dhe skajet IP të ndërruara. RFC 792 i përcakton këto fusha, dhe identifikuesi është ai që i lejon dërguesit t’i përputhë përgjigjet me kërkesat e tij.

Ajo që mungon është po aq e rëndësishme: nuk ka kokë TCP ose UDP, pra nuk ka port për të lejuar. Një rregull që emërton një port për një përgjigje jehone përshkruan një paketë që nuk do të ekzistojë kurrë. Ky është gabimi më i zakonshëm në biletat e ping-ut përmes VPN. Rregulli duket specifik, nuk zbatohet për asgjë dhe e lë defektin pikërisht aty ku ishte.

Tre kontekste vendosin për paketën

Nëse ping-u synon një host në LAN-in e largët, kërkesa duhet të përcjellë nga porta hyrëse. Nëse synon një adresë që i përket vetë portës hyrëse, përfundon në rrugën hyrëse lokale. Nëse porta hyrëse e nis vetë ping-un, paketa fillon në rrugën e saj të daljes dhe nuk e kalon fare vendimin e përcjelljes.

Këto tre kontekste kanë zinxhirë rregullash dhe numërues të ndryshëm, dhe trajtimi i tyre si një i vetëm është arsyeja pse «firewall-i lejon ICMP» mund të japë ende një ping të dështuar. Tuneli i jashtëm është konteksti i katërt: lejimi i dëgjuesit VPN nuk lejon automatikisht kërkesën e brendshme të dekapsuluar, dhe një leje e brendshme nuk thotë asgjë për atë nëse tuneli i jashtëm është lart.

Filtrat me gjendje dhe pa gjendje e trajtojnë përgjigjen ndryshe

Një firewall me gjendje që e pa kërkesën të dalë mund ta lidhë përgjigjen me atë rrjedhë dhe ta pranojë pa një rregull të dytë. Një filtër pa gjendje nuk ka një kujtesë të tillë, prandaj drejtimi i kthimit ka nevojë për lejen e vet të shprehur, me burimin dhe destinacionin të kthyer.

Kontrolloni cilin model produkti zbaton vërtet përpara se të shkruani gjë. Një rregull për kërkesën e jehonës nuk e mbulon domosdoshmërisht përgjigjen e jehonës, dhe një produkt që ndjek pyetjet ICMP mund të zbatojë ende një politikë tjetër për përgjigjet që mbërrijnë në një ndërfaqe tjetër.

Kufizoni atë që lejoni. Lejimi i çdo përgjigje jehone nga kudo nuk është e njëjta gjë si përfundimi i një lidhjeje me gjendje, dhe numri i tipit nuk e vërteton dërguesin.

Përkthimi ndryshon edhe identifikuesin

Nëse përkthimi i burimit është i qëllimshëm, tuple-i në skajin e largët nuk përputhet me atë që dërgoi klienti. Një NAT mund ta përkthejë identifikuesin e pyetjes ICMP së bashku me adresat, prandaj këmbëngulja që i njëjti numër të shfaqet në të dyja anët krijon një mospërputhje të rreme.

Në vend të kësaj, lidhni hartëzimin që raporton përkthyesi. Një përkthyes që e rishkruan identifikuesin nuk do ta ruajë numrin që regjistroi klienti juaj, prandaj trajtojeni hartëzimin si identitetin dhe jo numrin. Më pas ndiqni një kërkesë të identifikueshme përgjatë rrugës: konfirmoni që arrin në destinacion me burimin e pritur, konfirmoni që destinacioni lëshoi një përgjigje, ndiqni rrugën e kthimit të asaj përgjigjeje, dhe konfirmoni që klienti e mori atë, në vend që thjesht të shihni një numërues të portës hyrëse duke u rritur.

Mos i përfshini gabimet ICMP në politikën e jehonës

Mesazhi «kërkohet fragmentim» që përdor zbulimi i MTU-së së rrugës nuk është përgjigje jehone, dhe ngarkesa e tij citon paketën që e shkaktoi. Një leje vetëm për jehonë që i hedh në heshtje ato gabime e kthen një problem madhësie në një lidhje të varur, që është e kundërta e dobishme.

E njëjta kujdes vlen edhe për familjet e adresave. ICMPv6 përdor tipe mesazhesh të ndryshme dhe mbart funksione thelbësore që IPv4 nuk i ka, prandaj kopjimi i këtyre numrave në një rregull IPv6 është thjesht i gabuar.

Kur shkëmbimi i jehonës funksionon, provoni aplikacionin e vërtetë veçmas. Një ping i suksesshëm vërteton ecjen dhe kthimin e një protokolli, me një madhësi, drejt një destinacioni, dhe nuk është licencë për të supozuar se HTTPS, SMB ose çdo rrjedhë tjetër lejohet.