Luba DNS ainult oma VPN-i resolveri kaudu: samm-sammuline läbivaatus

Jälgi üht nimepäringut hetkest, mil selle sisestad. Brauser küsib operatsioonisüsteemilt, operatsioonisüsteem küsib resolverilt, mille valib selle poliitika, ja päring lahkub seadmest mingi liidese kaudu mingi transpordiga. Sinu VPN-i projekt ütleb, et vastus peaks tulema kindlalt resolverilt kindlat teed pidi. Nende kahe väite vahe on see, mille seadistad ja seejärel kehtestad.

Samm 1: nimeta resolver ja tee

Kirjuta kolm asja üles enne, kui tulemüüri puutud: resolveri aadress, oodatav protokoll ja port ning liides, mille kaudu päring peab väljuma. Ilma selle loendita on reegel oletus liikluse kohta, mitte otsuse kehtestamine. VPN võib kanda rakenduste andmeid, samal ajal kui DNS järgib eraldi korda, ja see ei ole iseenesest viga. See on see, mis juhtub, kui keegi ei ole kliendile teisiti öelnud.

Tee selgesõnaline nimetamine on vahe projekti ja juhuse vahel. See annab sulle ka midagi hiljem testida, sest iga vaatlust saab võrrelda kirjaliku ootusega. Hoia seda loendit muudatuse piletil, mitte kellegi peas.

Samm 2: pane poliitika sinna, kus see päriselt elab

Resolveri valik kuulub kliendile: operatsioonisüsteemi võrguseadistus, VPN-kliendi enda seaded või hallatav brauseripoliitika. Sea see kõigepealt seal, platvormi toetatud mehhanismiga, sest tulemüür ei saa sundida klienti valima resolverit, millest too pole kunagi kuulnud. Jaotatud tunneliga kliendil ütle selgelt, millised domeenid lähevad sisemisele resolverile. Hallatud pargis on brauseripoliitika sageli ainus hoob DoH jaoks, sest brauser saab valida oma krüpteeritud resolveri süsteemiseadest sõltumatult.

Jäta see vahele ja mine otse tulemüüri juurde ning saad reegli, mis lubab õiget resolverit, pluss kliendi, kes seda kunagi ei kasuta. Reegel näib õige ja resolveri logid jäävad tühjaks, mis on silumisel segane paar. Seadista kõigepealt valik ja kehtesta see alles siis.

Samm 3: kehtesta tee kitsalt

Nüüd lisa võrgu luba lubatud tee jaoks: resolveri aadress, protokoll ja port ning liides, mille kaudu see peab väljuma. Hoia reegel piiratud selle resolveriga, selle asemel et lubada kogu väljuv DNS. Kolm allolevat teed on need, mida kaasaegne klient saab valida, ja ainult esimest katab port 53 reegel.

DoH ja DoT blokeerimine on seaduslik; eeldada, et port 53 reegel on need juba blokeerinud, ei ole. DoH-d kasutav brauser lahendab nimesid teed pidi, mida sinu reegel kunagi ei kirjeldanud, ja oma resolveriga rakendus teeb sama. Kirjuta üles iga tee, mida kavatsed lubada, ja igaüks, mille kavatsed keelata. Reegel, mis ei nimeta teed, ei ole selle kohta otsust teinud.

Samm 4: jälgi privaatseid ja avalikke nimesid

Jaotatud DNS saadab teadlikult ainult privaatsed nimeruumid sisemisele resolverile, samal ajal kui avalikud nimed lähevad mujale, seega rohkem kui üks resolver projektis ei ole leke. Leke on päring, mis oleks pidanud minema sinu resolverile ja jõuab mujale, või kättesaamatu kavandatud tee, mis paneb kliendi vaikselt tagasi langema. Need kaks juhtumit on see, mida otsida. Jälgi kavandatud poliitika all üht sisemist ja üht avalikku nime ning märgi, milline resolver kummale vastas.

Testileht, mis teatab sinu resolveri, on vihje, mitte tõestus, sest see näeb ainult päringuid, mis temani jõudsid. Püüa päring kliendi poolel, kui pead teadma, millise tee see tegelikult valis, ja võrdle mõlemat vaatlust. Kui need lahknevad, oled leidnud tagasilanguse, mida keegi ei dokumenteerinud.

Kui resolveri aadress on õige, kuid kättesaamatu, on probleem marsruutimises või filtreerimises, mitte poliitikas. Jälgi päring sellele aadressile ja kinnita, et vastus tuleb tagasi oodatud liidesel, enne kui muudad ükskõik millist resolveri seadet.

Samm 5: hoia tagasitee lahti

Enne lüüsi DNS-i juurdepääsu karmistamist kinnita taastemeetod, mis ei sõltu nimede lahendamisest. Katkine resolver muudab iga parandusvahendi raskemini kättesaadavaks, ka need, mida muudatuse tagasipööramiseks kasutaksid. Hoia kohalik konsool või ribaväline tee lahti, kuni uus poliitika on tõestatud. Eemalda see alles siis, kui poliitika on üle elanud taasühenduse.

Pärast taasühendust või brauseripoliitika uuendust vaata efektiivne olek uuesti üle, sest mõlemad võivad resolverit muuta ilma sinu reeglit muutmata. Nõue on teada saaja ja kaitstud tee päringute jaoks, mitte ühel ekraanipildil rahustav resolveri silt. RFC 8484 DNS over HTTPS spetsifikatsioon on viide krüpteeritud teele, mida sinu pordi reegel ei näe.