Tillat DNS bare gjennom din egen VPN-resolver: en gjennomgang steg for steg

Følg ett navneoppslag fra det øyeblikket du taster det. Nettleseren spør operativsystemet, operativsystemet spør resolveren som policyen velger, og spørringen forlater enheten gjennom et eller annet grensesnitt med en eller annen transport. VPN-designet ditt sier at svaret skal komme fra en bestemt resolver ad en bestemt vei. Gapet mellom de to utsagnene er det du konfigurerer og deretter håndhever.

Trinn 1: navngi resolveren og veien

Skriv ned tre ting før du rører en brannmur: resolverens adresse, protokollen og porten du forventer, og grensesnittet spørringen skal gå ut gjennom. Uten den listen er en regel en gjetning om trafikk og ikke håndheving av en beslutning. Et VPN kan bære applikasjonsdata mens DNS følger et eget opplegg, og det er ikke en feil i seg selv. Det er det som skjer når ingen har fortalt klienten noe annet.

Å navngi veien eksplisitt er forskjellen mellom et design og et uhell. Det gir deg også noe å teste senere, fordi hver observasjon kan sammenlignes med en skriftlig forventning. Oppbevar listen i endringsbilletten og ikke i noens hode.

Trinn 2: sett policyen der den faktisk bor

Valget av resolver hører til klienten: operativsystemets nettverkskonfigurasjon, VPN-klientens egne innstillinger eller en administrert nettleserpolicy. Sett den der først, med mekanismen plattformen støtter, fordi en brannmur ikke kan tvinge en klient til å velge en resolver den aldri har hørt om. På en klient med delt tunnel må du si eksplisitt hvilke domener som går til den interne resolveren. I en administrert flåte er en nettleserpolicy ofte det eneste håndtaket for DoH, fordi nettleseren kan velge sin egen krypterte resolver uavhengig av systeminnstillingen.

Hopp over dette og gå rett til brannmuren, og du får en regel som tillater riktig resolver, pluss en klient som aldri bruker den. Regelen ser riktig ut, og resolverloggene forblir tomme, et forvirrende par å feilsøke. Konfigurer først valget, og håndhev det etterpå.

Trinn 3: håndhev veien smalt

Legg nå til nettverkstillatelsen for den tillatte veien: resolverens adresse, protokollen og porten, og grensesnittet den skal gå ut gjennom. Hold regelen avgrenset til den resolveren i stedet for å tillate all utgående DNS. De tre veiene nedenfor er dem en moderne klient kan ta, og bare den første dekkes av en regel for port 53.

Å blokkere DoH og DoT er legitimt; å anta at en regel for port 53 allerede har blokkert dem er det ikke. En nettleser med DoH løser navn via en vei regelen din aldri har beskrevet, og en applikasjon som tar med sin egen resolver gjør det samme. Skriv ned hver vei du akter å tillate og hver enkelt du akter å avvise. En regel som ikke navngir en vei har ikke bestemt noe om den.

Trinn 4: følg private og offentlige navn

Delt DNS sender med vilje bare private navnerom til en intern resolver mens offentlige navn går andre steder, så mer enn én resolver i designet er ikke en lekkasje. Lekkasjen er en spørring som skulle gått til resolveren din og dukker opp et annet sted, eller en utilgjengelig tiltenkt vei som får klienten til å falle stille tilbake. Det er disse to tilfellene du skal lete etter. Følg et internt og et offentlig navn under den tiltenkte policyen, og noter hvilken resolver som svarte på hvert av dem.

Et testsite som rapporterer resolveren din er et hint, ikke et bevis, fordi det bare ser spørringene som nådde fram til det. Fang spørringen på klientsiden når du trenger å vite hvilken vei den faktisk tok, og sammenlign de to observasjonene. Når de er uenige, har du funnet et tilbakefall ingen har dokumentert.

Hvis resolveradressen er riktig men utilgjengelig, er problemet ruting eller filtrering og ikke policy. Spor spørringen til den adressen, og bekreft at svaret kommer tilbake på det forventede grensesnittet før du endrer noen resolverinnstilling.

Trinn 5: behold en vei tilbake

Før du strammer inn DNS-tilgangen på gatewayen, bekreft en gjenopprettingsmetode som ikke avhenger av navneoppslag. En ødelagt resolver gjør hvert reparasjonsverktøy vanskeligere å nå, også dem du ville brukt til å rulle tilbake endringen. Hold en lokal konsoll eller en utenforbåndsvei åpen til den nye policyen er bevist. Fjern den først når policyen har overlevd en gjentilkobling.

Etter en gjentilkobling eller en oppdatering av nettleserpolicyen, inspiser den effektive tilstanden på nytt, fordi begge kan endre resolveren uten å endre regelen din. Kravet er en kjent mottaker og en beskyttet vei for spørringene, ikke en beroligende resolveretikett på ett skjermbilde. RFC 8484-spesifikasjonen for DNS over HTTPS er referansen for den krypterte veien som portregelen din ikke ser.