Tillat DNS berre gjennom din eigen VPN-resolver: ein gjennomgang steg for steg

Følg eitt namneoppslag frå det augneblunken du tastar det. Nettlesaren spør operativsystemet, operativsystemet spør resolveren som policyen vel, og spurnaden forlèt eininga gjennom eit eller anna grensesnitt med ein eller annan transport. VPN-designet ditt seier at svaret skal kome frå ein bestemt resolver på ein bestemt veg. Gapet mellom dei to utsegnene er det du konfigurerer og deretter handhevar.

Steg 1: namnge resolveren og vegen

Skriv ned tre ting før du rører ein brannmur: adressa til resolveren, protokollen og porten du ventar, og grensesnittet spurnaden skal gå ut gjennom. Utan den lista er ein regel ei gjetting om trafikk og ikkje handheving av eit vedtak. Eit VPN kan bera applikasjonsdata medan DNS følgjer eit eige opplegg, og det er ikkje ein feil i seg sjølv. Det er det som skjer når ingen har fortalt klienten noko anna.

Å namngje vegen uttrykkeleg er skilnaden mellom eit design og eit uhell. Det gjev deg òg noko å teste seinare, fordi kvar observasjon kan samanliknast med ei skriven forventning. Oppbevar lista i endringsbilletten og ikkje i hovudet til nokon.

Steg 2: set policyen der han faktisk bur

Valet av resolver høyrer til klienten: nettverkskonfigurasjonen til operativsystemet, eigne innstillingar i VPN-klienten eller ein administrert nettlesarpolicy. Set han der først, med mekanismen plattforma støttar, fordi ein brannmur kan ikkje tvinge ein klient til å velje ein resolver han aldri har høyrt om. På ein klient med delt tunnel må du seie uttrykkeleg kva domene som går til den interne resolveren. I ein administrert flåte er ein nettlesarpolicy ofte det einaste handtaket for DoH, fordi nettlesaren kan velje sin eigen krypterte resolver uavhengig av systeminnstillinga.

Hopp over dette og gå rett til brannmuren, og du får ein regel som tillèt rett resolver, pluss ein klient som aldri brukar han. Regelen ser rett ut, og resolverloggane blir verande tomme, eit forvirrande par å feilsøkje. Konfigurer først valet, og handhev det etterpå.

Steg 3: handhev vegen smalt

Legg no til nettverkstilgjenge for den tillatne vegen: adressa til resolveren, protokollen og porten, og grensesnittet han skal gå ut gjennom. Hald regelen avgrensa til den resolveren i staden for å tillate all utgåande DNS. Dei tre vegane nedanfor er dei ein moderne klient kan ta, og berre den første er dekt av ein regel for port 53.

Å blokkere DoH og DoT er legitimt; å gå ut frå at ein regel for port 53 alt har blokkert dei er det ikkje. Ein nettlesar med DoH løyser namn via ein veg regelen din aldri har skildra, og ein applikasjon som tek med sin eigen resolver gjer det same. Skriv ned kvar veg du aktar å tillate og kvar ein du aktar å avvise. Ein regel som ikkje nemner ein veg har ikkje bestemt noko om han.

Steg 4: følg private og offentlege namn

Delt DNS sender med vilje berre private namnerom til ein intern resolver medan offentlege namn går andre stader, så meir enn ein resolver i designet er ikkje ein lekkasje. Lekkasjen er ein spurnad som skulle gått til resolveren din og dukkar opp ein annan stad, eller ein utilgjengeleg tiltenkt veg som får klienten til å falle stille tilbake. Det er desse to tilfella du skal leite etter. Følg eit internt og eit offentleg namn under den tiltenkte policyen, og noter kva resolver som svara på kva av dei.

Ein teststad som rapporterer resolveren din er eit hint, ikkje eit prov, fordi han berre ser spurnadene som nådde fram til han. Fang spurnaden på klientsida når du treng å vite kva veg han faktisk tok, og samanlikn dei to observasjonane. Når dei er usamde, har du funne eit tilbakefall ingen har dokumentert.

Om resolveradressa er rett men utilgjengeleg, er problemet ruting eller filtrering og ikkje policy. Spor spurnaden til den adressa, og stadfest at svaret kjem tilbake på det venta grensesnittet før du endrar noka resolverinnstilling.

Steg 5: hald ein veg tilbake

Før du strammar inn DNS-tilgangen på gatewayen, stadfest ein attopprettingsmetode som ikkje er avhengig av namneoppslag. Ein øydelagd resolver gjer kvart reparasjonsverkty vanskelegare å nå, òg dei du ville brukt til å rulle attende endringa. Hald ein lokal konsoll eller ein veg utanfor bandet open til den nye policyen er prova. Fjern han først når policyen har overlevd ei attilkopling.

Etter ei attilkopling eller ei oppdatering av nettlesarpolicyen, inspiser den effektive tilstanden på nytt, fordi begge kan endre resolveren utan å endre regelen din. Kravet er ein kjend mottakar og ein verna veg for spurnadene, ikkje ei beroligande resolvermerkelapp på eitt skjermbilete. RFC 8484-spesifikasjonen for DNS over HTTPS er referansen for den krypterte vegen som portregelen din ikkje ser.