Slipp DNS bare gjennom VPN-resolveren din: en trinnvis gjennomgang

Følg en enkelt navneforespørsel fra du taster navnet. Nettleseren spør operativsystemet, operativsystemet spør resolveren som dets policy peker på, og forespørselen forlater maskinen over et grensesnitt med en transport. VPN-planen din sier at svaret skal komme fra en bestemt resolver over en bestemt vei. Avstanden mellom disse to setningene er nettopp det du setter opp og deretter håndhever.

Trinn 1: gi resolveren og veien et navn

Noter tre ting før du begynner på brannmuren: resolverens adresse, hvilken protokoll og port du forventer, og grensesnittet forespørselen skal gå ut fra. Uten denne listen er regelen bare en antakelse om trafikk, ikke gjennomføring av en beslutning. Et VPN kan frakte applikasjonsdata mens DNS følger en separat ordning, og det er ikke feil i seg selv. Det er resultatet når ingen har fortalt klienten noe annet.

Å navngi veien eksplisitt skiller et design fra en tilfeldighet. Du får også noe å teste senere, siden hver observasjon kan holdes opp mot en skriftlig forventning. Ta vare på listen i endringssaken, ikke bare i hodet.

Trinn 2: legg policyen der den faktisk ligger

Resolvervalget hører til klienten: nettverksoppsettet i operativsystemet, innstillingene i selve VPN-klienten eller en styrt nettleserpolicy. Legg det der først, med mekanismen plattformen støtter, fordi en brannmur ikke kan tvinge en klient til å velge en resolver den aldri har fått vite om. På en klient med delt tunnel må du si rett ut hvilke domener som går til den interne resolveren. I en styrt maskinpark er nettleserpolicyen ofte det eneste håndtaket for DoH, siden nettleseren kan velge sin egen krypterte resolver uavhengig av systeminnstillingen.

Hvis du hopper over dette og går rett på brannmuren, ender du med en regel som slipper gjennom riktig resolver, og en klient som aldri bruker den. Regelen ser riktig ut, resolverloggen er tom, og kombinasjonen er vanskelig å feilsøke. Sett opp valget først, håndhev det etterpå.

Trinn 3: håndhev veien strengt

Legg til nettverkstillatelsen for den tillatte veien: resolverens adresse, protokoll og port, og grensesnittet den skal gå ut over. Hold regelen begrenset til denne resolveren i stedet for å tillate all utgående DNS. De tre veiene nedenfor er de en moderne klient kan bruke, og bare den første dekkes av en port 53-regel.

Det er legitimt å blokkere DoH og DoT; det er det ikke å anta at en port 53-regel allerede har gjort det. En nettleser med DoH løser navn over en vei regelen din aldri har beskrevet, og en applikasjon som har sin egen resolver gjør det samme. Skriv opp hver vei du vil tillate og hver vei du vil avvise. En regel som ikke nevner en vei, har heller 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å flere resolvere i planen er ikke en lekkasje. Lekkasjen er en forespørsel som skulle gått til din resolver 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 se etter. Følg et internt og et offentlig navn under den tiltenkte policyen, og noter hvilken resolver som svarte på hvert av dem.

Et teststed som rapporterer resolveren din, er et hint og ikke et bevis, fordi det bare ser forespørslene som nådde det. Ta vare på forespørselen på klientsiden når du må vite hvilken vei den faktisk tok, og sammenlign de to observasjonene. Når de ikke stemmer, har du funnet en tilbakefall som ingen har dokumentert.

Er resolveradressen riktig men utilgjengelig, ligger problemet i ruting eller filtrering og ikke i policyen. Spor forespørselen til den adressen, og bekreft at svaret kommer tilbake på det forventede grensesnittet før du endrer noen resolverinnstilling.

Trinn 5: hold en vei tilbake åpen

Før du strammer inn DNS-tilgangen på gatewayen, må du bekrefte en gjenopprettingsmetode som ikke er avhengig av navneoppslag. En ødelagt resolver gjør det vanskeligere å nå alle reparasjonsverktøy, også dem du ville brukt for å reversere endringen. Hold en lokal konsoll eller en vei utenfor båndet åpen til den nye policyen er bevist. Fjern den først når policyen har tålt en gjentilkobling.

Etter en gjentilkobling eller en oppdatering av nettleserpolicyen bør du se på den faktiske tilstanden igjen, fordi begge kan endre resolveren uten at regelen din endres. Kravet er en kjent mottaker og en beskyttet vei for forespørslene, 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.