Tillad kun DNS gennem din egen VPN-resolver: en gennemgang

Følg et enkelt navneopslag fra det øjeblik, du taster det. Browseren spørger styresystemet, styresystemet spørger den resolver, som dets politik vælger, og forespørgslen forlader enheden gennem et eller andet interface med en eller anden transport. Dit VPN-design siger, at svaret skal komme fra en bestemt resolver ad en bestemt vej. Kløften mellem de to udsagn er det, du konfigurerer og derefter håndhæver.

Trin 1: navngiv resolveren og vejen

Skriv tre ting ned, før du rører en firewall: resolverens adresse, den protokol og port du forventer, og det interface forespørgslen skal forlade enheden ad. Uden den liste er en regel et gæt om trafik og ikke håndhævelse af en beslutning. Et VPN kan bære applikationsdata, mens DNS følger en særskilt ordning, og det er ikke i sig selv en fejl. Det er, hvad der sker, når ingen har fortalt klienten andet.

At navngive vejen eksplicit er forskellen mellem et design og et tilfælde. Det giver dig også noget at teste senere, fordi hver observation kan sammenlignes med en skriftlig forventning. Opbevar listen i ændringsbilletten og ikke i nogens hoved.

Trin 2: sæt politikken, hvor den faktisk bor

Valget af resolver hører til klienten: styresystemets netværkskonfiguration, VPN-klientens egne indstillinger eller en administreret browserpolitik. Sæt den der først, med den mekanisme platformen understøtter, for en firewall kan ikke tvinge en klient til at vælge en resolver, den aldrig har hørt om. På en klient med delt tunnel skal du udtrykkeligt sige, hvilke domæner der går til den interne resolver. I en administreret flåde er en browserpolitik ofte det eneste håndtag for DoH, fordi browseren kan vælge sin egen krypterede resolver uafhængigt af systemindstillingen.

Spring det over og gå direkte til firewallen, og du får en regel, der tillader den rigtige resolver, plus en klient, der aldrig bruger den. Reglen ser rigtig ud, og resolverloggene forbliver tomme, hvilket er et forvirrende par at fejlfinde. Konfigurer først valget, og håndhæv det derefter.

Trin 3: håndhæv vejen snævert

Tilføj nu netværkstilladelsen for den tilladte vej: resolverens adresse, protokollen og porten samt det interface, den skal forlade enheden ad. Hold reglen afgrænset til den resolver i stedet for at tillade al udgående DNS. De tre veje nedenfor er dem, en moderne klient kan tage, og kun den første dækkes af en regel for port 53.

At blokere DoH og DoT er legitimt; at antage, at en regel for port 53 allerede har blokeret dem, er ikke. En browser med DoH opløser navne ad en vej, din regel aldrig har beskrevet, og en applikation med sin egen resolver gør det samme. Skriv hver vej ned, du vil tillade, og hver enkelt, du vil afvise. En regel, der ikke navngiver en vej, har ikke besluttet noget om den.

Trin 4: følg private og offentlige navne

Delt DNS sender bevidst kun private navnerum til en intern resolver, mens offentlige navne går andre steder hen, så mere end én resolver i designet er ikke en lækage. Lækagen er en forespørgsel, der burde være gået til din resolver og dukker op et andet sted, eller en utilgængelig tilsigtet vej, der får klienten til at falde tavst tilbage. De to tilfælde er dem, du skal lede efter. Følg et internt og et offentligt navn under den tilsigtede politik, og noter hvilken resolver der svarede på hvert.

Et testsite, der rapporterer din resolver, er et fingerpeg og ikke et bevis, fordi det kun ser de forespørgsler, der nåede frem til det. Fang forespørgslen på klientsiden, når du skal vide, hvilken vej den faktisk tog, og sammenlign de to observationer. Når de er uenige, har du fundet et tilbagefald, som ingen har dokumenteret.

Hvis resolveradressen er rigtig, men utilgængelig, er problemet rutning eller filtrering og ikke politik. Spor forespørgslen til den adresse, og bekræft at svaret vender tilbage på det forventede interface, før du ændrer nogen resolverindstilling.

Trin 5: behold en vej tilbage

Før du strammer DNS-adgangen på gatewayen, skal du bekræfte en gendannelsesmetode, der ikke afhænger af navneopslag. En ødelagt resolver gør hvert reparationsværktøj sværere at nå, også dem du ville bruge til at rulle ændringen tilbage. Hold en lokal konsol eller en out-of-band-vej åben, indtil den nye politik er bevist. Fjern den først, når politikken har overlevet en genopkobling.

Efter en genopkobling eller en opdatering af browserpolitikken skal du inspicere den effektive tilstand igen, fordi begge kan ændre resolveren uden at ændre din regel. Kravet er en kendt modtager og en beskyttet vej for forespørgslerne, ikke en beroligende resolveretikette på et skærmbillede. RFC 8484-specifikationen for DNS over HTTPS er reference for den krypterede vej, som din portregel ikke ser.