Krypterer VPN-en din DNS, eller berre neste hopp?

Å slå på kryptert DNS på VPN-serveren vert ofte skildra som å tette ein lekkasje, og den skildringa gøymer kva samband som vart endra. Hoppet frå klienten til resolvaren og hoppet frå resolvaren til oppstraums er skilde samband med skilde eigarar. Krypterer du det eine, står det andre nøyaktig som det var.

Skriv ned kven som får spørjinga i kvar fase før du rører ei konfigurasjonsfil.

To oppsett ser like ut på ei innstillingsside

I det første oppsettet køyrer eininga DNS over TLS sjølv, og tunnelen fraktar berre det sambandet til ein resolvar du valde. TLS-økta tek slutt hos resolvaren, som tyder at resolvaren ser spørjinga, medan VPN-utgangen ser kryptert tekst han ikkje kan lese. I det andre oppsettet sender eininga vanleg DNS gjennom tunnelen til ein videresendar på VPN-verten, og den videresendaren opnar sitt eige krypterte samband til ein oppstraums resolvar. Begge ser ut som "kryptert DNS med VPN" i ei funksjonsliste, og dei plasserer den lesbare spørjinga i ulike bygningar.

Skilnaden er målbar, ikkje filosofisk. Leit etter TLS-økta på klienten eller på serveren, så veit du kva oppsett du faktisk har.

Kartlegg resolvarkjeda før du endrar henne

Tel resolvarane på vegen og nemn rolla til kvar av dei. Ein videresendande komponent overlet ei førespurnad til ein annan resolvar, medan ein rekursiv resolvar gjer arbeidet med å finne eit svar og kan snakke direkte med autoritative serverar. Desse rollene er definerte kvar for seg nettopp av denne grunnen, og resolvardefinisjonane i RFC 9076 er verd å lese før du går ut frå at det finst berre eitt oppstraums mål. Ein vert som køyrer sin eigen rekursive resolvar har ingen einaste "oppstraum" å kryptere, og det gjer heile planen ugyldig.

Spør så kva komponent klienten er sett opp til å bruke. Ei DNS-adresse som VPN-profilen sender ut, fortel kvar spørjingane går, ikkje kva prosess som svarar på dei.

Legg òg merke til åtferda ved feil. Viss den krypterte oppstraumen vert utilgjengeleg, feilar videresendaren då lukka, fell han tilbake til klartekst, eller fell han tilbake til ein annan resolvar? Den avgjerda høyrer heime i journalen, fordi ho endrar personvernløftet i det augneblinken tunnelen er minst sunn.

Stadfest kva hopp som er kryptert

Start på klienten og stadfest om han har ei TLS-økt til port 853. Ei spørjing som vert løyst rett gjennom port 53 provar ingenting om kryptering.

resolvectl status | grep -E "DNS Servers|DNS over TLS"
kdig +tls +tls-ca +tls-hostname=dns.example.net @198.51.100.53 example.com A

Flytt deg så til VPN-verten og leit etter det utgåande krypterte sambandet som videresendaren opna. Sokkeltabellen fortel om det finst ei oppstraums TLS-økt, og kva prosess som eig henne:

ss -tunp '( dport = :853 )'
dig @127.0.0.1 example.com A +short

Viser klienten ei TLS-økt og serveren ingen, er du i det første oppsettet, og serveren kan ikkje lese spørjingar han videresender på IP-nivå. Viser serveren TLS-økta og klienten vanleg port 53-trafikk inne i tunnelen, er du i det andre oppsettet: det vidare hoppet er verna, og videresendaren les framleis kvart namn eininga spør om. Det andre resultatet er ikkje ein feil, men å kalle det ende-til-ende-kryptering er gale.

Før opp eigaren og åtferda ved feil

Eigarskap avgjer kva du har lov til å love. Einingseigaren styrer eit kryptert samband på klientsida, medan VPN-administratoren styrer det vidare sambandet som videresendaren hans lagar. Den som ikkje driv nokon av dei, kan berre skildre vegen.

Før du slår på noko, sjekk intern namngjeving. Å sende organisasjonsnamn til ein offentleg resolvar er ikkje ei likeverdig løysing, og ei split-horizon-sone som berre finst inne i nettet vert ikkje løyst oppstraums i det heile. Test eitt internt og eitt offentleg namn etter endringa, og ta vare på resultatet saman med konfigurasjonsendringa. Viss den krypterte vegen bryt oppløysinga for interne vertar, er rettinga ein resolvarregel med avgrensa omfang, ikkje ein breiare tunnel.

Avslutt med å skrive éi setning per hopp: kva komponent som fekk spørjinga, om hoppet var kryptert, og kven som kan lese namnet. Når setninga om VPN-verten framleis seier at han kan lese spørjingar, bør dokumentasjonen seie det same, fordi eit diagram som påstår det motsette, vil verte trudd av nokon som aldri køyrde kommandoane.