Pse përgjigja DNS dështon në një firewall skajor VPN pa gjendje

Tuneli është aktiv, klientët arrijnë hostin VPN, por hosti nuk mund të zgjidhë asgjë. Kërkesat e tij dalëse e lënë ndërfaqen pastër, prandaj defekti është në rrugën e kthimit: në një skaj më lart që filtron trafikun hyrës pa mbajtur mend çfarë sapo dërgoi hosti. Lejimi i portës së tunelit nuk e përshkruan fare atë shkëmbim. Përgjigja ndaj një kërkese DNS është një rrjedhë më vete, dhe nëse skaji është pa gjendje, asgjë nuk i ka dhënë leje të kthehet.

Dy shkëmbimet nuk janë i njëjti shkëmbim

Shkruajini tuple-t dhe gabimi bëhet i dukshëm. Porti destinacion i kërkesës bëhet porti burim i përgjigjes, që është e kundërta e asaj që imagjinon shumica kur shton një rregull hyrës për portën 53:

query:  203.0.113.10:53018 -> 198.51.100.53:53
reply:  198.51.100.53:53 -> 203.0.113.10:53018

Një rregull hyrës që kërkon portën destinacion 53 përshkruan trafik të drejtuar drejt një dëgjuesi DNS që ekzekutohet në host, dhe ky është një shërbim krejt tjetër. Këto adresa janë shembuj dokumentacioni, dhe portin burim e zgjedh klienti për çdo kërkesë, pra nuk është një vlerë që mund ta kopjoni në një rregull dhe të shpresoni se do të vazhdojë të funksionojë.

Skaj pa gjendje kundrejt firewall-i të hostit me gjendje

Një filtër skajor pa gjendje vlerëson çdo paketë hyrëse kundrejt listës së rregullave të tij pa asnjë tabelë lidhjesh pas saj. Një kërkesë dalëse që doli me sukses nuk krijon asnjë leje për përgjigjen e saj hyrëse, sepse pajisja nuk ka asnjë regjistrim që një kërkesë ka ndodhur ndonjëherë. Një firewall hosti me gjendje është e kundërta: gjurmimi i lidhjeve të tij e njeh trafikun e kthimit të një shkëmbimi të lejuar dhe e lë të kalojë pa një rregull për përgjigjen. Të dy kufijtë ekzistojnë në një rrugë tipike, dhe të dy duhet të lejojnë paketën e synuar.

Krahasimi ka rëndësi sepse dy pajisjet dështojnë ndryshe. Një firewall me gjendje që e refuzon përgjigjen regjistron një hedhje; një skaj pa gjendje e refuzon në heshtje, prandaj hosti thjesht arrin në skadim kohe.

Ndërtojeni lejen rreth protokollit, jo rreth një numri porte

Kufizojeni rregullin te adresat reale të zgjidhësit, hosti destinacion dhe politika e portës pritëse që mbështet produkti. Mbani parasysh edhe rrugën TCP të DNS, sepse një përgjigje e madhe ose një tërheqje për shkak të shkurtimit e zhvendos shkëmbimin në TCP dhe një rregull vetëm për UDP nuk do ta mbulojë. Nëse skaji mbështet inspektim me gjendje për një rrjedhë të përcaktuar, jepini përparësi ndaj një rregulli përgjigjeje të shkruar me dorë, sepse rruga me gjendje ndjek automatikisht portat që zgjedh klienti.

Më pas konfirmoni cili produkt në rrugë e filtron vërtet trafikun. Një shtrirje skajore IPv4 e dokumentuar nuk vendos një politikë IPv6, dhe trafiku i brendshëm i ofruesit mund të mos kalojë kurrë nëpër të njëjtin filtër.

Pse lejimi i çdo porte burim 53 nuk është zgjidhje

Një rregull që pranon gjithçka që pretendon portën burim 53 është një rregull që pranon atë që shkruan dërguesi në një fushë kreu. Numri i portës nuk e vërteton dërguesin dhe nuk provon se ngarkesa është përgjigje e vlefshme, prandaj rregulli zgjeron ekspozimin e hostit pa e bërë zgjidhjen më të besueshme. Mbani kufizimet e burimit dhe kontrollet e përgjigjes të vetë klientit, përfshirë rastësimin e portës burim, në vend që t'i çaktivizoni për të thjeshtuar një listë aksesi.

Nëse zgjidhësi është një shërbim që ju kontrolloni, kufizimi te adresat e tij mjafton. Nëse është zgjidhës publik, kufizojeni te adresat që keni miratuar dhe shënoni ato në komentin e rregullit.

Verifikoni në kufirin e duhur, në drejtimin e duhur

Kapni në host dhe në skaj të njëjtën kërkesë, dhe krahasoni tuple-t në vend të numërimeve të paketave. Një kërkesë e dukshme në të dyja anët pa përgjigje të dukshme në anën e hostit tregon filtrin hyrës; një kërkesë e dukshme vetëm në anën e hostit tregon rrugëtimin ose vetë zgjidhësin. Përsëriteni me një kërkesë TCP nëse keni vetëm leje për UDP, sepse pikërisht kjo është boshllëku që testi i parë nuk mund ta shohë.

Rregullimi i kësaj plotëson një shkëmbim DNS që hosti ka vërtet nevojë. Nuk e kthen hostin në zgjidhës publik, nuk autorizon rrjedha VPN të përcjella dhe nuk provon se DNS ishte shkaku i ndonjë problemi tuneli të palidhur.