Pratite jedno traženje imena od trenutka kada ga otkucate. Pregledač pita operativni sistem, operativni sistem pita rezolver koji odabere njegova politika, a upit napušta uređaj kroz neko sučelje i nekim prenosom. Vaš VPN nacrt kaže da odgovor treba da dođe od određenog rezolvera određenim putem. Razlika između tih tvrdnji je ono što podešavate i zatim sprovodite.

Korak 1: imenujte rezolver i put

Zapišite tri stvari pre nego što dotaknete vatrozid: adresu rezolvera, protokol i port koje očekujete, i sučelje kroz koje upit treba da izađe. Bez tog spiska pravilo je nagađanje o saobraćaju, a ne sprovođenje odluke. VPN može da nosi podatke aplikacija dok DNS sledi odvojeno uređenje, 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 nacrta i slučajnosti. Ono vam daje i nešto za kasnije testiranje, jer se svako opažanje može uporediti sa napisanim očekivanjem. Držite taj spisak u tiketu promene, a ne u nečijoj glavi.

Korak 2: postavite politiku tamo gde ona zaista živi

Izbor rezolvera pripada klijentu: mrežna konfiguracija operativnog sistema, sopstvene postavke VPN klijenta ili upravljana politika pregledača. Postavite je prvo tamo, mehanizmom koji platforma podržava, jer vatrozid ne može da natera klijenta da odabere rezolver za koji nikada nije čuo. Na klijentu sa podeljenim tunelom izričito recite koje domene idu unutrašnjem rezolveru. U upravljanom parku politika pregledača je često jedina poluga za DoH, jer pregledač može da odabere sopstveni šifrovani rezolver nezavisno od sistemske postavke.

Preskočite to i idite pravo na vatrozid, i dobijate pravilo koje dozvoljava pravi rezolver plus klijenta koji ga nikada ne koristi. Pravilo izgleda ispravno, a evidencija rezolvera ostaje prazna, što je zbunjujući par za otklanjanje grešaka. Prvo podesite izbor, zatim ga sprovedite.

Korak 3: sprovedite put usko

Sada dodajte mrežnu dozvolu za dozvoljeni put: adresu rezolvera, protokol i port, i sučelje kroz koje treba da izađe. Držite pravilo ograničeno na taj rezolver umesto da dozvolite sav odlazni DNS. Tri puta ispod su ona koja moderni klijent može da prođe, 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. Pregledač sa DoH razrešava imena putem koji vaše pravilo nikada nije opisalo, a aplikacija sa sopstvenim rezolverom čini isto. Zapišite svaki put koji nameravate da dozvolite i svaki koji nameravate da odbijete. Pravilo koje ne imenuje put nije o njemu odlučilo.

Korak 4: pratite privatna i javna imena

Podeljeni DNS namerno šalje samo privatne prostore imena unutrašnjem rezolveru dok javna imena idu drugde, pa više od jednog rezolvera u nacrtu nije curenje. Curenje je upit koji je trebalo da ide vašem rezolveru a pojavljuje se drugde, ili nedostupan predviđeni put zbog kojeg klijent tiho pada nazad. Ta dva slučaja treba tražiti. Pratite jedno unutrašnje i jedno javno ime pod predviđenom politikom i zabeležite koji je rezolver odgovorio na svako.

Test stranica koja izveštava o vašem rezolveru je nagoveštaj, ne dokaz, jer vidi samo upite koji su do nje stigli. Snimite upit na strani klijenta kada treba da znate 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 rezolvera 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 pre nego što promenite bilo koju postavku rezolvera.

Korak 5: ostavite put nazad

Pre nego što zategnete pristup DNS-u na mrežnom prolazu, potvrdite metod oporavka koji ne zavisi od razrešavanja imena. Pokvaren rezolver čini svaki alat za popravku teže dostupnim, uključujući one kojima biste poništili promenu. 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 pregledača ponovo pregledajte stvarno stanje, jer oboje mogu da promene rezolver bez promene vašeg pravila. Zahtev je poznat primalac i zaštićen put za upite, a ne umirujuća oznaka rezolvera na jednoj slici ekrana. Specifikacija RFC 8484 za DNS over HTTPS referenca je za šifrovani put koji vaše pravilo porta ne vidi.

Povezani članci