Hvers vegna DNS-svari mistekst á stöðulausri VPN-brúnarvörn

Tunnillinn er uppi, biðlarar ná VPN-hýslinu, en hýsillinn getur ekki leyst neitt. Eigin útfarendi fyrirspurnir hans yfirgefa viðmótið hreint, svo bilunin er á leiðinni til baka: á brún ofar sem síar komandi umferð án þess að muna hvað hýsillinn sendi rétt í þessu. Að leyfa höfn tunnilsins lýsir þeim skiptum alls ekki. Svarið við DNS-fyrirspurn er aðskilinn straumur, og ef brúnin er stöðulaus hefur ekkert veitt því leyfi til að snúa aftur.

Skiptin tvö eru ekki sömu skipti

Skrifaðu tvípökin niður og mistökin verða augljós. Áfangahlið fyrirspurnarinnar verður upprunahlið svarsins, sem er andstæðan við það sem flestir ímynda sér þegar þeir bæta við komandi reglu fyrir hlið 53:

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

Komin regla sem krefst áfangahliðar 53 lýsir umferð sem er beint að DNS-hlustara sem keyrir á hýslinum, og það er allt önnur þjónusta. Þessi vistföng eru dæmi úr skjölum, og upprunahliðina velur biðlarinn fyrir hverja fyrirspurn, svo það er ekki gildi sem þú getur afritað í reglu og búist við að haldi áfram að virka.

Stöðulaus brún gegn stöðufullri hýsilvörn

Stöðulaus brúnarsía metur hvert komandi pakka gegn reglulistanum sínum án nokkurrar tengingatöflu að baki. Útfarendi fyrirspurn sem komst út skapar ekkert leyfi fyrir komandi svar sitt, vegna þess að tækið hefur enga skrá um að fyrirspurn hafi nokkru sinni átt sér stað. Stöðufull hýsilvörn er hið gagnstæða: tengingarakning hennar þekkir afturumferð leyfðra skipta og hleypir henni í gegn án reglu fyrir svarið. Báðar brúnir eru til á dæmigerðri leið, og báðar verða að leyfa tilætlaðan pakka.

Samanburðurinn skiptir máli vegna þess að tækin tvö mistakast á ólíkan hátt. Stöðufull vörn sem synjar svarinu skráir drop; stöðulaus brún synjar því hljóðlega, og þess vegna fer hýsillinn einfaldlega í tímamörk.

Byggðu leyfið í kringum samskiptareglurnar, ekki hliðarnúmer

Takmarkaðu regluna við raunveruleg vistföng leysisins, áfangahýsilinn og þá stefnu um móttökuhlið sem varan styður. Hafðu TCP-leið DNS líka í huga, vegna þess að stórt svar eða afturhvarf vegna styttingar færir skiptin yfir á TCP og regla sem aðeins nær til UDP mun ekki ná utan um þau. Ef brúnin styður stöðufulla skoðun fyrir skilgreindan straum skaltu velja hana fram yfir handskrifaða svarreglu, vegna þess að stöðufulla leiðin fylgir hliðunum sem biðlarinn velur sjálfkrafa.

Staðfestu síðan hvaða vara á leiðinni síar umferðina í raun. Skjalfest IPv4-brúnarsvið festir ekki IPv6-stefnu, og umferð innan þjónustuveitandans fer kannski aldrei í gegnum sama sía.

Hvers vegna að leyfa hvaða upprunahlið 53 sem er er ekki lagfæring

Regla sem tekur við öllu sem segist hafa upprunahlið 53 er regla sem tekur við því sem sendandi skrifar í hausreit. Hliðarnúmerið staðfestir ekki sendandann og sannar ekki að farmurinn sé gild svar, svo reglan eykur útsetningu hýsilsins án þess að gera leysinguna áreiðanlegri. Haltu upprunatakmörkunum og haltu eigin svarprófunum biðlarans, þar á meðal slembivali upprunahliðar, í stað þess að slökkva á þeim til að einfalda aðgangslista.

Ef leysirinn er þjónusta sem þú stjórnar er nóg að takmarka við vistföng hans. Ef hann er opinber leysir skaltu takmarka við vistföngin sem þú samþykktir og skrá þau í athugasemd reglunnar.

Sannprófaðu á réttri brún, í rétta átt

Gríptu á hýslinum og á brúninni fyrir sömu fyrirspurn og berðu saman tvípökin frekar en pakkatalningarnar. Fyrirspurn sem sést á báðum hliðum án svars sem sést á hýsilhliðinni bendir á komandi síuna; fyrirspurn sem sést aðeins á hýsilhliðinni bendir á leiðslu eða leysirinn sjálfan. Endurtaktu með TCP-fyrirspurn ef þú hefur aðeins leyfi fyrir UDP, vegna þess að það er bilið sem fyrsta prófið getur ekki séð.

Að laga þetta lýkur DNS-skiptum sem hýsillinn þarf sannarlega á að halda. Það gerir hýsilinn ekki að opinberum leysi, heimilar ekki áframsenda VPN-strauma og sannar ekki að DNS hafi verið orsök einhvers ótengds tunnilvandamáls.