VPN DNS vs DoH ng browser: ang hindi masasabi ng leak test

Sinasabi ng pahina ng leak test na maayos ang DNS mo, sinasabi ng badge sa browser na secure, at hindi pa rin naglo-load ang panloob na wiki. Maaaring totoo ang tatlo nang sabay, dahil ang address ng resolver ay hindi kapareho ng patakarang pumili nito o ng landas na tinahak ng query. Ang tinatawag ng mga tao na DNS leak ay talagang isang tanong: aling resolver ang tumanggap ng pangalan, at sinasadya ba ang pagpiling iyon? Kailangan ng tatlong pagsusuri para maayos iyon, at ang huli lang ang may kinalaman sa pagbabago ng setting.

Mito uno: pinangalanan ng badge ang resolver mo

Nagre-resolve ang leak test ng isang probe name at iniuulat ang address na sumagot. Hindi nito iniuulat ang patakarang pumili ng resolver na iyon, at kapag ang query ay nakabalot sa DNS over HTTPS, hindi makikita ng middlebox sa landas ang pangalan. Dalawang magkaibang makina ang gumagawa ng parehong nakapapawing-pagod na badge: isa kung saan itinulak ng VPN ang 10.8.0.1 at ginagamit ito ng browser, at isa kung saan binale-wala ng browser ang listahan ng system at ipinadala ang pangalan sa sarili nitong naka-encrypt na provider sa loob ng tunnel.

Mahalaga ang pagkakaiba sa sandaling mabigo ang isang pribadong pangalan. Sa unang setup, sinasagot ng VPN resolver ang corporate zone; sa pangalawa, hindi ito kailanman tinanong ng browser, kaya hindi nagre-resolve ang maikling hostname at ang kabiguan ay mukhang sira ang VPN. Ang pagsusuri ay hindi isa pang leak test, ito ay paghahanap sa isang pangalang isang resolver lang ang nakakaalam.

Mito dos: umaalis ang browser sa tunnel

Pumipili ang DNS ng address, dinadala ng routing ang koneksyon, at magkaibang layer ang dalawa. Ang query na ipinadala sa pampublikong DoH provider ay TCP port 443 pa rin patungo sa isang address na maruroute. Kung ipinapadala ng route table mo ang default route sa tunnel, dumadaan din ang query na iyon sa tunnel. Hindi tinutukoy ng brand ng resolver ang landas.

Ang binabago ng DoH ng browser ay ang tatanggap ng mga pangalan. Tunay na desisyon iyon sa privacy at tunay na desisyon sa patakaran, pero hindi ito paglampas sa routing. Kung ang pangangailangan mo ay manatili ang mga pangalan sa operator ng VPN, nabibigo ang naka-encrypt na query sa ibang tao sa pangangailangang iyon habang ginagamit pa rin ang tunnel para sa aktuwal na koneksyon.

Mito tres: ine-override ng bawat VPN ang bawat browser

May mga mode, hindi switch, ang secure DNS sa browser: off, default provider na may fallback, custom template, o patakarang ipinapatupad ng operating system o ng organisasyon. Ang kaso ng fallback ang gumagawa ng pana-panahong ulat. Kapag hindi maabot ang naka-encrypt na endpoint, maaaring bumalik ang browser sa resolver ng system, kaya ang parehong laptop ay nagre-resolve ng pribadong pangalan nang tama tuwing Lunes at hindi tuwing Martes.

Kasabay nito, itinatakda ng karamihan ng VPN client ang system resolver kapag bumangon ang koneksyon at ibinabalik ang nauna kapag bumagsak ito. Ang browser na may hawak na custom na naka-encrypt na resolver ay hindi man lang napapansin ang pagbabalik na iyon. Ito ang dahilan kung bakit iba ang kilos ng parehong profile sa dalawang laptop at bakit mukhang tama ang resolv.conf habang nagtatanong pa rin ang browser sa ibang tao.

resolvectl status                 # per-link DNS servers and split-DNS domains
scutil --dns | head -30           # macOS resolver order for each domain
nslookup intranet.corp 10.8.0.1   # ask the VPN resolver directly

Patakbuhin ang mga iyon habang konektado, itala ang mga domain na inaangkin ng bawat resolver, at ihambing sa iniuulat ng browser tungkol sa sarili nitong mode. Ang dokumentasyon ng DoH ng Mozilla ay makatwirang paglalarawan kung paano dapat gumana ang default at fallback na pag-uugali ng browser.

Tatlo, hindi isa, ang input ng desisyon

Ang mga pribadong pangalan, tiwala sa operator at abot-kaalaman ang nagtatakda ng tamang kaayusan. Ang mga pangalang alam lang ng VPN resolver ay nagpipilit ng split DNS: ang pribadong suffix ay napupunta sa itinulak na resolver, ang lahat ng iba ay sumusunod sa patakarang pinili mo para sa mga pampublikong pangalan. Ang tiwala sa operator ang nagtatakda kung ang mga pampublikong pangalan ay dapat ding pumunta sa resolver na iyon o sa hiwalay na serbisyo. Ang abot-kaalaman ang nagtatakda kung magagamit man lang ang pinili mong naka-encrypt na resolver sa network na ito.

Wala sa mga row na ito ang pangkalahatang rekomendasyon. Ang resolver na pinapatakbo ng VPN ay nagsasama-sama ng mga obserbasyon sa operator na iyon; ang hiwalay na serbisyo ay nagdadagdag ng isa pang tatanggap ng mga tinatanong na pangalan. Wala sa mga kaayusan ang nagpapatunay ng anuman tungkol sa pagtago maliban kung babasahin mo ang patakaran.

Isulat ang desisyon kada profile, dahil nagbabago ang mga setting na ito. Ang profile na nagtulak ng resolver noong nakaraang buwan ay maaaring walang itulak ngayon, at masayang itatago ng browser ang lumang custom na endpoint na sumasagot pa rin. Ang dapat nasa tala ay ang address ng resolver, ang mga suffix na pag-aari nito at ang mode ng browser, hindi ang brand ng serbisyo.

Subukan ang patakarang akala mong na-configure mo

Subukan sa pamamagitan ng pangalan, hindi sa badge. I-resolve ang pampubliko at pribadong pangalan sa pamamagitan ng system resolver, pagkatapos ulitin sa loob ng browser gamit ang sarili nitong secure DNS setting sa mode na balak mong gamitin. Kung nabigo ang pribadong pangalan sa browser lang, natagpuan mo ang mismatch ng tatanggap nang hindi hinahawakan kahit isang setting ng VPN.

Pagkatapos, kumonekta muli at suriin ang pagbabalik, dahil doon nakatira ang mga bug sa handoff: idiskonekta, kumpirmahin na bumalik ang dating resolver, kumonekta muli, kumpirmahin na bumalik ang itinulak. Sa wakas, subukan ang browser na may managed policy kung mayroon ka, dahil maaaring tanggihan ng mode na iyon ang pagbabago mo nang buo at tahimik na itago ang dating resolver.

Simulan sa tanong ng namespace at maiiwasan mo ang karamihan nito. Kung kailangang maabot ng makina ang mga panloob na pangalan, ang naka-encrypt na resolver ng browser ay desisyon tungkol sa pampublikong kalahati lamang, at ang pribadong kalahati ay nananatili sa kung ano ang itinulak ng VPN.