Ang browser ay ibinukod mula sa tunnel, kinukumpirma ng pampublikong IP page na lumalabas ang trapiko nito sa koneksyon sa bahay, at hindi pa rin bumubukas ang panloob na wiki. Ang paglutas ng pangalan ay pumunta sa ibang lugar, at ang ibang lugar na iyon ay karaniwang ang resolver na itinakda ng VPN. Ang daanan ng data at daanan ng resolver ay magkahiwalay na desisyon sa karamihan ng disenyo ng split tunnel. Suriin kung alin ang aktwal na ginamit ng browser bago tawagin ang pagbubukod na sira.

Naghiwalay ang daanan ng data at daanan ng resolver

Inaalis ng pagbubukod ang mga packet ng isang application mula sa tunnel, na isang desisyon sa routing at firewall sa daanan ng data. Ang paglutas ng pangalan ay ibang paghahanap: may prosesong nagtatanong sa resolver ng system, at ang resolver na iyon ang nagpapasya kung aling server ang tatanggap ng tanong.

Puwedeng sinasadya at magkaiba ang dalawa. Ang isang deployment sa trabaho ay maaaring panatilihin ang mga panloob na namespace sa corporate resolver habang ipinapadala ang piling pampublikong pag-browse sa labas ng tunnel, dahil mismo hindi nalulutas ang mga panloob na pangalan sa ibang lugar. Ang nakakalitong kaso ay kabaligtaran: nabigo ang pampublikong site dahil hindi kailanman tinanong ng browser ang resolver na inaasahan ng deployment. Itala ang ruta at ang resolver nang hiwalay, at mawawala ang kalahati ng mga pagtatalo.

Alamin kung aling proseso ang nagtatanong

Ang browser ay maaaring gumamit ng resolver ng system, ng sarili nitong naka-encrypt na DNS service, o ng resolver na itinatalaga ng operating system bawat network. Ang una ay sumusunod sa patakaran ng platform, ang pangalawa ay tuluyang lumalabpas sa patakarang iyon, at ang pangatlo ay nakadepende sa kung aling link iruruta ang query.

resolvectl status
resolvectl query intranet.example.net
dig +short +time=2 intranet.example.net @10.52.0.2
scutil --dns | head -n 40

Basahin ang umiiral na configuration bago mag-test: aling mga link ang may DNS server, anong namespace ang hinihingi, at kung pinapalitan ng patakaran bawat pangalan ang default. Sa Linux gumagamit ang split DNS ng routing domain; sa Windows ginagawa ng name resolution policy table ang parehong trabaho para sa namespace. Wala sa dalawa ang nakikita mula sa pahina ng leak test.

Magpasya kung aling resolver ang makakakita ng aling pangalan

Isulat ang nilalayong mapping bago magbago ng anuman: panloob na pangalan sa corporate resolver, pampublikong pangalan sa serbisyong pinapayagan ng patakaran, at mga exception na may may-ari. Kung wala ang listahang iyon, ang bawat label ng leak test ay nagiging debate sa patakaran na walang makapagtatapos.

Pagkatapos suriin ang sariling setting ng browser, dahil ang naka-encrypt na DNS sa browser ay inilalapat bago matanggap ng operating system ang query. Ang gumamit na nag-enable nito para iwasan ang captive portal ay tahimik na pinatungan ang resolver na pinili ng deployment. Desisyon iyon sa configuration at hindi leak, at karapat-dapat itong maging desisyon kaysa blocklist.

Huwag muling isulat ang bawat DNS field para maging berde ang isang test label. Inilalarawan ng label ang isang query mula sa isang proseso sa isang sandali.

Suriin nang hiwalay ang query at koneksyon

Subukan ang dalawang daanan nang hiwalay. Ipinapakita ng connection test ang ruta ng data, at ipinapakita ng resolver test kung sino ang tumanggap ng pangalan.

curl -sS --max-time 8 https://api.ipify.org
resolvectl query example.net
dig +short example.net

Tanungin din ang resolver nang tahasan, para maipatungkol ang pagkabigo sa server at hindi sa daanan. Pagkatapos i-restart ang browser at ulitin, dahil nagka-cache ang mga application ng negatibong sagot at ang lumang pagkabigo ay mukhang tuluy-tuloy.

Pagkatapos ng aprubadong pagbabago, itala ang ruta ng data at ang tatanggap ng resolver bilang dalawang hiwalay na linya kasama ang petsa. Kung babalik ang pag-uugali sa susunod na muling pagkonekta, ang profile na nagbibigay nito ang dapat ayusin, hindi ang browser.

Kaugnay na mga artikulo