A e kripton VPN-i yt DNS-në apo vetëm hopin tjetër?

Aktivizimi i DNS-së së kriptuar në serverin VPN përshkruhet shpesh si mbyllje e një rrjedhjeje, dhe ai përshkrim fsheh se cila lidhje ndryshoi. Hopi nga klienti te zgjidhësi dhe hopi nga zgjidhësi te niveli i sipërm janë lidhje të veçanta me pronarë të veçantë. Kriptimi i njërës e lë tjetrën saktësisht siç ishte.

Shkruaj kush e merr kërkesën në çdo fazë para se të prekësh një skedar konfigurimi.

Dy rregullime duken njësoj në faqen e cilësimeve

Në rregullimin e parë pajisja ekzekuton vetë DNS over TLS, dhe tuneli thjesht e transporton atë lidhje te një zgjidhës që zgjodhe. Sesioni TLS përfundon te zgjidhësi, që do të thotë se zgjidhësi e sheh kërkesën, ndërsa dalja e VPN-së sheh tekst të kriptuar që nuk mund ta lexojë. Në rregullimin e dytë pajisja dërgon DNS të zakonshëm përmes tunelit te një përcjellës në hostin VPN, dhe ai përcjellës hap lidhjen e vet të kriptuar me një zgjidhës të sipërm. Në një listë funksionesh të dyja duken si "DNS i kriptuar me VPN", dhe e vendosin kërkesën e lexueshme në ndërtesa të ndryshme.

Diferenca është e matshme, jo filozofike. Kërko sesionin TLS te klienti ose te serveri dhe do të mësosh se cilin rregullim ke në të vërtetë.

Hartografo zinxhirin e zgjidhësve para se ta ndryshosh

Numëro zgjidhësit në rrugë dhe emërto rolin e secilit. Një komponent përcjelljeje ia dorëzon një kërkese një zgjidhësi tjetër, ndërsa një zgjidhës rekurziv bën punën e gjetjes së një përgjigjeje dhe mund të flasë drejtpërdrejt me serverë autoritativë. Këto role janë përcaktuar veçmas pikërisht për këtë arsye, dhe përkufizimet e zgjidhësve të RFC 9076 ia vlen të lexohen para se të supozosh se ekziston një destinacion i vetëm i sipërm. Një host që ekzekuton zgjidhësin e vet rekurziv nuk ka një "nivel të sipërm" të vetëm për të kriptuar, gjë që e bën të pavlefshëm të gjithë planin.

Pastaj pyet cili komponent është konfiguruar të përdorë klienti. Një adresë DNS e dhënë nga profili VPN të tregon ku shkojnë kërkesat, jo cili proces u përgjigjet.

Vër re edhe sjelljen në dështim. Nëse niveli i sipërm i kriptuar bëhet i paarritshëm, a dështon përcjellësi i mbyllur, kthehet në tekst të hapur apo kalon te një zgjidhës tjetër? Ai vendim duhet të jetë në regjistër, sepse ndryshon garancinë e privatësisë në momentin kur tuneli është më pak i shëndetshëm.

Verifiko cili hop është i kriptuar

Nis nga klienti dhe konfirmo nëse mban një sesion TLS drejt portës 853. Një kërkesë që zgjidhet saktë përmes portës 53 nuk provon asgjë për kriptimin.

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

Pastaj kalo te hosti VPN dhe kërko lidhjen dalëse të kriptuar që hapi përcjellësi. Tabela e socket-eve të tregon nëse ekziston një sesion TLS i sipërm dhe cili proces e zotëron:

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

Nëse klienti tregon një sesion TLS dhe serveri asnjë, je në rregullimin e parë dhe serveri nuk mund të lexojë kërkesat që përcjell në shtresën IP. Nëse serveri tregon sesionin TLS dhe klienti trafik të zakonshëm të portës 53 brenda tunelit, je në rregullimin e dytë: hopi pasues është i mbrojtur, dhe përcjellësi vazhdon të lexojë çdo emër që pajisja kërkon. Ai rezultat i dytë nuk është dështim, por ta quash kriptim skaj-më-skaj është gabim.

Regjistro pronarin dhe sjelljen në dështim

Pronësia vendos se çfarë të lejohet të premtosh. Pronari i pajisjes kontrollon një lidhje të kriptuar në anën e klientit, ndërsa administratori i VPN-së kontrollon lidhjen pasuese që krijon përcjellësi i tij. Kush nuk operon asnjërën prej tyre mund vetëm ta përshkruajë rrugën.

Para se të aktivizosh diçka, kontrollo emërtimin e brendshëm. Dërgimi i emrave të organizatës te një zgjidhës publik nuk është dizajn ekuivalent, dhe një zonë split-horizon që ekziston vetëm brenda rrjetit nuk do të zgjidhet fare në nivelin e sipërm. Testo një emër të brendshëm dhe një emër publik pas ndryshimit, dhe mbaj rezultatin bashkë me ndryshimin e konfigurimit. Nëse rruga e kriptuar prish zgjidhjen për hostet e brendshme, rregullimi është një rregull zgjidhësi me shtrirje të kufizuar, jo një tunel më i gjerë.

Përfundo duke shkruar një fjali për çdo hop: cili komponent e mori kërkesën, a ishte i kriptuar ai hop dhe kush mund ta lexojë emrin. Kur fjalia për hostin VPN vazhdon të thotë se ai mund t'i lexojë kërkesat, dokumentacioni duhet ta thotë këtë, sepse një diagram që pretendon të kundërtën do të besohet nga dikush që nuk i ka ekzekutuar kurrë komandat.