Ang VPN DNS fallback mo: saan talaga napupunta ang query

Nagbago ang setting ng resolver mula sa pribadong address tungo sa pampublikong address, at agad dumarating ang konklusyon: may tumatagas sa tunnel. Minsan totoo ito. Kadalasan, ang fallback query ay naglakbay pa rin sa loob ng tunnel patungo sa resolver na pinili ng administrator, kaya naging desisyon ito sa patakaran at hindi depekto. Ang paghihiwalay sa mga kasong iyon ay nangangailangan ng tatlong katotohanan sa halip na isa, at ang una ay kung sino ang sumagot. Alamin kung sino ang tumanggap ng query, aling ruta ang nagdala nito at aling mga pangalan ang tinanong.

Ang fallback ay patakaran, hindi isang pag-uugali

Bawat kliyente ay kailangang magpasya kung ano ang gagawin kapag tumigil nang sumagot ang gustong resolver. Maaari nitong harangan ang resolusyon, subukang muli, gumamit ng naka-configure na alternatibo o ipaubaya sa operating system, at mula sa pananaw ng privacy ay apat na magkaibang produkto iyon. Ang pagbasa sa screen ng setting ay nagsasabi kung aling pag-uugali ang naka-configure; hindi nito sinasabi kung alin ang nangyari. Ang screen na may isang switch ay hindi naglalarawan ng apat na posibilidad.

Nagdaragdag ang mga browser ng sarili nilang layer. Ang browser na may naka-enable na secure na DNS ay maaaring mag-resolve ng pangalan sa pamamagitan ng sarili nitong piniling provider kahit na tumuturo sa ibang lugar ang operating system, na nangangahulugang maaaring hindi kailanman konsultahin ang patakaran ng tunnel client para sa mga kahilingang talagang mahalaga sa iyo. Suriin ang application na gumawa ng kahilingan, hindi lamang ang setting ng system.

Ang pagkakakilanlan ng kapalit na resolver ang unang katotohanang sulit itatag. Ang pampublikong resolver na pagmamay-ari ng provider na pinagkakatiwalaan mo na ay ibang sitwasyon kaysa sa address na ibinigay ng network kung saan ka naroroon. Bihirang sabihin ng address mismo kung alin sa dalawa ang tinitingnan mo.

Sino ang tumatanggap ng query pagkatapos ng pagpalit

Ang tatanggap at ang ruta ay independiyente, at ang kombinasyon lamang nila ang naglalarawan ng pagkalantad. Ang pampublikong resolver na naabot sa pamamagitan ng tunnel ay hindi kailanman nakikita ang address ng iyong access network, samantalang ang parehong resolver na naabot nang direkta ay nakikita ito. Parehong nagbubunga ng sagot ang dalawang kaso, at ang leak test na nag-uulat lamang ng address ng resolver ay ilalarawan silang magkapareho. Hingin ang interface kasama ng address kapag binabasa mo ang resulta.

Ginagawang kongkreto ng mga panloob na pangalan ang pagkakaiba. Karaniwang hindi kayang sagutin ng pampublikong resolver ang isang pangalang split-horizon, kaya nabigo ang query habang ang pangalan ay naisapubliko pa rin sa isang partidong walang karapatang makita ito. Kaya sabay na gumagalaw dito ang kakayahang magamit at privacy sa halip na magpalitan.

Maaari ring dalhin ng tunnel ang query sa resolver na hindi pinapatakbo ng provider ng VPN, dahil nagpapasa ang tunnel sa halip na nagre-resolve. Nakikita ng host na nagpapasa ang query sa plaintext at pagkatapos ay binubuksan ang sarili nitong koneksyon patuloy, na nagpoprotekta sa susunod na hop nang hindi pinoprotektahan ang una.

Suriin ang ruta at ang tatanggap nang sabay

Obserbahan ang mga packet sa halip na ang configuration. Itanong sa system kung aling resolver ang gagamitin, pagkatapos ay kumpirmahin na talagang umalis ang query mula sa inaasahang interface patungo sa inaasahang address.

resolvectl status | grep -E "Current DNS Server|DNS Servers|DNSOverTLS"
dig +short example.com
tcpdump -ni any udp port 53 or tcp port 853

Kung ipinapakita ng capture na umaalis ang query sa pisikal na interface habang naka-up ang tunnel, nilagpasan ng fallback ang tunnel anuman ang sinasabi ng listahan ng resolver. Kung lumitaw ito sa interface ng tunnel, ang tanong ay kung sino ang nagpapatakbo ng malayong dulo at ano ang itinatago nito.

Ulitin ang pagsusuri para sa isang panloob at isang pampublikong pangalan. Ang panloob na query ang lugar kung saan karaniwang inilalantad ng fallback configuration ang sarili nito, dahil ang resolver na hindi makasagot ay tumatanggap pa rin ng tanong.

Magpasya kung dapat pahintulutan ang fallback

Kung ang kinakailangan ay huminto ang resolusyon kapag hindi available ang gustong resolver, i-configure ang patakaran sa pagpapatupad na nabibigo nang sarado at tanggapin ang kahihinatnan: hindi mare-resolve ang mga pangalan sa panahon ng pagkawala. Iyon ay sinadyang kalakalan sa availability at hindi malfunction, at dapat sabihin ito ng disenyo bago pa mangyari ang pagkawala.

Kung ang kinakailangan lamang ay hindi dapat lumabas ng tunnel ang mga query, maaaring katanggap-tanggap ang pampublikong resolver na naabot sa pamamagitan ng tunnel basta't nauunawaan ang operator at ang patakaran nito sa pagpapanatili. Ang gayong pagtanggap ay paghuhusga tungkol sa ikatlong partido at hindi pahayag tungkol sa cryptography, at pag-aari ito ng sinumang may hawak ng pag-aangkin sa privacy. Kung dapat patuloy na gumana ang mga panloob na pangalan, ang fallback ay dapat resolver na may hawak ng mga panloob na zone, na karaniwang nangangahulugang ang target ng fallback ay ibang server at hindi ibang pamilya ng address.

Idokumento ang kinalabasan bilang isang pangungusap tungkol sa pag-uugali: aling resolver ang tumatanggap ng mga query sa normal na operasyon, alin ang tumatanggap sa mga ito pagkatapos ng pagkabigo, at kung nagre-resolve ang mga panloob na pangalan sa ikalawang kaso. Ang leak test na sa huli ay naglo-load ng pahina ay nagpapatunay ng mas kaunti kaysa sa pangungusap na iyon, dahil ang pahina ay maaaring mag-load sa pamamagitan ng resolver na hindi dapat kailanman konsultahin.