Pratite jedno traženje imena od trenutka kada ga otkucate. Preglednik pita operativni sistem, operativni sistem 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 konfigurišete i zatim provodite.

Korak 1: imenujte resolver i put

Zapišite tri stvari prije nego što dotaknete firewall: adresu resolvera, protokol i port koje očekujete, i sučelje kroz koje upit treba izaći. Bez tog spiska pravilo je nagađanje o prometu, a ne provođenje odluke. VPN može nositi podatke aplikacija dok DNS slijedi odvojen raspored, i to samo po sebi nije greška. To je ono što se dogodi kada niko 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 uporediti s napisanim očekivanjem. Držite taj spisak u tiketu promjene, a ne u nečijoj glavi.

Korak 2: postavite politiku tamo gdje ona zaista živi

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

Preskočite to i idite ravno na firewall, i dobijate pravilo koje dozvoljava pravi resolver plus klijenta koji ga nikada ne koristi. Pravilo izgleda ispravno, a evidencija resolvera ostaje prazna, što je zbunjujući par za otklanjanje grešaka. Prvo konfigurišite izbor, zatim ga provedite.

Korak 3: provedite put usko

Sada dodajte mrežnu dozvolu 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 dozvolite sav odlazni DNS. Tri puta ispod su ona koja moderni klijent može preći, a samo prvi pokriva pravilo porta 53.

PathPortWho controls it
Classic DNSUDP and TCP 53System resolver settings
DNS over TLSTCP 853Resolver or stub configuration
DNS over HTTPSTCP 443Browser or application policy

Blokirati DoH i DoT je legitimno; 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 dozvoliti 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 unutrašnjem resolveru dok javna imena idu drugdje, 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 unutrašnje i jedno javno ime pod predviđenom politikom i zabilježite koji je resolver odgovorio na svako.

Test stranica koja prijavljuje vaš resolver 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 uporedite oba opažanja. Kada se razilaze, našli ste povratak koji niko nije dokumentovao.

Ako je adresa resolvera ispravna ali nedostupna, problem je u rutiranju 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 zavisi od razrješavanja imena. Pokvaren resolver čini svaki alat za popravku teže dostupnim, uključujući one kojima biste poništili promjenu. Držite lokalnu konzolu ili vanpojasni 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 ponovo pregledajte stvarno stanje, jer oboje mogu promijeniti resolver bez promjene vašeg pravila. Zahtjev je poznat primalac i zaštićen put za upite, a ne umirujuća oznaka resolvera na jednoj snimci ekrana. Specifikacija RFC 8484 za DNS over HTTPS referenca je za šifrovani put koji vaše pravilo porta ne vidi.

Povezani članci