Dopustite DNS samo kroz svoj VPN resolver: pregled korak po korak

Pratite jedno traženje imena od trenutka kada ga upišete. Preglednik pita operacijski sustav, operacijski sustav pita resolver koji odabere njegova politika, a upit napušta uređaj kroz neko sučelje i nekim transportom. Vaš VPN dizajn kaže da odgovor treba doći od određenog resolvera određenim putem. Razlika između tih tvrdnji je ono što konfigurirate i zatim provodite.

Korak 1: imenujte resolver i put

Zapišite tri stvari prije nego dotaknete vatrozid: adresu resolvera, protokol i port koje očekujete, i sučelje kroz koje upit treba izaći. Bez tog popisa pravilo je nagađanje o prometu, a ne provedba odluke. VPN može nositi podatke aplikacija dok DNS slijedi odvojen raspored, i to samo po sebi nije pogreška. To je ono što se dogodi kada nitko klijentu nije rekao drugačije.

Izričito imenovanje puta razlika je između dizajna i slučajnosti. Ono vam daje i nešto za kasnije testiranje, jer se svako opažanje može usporediti s napisanim očekivanjem. Držite taj popis u ticketu promjene, a ne u nečijoj glavi.

Korak 2: postavite politiku tamo gdje ona zaista živi

Izbor resolvera pripada klijentu: mrežna konfiguracija operacijskog sustava, vlastite postavke VPN klijenta ili upravljana politika preglednika. Postavite je prvo tamo, mehanizmom koji platforma podržava, jer vatrozid ne može natjerati klijenta da odabere resolver za koji nikada nije čuo. Na klijentu s podijeljenim tunelom izričito recite koje domene idu unutarnjem resolveru. U upravljanom parku politika preglednika često je jedina poluga za DoH, jer preglednik može odabrati vlastiti šifrirani resolver neovisno o sistemskoj postavci.

Preskočite to i idite ravno na vatrozid, i dobivate pravilo koje dopušta pravi resolver plus klijenta koji ga nikada ne koristi. Pravilo izgleda ispravno, a evidencija resolvera ostaje prazna, što je zbunjujući par za otklanjanje pogrešaka. Prvo konfigurirajte izbor, zatim ga provedite.

Korak 3: provedite put usko

Sada dodajte mrežno dopuštenje za dopušteni put: adresu resolvera, protokol i port, i sučelje kroz koje treba izaći. Držite pravilo ograničeno na taj resolver umjesto da dopustite sav odlazni DNS. Tri puta ispod su ona koja moderni klijent može proći, a samo prvi pokriva pravilo porta 53.

Blokirati DoH i DoT legitimno je; pretpostaviti da ih je pravilo porta 53 već blokiralo nije. Preglednik s DoH razrješava imena putem kojeg vaše pravilo nikada nije opisalo, a aplikacija s vlastitim resolverom čini isto. Zapišite svaki put koji namjeravate dopustiti i svaki koji namjeravate odbiti. Pravilo koje ne imenuje put nije o njemu odlučilo.

Korak 4: pratite privatna i javna imena

Podijeljeni DNS namjerno šalje samo privatne prostore imena unutarnjem resolveru dok javna imena idu drugamo, pa više od jednog resolvera u dizajnu nije curenje. Curenje je upit koji je trebao ići vašem resolveru a pojavljuje se drugdje, ili nedostupan predviđeni put zbog kojeg klijent tiho pada natrag. Ta dva slučaja treba tražiti. Pratite jedno unutarnje i jedno javno ime pod predviđenom politikom i zabilježite koji je resolver odgovorio na svako.

Testna stranica koja izvješćuje o vašem resolveru je nagovještaj, ne dokaz, jer vidi samo upite koji su do nje stigli. Snimite upit na strani klijenta kada trebate znati kojim je putem zaista išao, pa usporedite oba opažanja. Kada se razilaze, našli ste povratak koji nitko nije dokumentirao.

Ako je adresa resolvera ispravna ali nedostupna, problem je u usmjeravanju ili filtriranju, a ne u politici. Pratite upit do te adrese i potvrdite da se odgovor vraća kroz očekivano sučelje prije nego promijenite bilo koju postavku resolvera.

Korak 5: ostavite put natrag

Prije nego zategnete pristup DNS-u na mrežnom prolazu, potvrdite metodu oporavka koja ne ovisi o razrješavanju imena. Pokvaren resolver čini svaki alat za popravak teže dostupnim, uključujući one kojima biste poništili promjenu. Držite lokalnu konzolu ili izvanpojasni put otvorenim dok nova politika ne bude dokazana. Uklonite ga tek nakon što politika preživi ponovno povezivanje.

Nakon ponovnog povezivanja ili ažuriranja politike preglednika ponovno pregledajte stvarno stanje, jer oboje mogu promijeniti resolver bez promjene vašeg pravila. Zahtjev je poznat primatelj i zaštićen put za upite, a ne umirujuća oznaka resolvera na jednoj snimci zaslona. Specifikacija RFC 8484 za DNS over HTTPS referenca je za šifrirani put koji vaše pravilo porta ne vidi.