Sledujte jednu požiadavku na meno od chvíle, keď ju napíšete. Prehliadač sa pýta operačného systému, operačný systém sa pýta resolvera, ktorý vyberie jeho politika, a požiadavka opúšťa zariadenie cez nejaké rozhranie s nejakým transportom. Váš návrh VPN hovorí, že odpoveď má prísť od určitého resolvera určitou cestou. Rozdiel medzi týmito dvoma tvrdeniami je to, čo nastavíte a potom vynútite.

Krok 1: pomenujte resolver a cestu

Zapíšte tri veci, kým sa dotknete firewallu: adresu resolvera, protokol a port, ktoré očakávate, a rozhranie, ktorým má požiadavka odísť. Bez tohto zoznamu je pravidlo dohad o prevádzke, nie vynútenie rozhodnutia. VPN môže prenášať dáta aplikácií, zatiaľ čo DNS ide podľa osobitného usporiadania, a samo o sebe to nie je chyba. Je to to, čo sa stane, keď klientovi nikto nepovedal nič iné.

Pomenovať cestu výslovne je rozdiel medzi návrhom a náhodou. Dáva vám aj niečo na neskoršie testovanie, pretože každé pozorovanie sa dá porovnať s písomným očakávaním. Držte ten zoznam v tikete zmeny, nie v niekoho hlave.

Krok 2: nastavte politiku tam, kde skutočne žije

Voľba resolvera patrí klientovi: sieťová konfigurácia operačného systému, vlastné nastavenia VPN klienta alebo spravovaná politika prehliadača. Nastavte ju najprv tam, mechanizmom, ktorý platforma podporuje, pretože firewall nemôže prinútiť klienta vybrať resolver, o ktorom sa nikdy nedozvedel. Na klientovi s rozdeleným tunelom výslovne povedzte, ktoré domény idú na interný resolver. V spravovanej flotile je politika prehliadača často jedinou pákou pre DoH, pretože prehliadač si môže vybrať vlastný šifrovaný resolver nezávisle od systémového nastavenia.

Preskočte to a choďte rovno na firewall a dostanete pravidlo, ktoré povoľuje správny resolver, plus klienta, ktorý ho nikdy nepoužije. Pravidlo vyzerá správne a záznamy resolvera zostávajú prázdne, čo je pri ladení mätúca dvojica. Najprv nastavte voľbu, potom ju vynúťte.

Krok 3: vynúťte cestu úzko

Teraz pridajte sieťové povolenie pre povolenú cestu: adresu resolvera, protokol a port a rozhranie, ktorým má odísť. Držte pravidlo obmedzené na tento resolver namiesto povolenia všetkého odchádzajúceho DNS. Tri cesty nižšie sú tie, ktorými sa moderný klient môže vydať, a len prvú pokrýva pravidlo pre port 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

Blokovať DoH a DoT je legitímne; predpokladať, že pravidlo pre port 53 ich už zablokovalo, nie. Prehliadač s DoH rieši mená cestou, ktorú vaše pravidlo nikdy neopísalo, a aplikácia s vlastným resolverom robí to isté. Zapíšte každú cestu, ktorú chcete povoliť, aj každú, ktorú chcete odmietnuť. Pravidlo, ktoré cestu nepomenuje, o nej nerozhodlo.

Krok 4: sledujte súkromné a verejné mená

Rozdelený DNS zámerne posiela len súkromné menné priestory na interný resolver, zatiaľ čo verejné mená idú inam, takže viac resolverov v návrhu nie je únik. Únik je požiadavka, ktorá mala ísť na váš resolver a objaví sa inde, alebo nedostupná zamýšľaná cesta, kvôli ktorej klient ticho padne späť. Tieto dva prípady treba hľadať. Sledujte interné a verejné meno pod zamýšľanou politikou a poznamenajte, ktorý resolver na každé odpovedal.

Testovacia stránka, ktorá hlási váš resolver, je náznak, nie dôkaz, pretože vidí len požiadavky, ktoré k nej dorazili. Zachyťte požiadavku na strane klienta, keď potrebujete vedieť, ktorou cestou sa skutočne vydala, a obe pozorovania porovnajte. Keď sa rozchádzajú, našli ste návrat, ktorý nikto nezdokumentoval.

Ak je adresa resolvera správna, ale nedostupná, problém je v smerovaní alebo filtrovaní, nie v politike. Vystopujte požiadavku na tú adresu a potvrďte, že sa odpoveď vracia očakávaným rozhraním, kým zmeníte akékoľvek nastavenie resolvera.

Krok 5: nechajte si cestu späť

Kým utiahnete prístup k DNS na bráne, potvrďte spôsob obnovy, ktorý nezávisí od prekladu mien. Pokazený resolver sťažuje dosiahnutie každého opravného nástroja, vrátane tých, ktorými by ste zmenu vrátili. Držte lokálnu konzolu alebo mimopásmovú cestu otvorenú, kým nová politika nebude dokázaná. Odstráňte ju až po tom, čo politika prežila opätovné pripojenie.

Po opätovnom pripojení alebo aktualizácii politiky prehliadača znova preverte efektívny stav, pretože oboje môže zmeniť resolver bez zmeny vášho pravidla. Požiadavkou je známy príjemca a chránená cesta pre požiadavky, nie upokojujúci štítok resolvera na jednej snímke obrazovky. Špecifikácia RFC 8484 pre DNS over HTTPS je referenciou pre šifrovanú cestu, ktorú vaše pravidlo portu nevidí.

Súvisiace články