Kinukuha ng DNS ng VPN ang bawat paghahanap: ayusin ang dns-priority sa NetworkManager

Ikonekta ang VPN ng opisina at biglang lahat ng paghahanap ng pangalan ay napupunta sa resolver ng kumpanya. Nalulutas pa rin ang mga pampublikong pangalan, kaya walang mukhang sira hanggang mabigo ang pangalan ng lokal na printer o may split-horizon record na magbalik ng address ng opisina. Sa ilang setup ng Fedora, kabaligtaran ang nangyayari: patuloy na sumasagot ang resolver ng provider pagkatapos na bumangon ang tunnel. Parehong isang tanong ang dalawa — aling resolver ang may-ari ng query na ito — at sa mga sistemang NetworkManager, nabubuhay ang sagot sa mga DNS property ng bawat koneksyon.

Dalawang koneksyon, isang nananalong resolver

Bawat koneksyon ay nagdedeklara ng prioridad ng DNS. Ang mga ordinaryong koneksyon ay 50 bilang default at ang mga VPN ay 0, at nananalo ang mas mababang halaga. Iyon mismong default ang dahilan kung bakit tahimik na nalalampasan ng koneksyon ng VPN ang kable para sa bawat domain na inaangkin nito: tinatalo ng zero ang limampu nang walang pumili nito.

Inaayos ng prioridad ang mga kandidato. Hindi nito nililimitahan kung ano ang itatanong sa panalo. Ang koneksyon ng VPN na walang search domain ay inaangkin ang lahat, kaya ang pagpili dito ay nagpapadala rin ng mga pampublikong query sa loob ng tunnel at, sa disenyong split-tunnel, doon kung saan nagpapasa ang resolver ng kumpanya.

Prioridad ang nagtatakda ng pagkakasunod-sunod, listahan ng paghahanap ang nagtatakda ng pagmamay-ari

nmcli -f connection.id,ipv4.dns,ipv4.dns-search,ipv4.dns-priority con show "Corp VPN"
resolvectl status
readlink -f /etc/resolv.conf

Ang listahan ng paghahanap ang pahayag ng pagmamay-ari. Ang hubad na domain tulad ng corp.example ay nagiging suffix ng paghahanap at routing domain. Ang anyong para sa routing lamang ~corp.example ay nagpapadala ng mga paghahanap sa ilalim ng suffix na iyon sa koneksyong ito nang hindi idinadagdag ang domain sa maiikling pangalan. Ang tildeng iyon ang pagkakaiba ng «tanungin ang server na ito» at «tanungin ang server na ito at tapusin ang aking pagta-type».

Gamitin ang dalawang anyo kapag nagta-type ang mga gumagamit ng maiikling hostname at ang mga record ay tinutugunan din ng ganap na kwalipikadong pangalan. Gamitin lamang ang anyong routing kapag gusto mo ang paghahati nang hindi binabago kung paano kinukumpleto ng resolver ang hubad na pangalan.

Pagkatapos, gawing tahasan ang kagustuhan at i-activate muli:

nmcli con modify "Corp VPN" ipv4.dns-priority -100
nmcli con modify "Corp VPN" ipv6.dns-priority -100
nmcli con modify "Corp VPN" ipv4.dns-search "~corp.example,corp.example"
nmcli con up "Corp VPN"

Ang negatibong prioridad ay ang dokumentadong paraan upang sabihing «piliin ang koneksyong ito», at ang pagtatakda ng parehong pamilya ng address ay nagpapanatili ng pare-parehong pag-uugali sa host na may konektibidad na IPv6. Ang pagbabago ng property nang hindi ini-activate muli ang koneksyon ay walang binabago sa kasalukuyang tumatakbo, kaya nagtatapos ang pagkakasunod-sunod sa tahasang up.

Hayaang hawakan ng systemd-resolved ang paghahati

Ang default na plugin ng dnsmasq ay naglalagay ng mga query sa isang lokal na resolver, kaya nananatiling magaspang ang paghihiwalay bawat link. Inilalantad ng systemd-resolved ang paghahati bawat link, at pinapangalanan ng resolvectl query ang link na sumagot.

systemctl enable --now systemd-resolved
ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf
systemctl restart systemd-resolved NetworkManager
resolvectl query build.corp.example

Pagkatapos nito, dinadala ng link ng kumpanya ang corp.example at pinaglilingkuran ng pampublikong resolver ang natitira. Kapag umabot ang query sa maling link, pinapangalanan ng utos ang link na sumagot dito, at mas mabuting malaman iyon kaysa sa address lamang.

Itugma ang disenyo ng DNS sa uri ng tunnel

Ang mga disenyo ng privacy na nagpapadala ng lahat sa tunnel ay hindi dapat magdala ng listahan ng paghahati, dahil ibabalik nito ang mga pampublikong pangalan sa lokal na resolver at papawiin ang layunin. Ang mga disenyong split-tunnel ay nangangailangan nito: kung wala ito, nakikita ng resolver ng kumpanya ang bawat pampublikong query, at nasisira ang setup sa sandaling bumagsak ang tunnel.

Pagkatapos, may kill switch na humaharang sa DNS sa labas ng tunnel. Nalulutas ang mga pangalan para sa mga zone ng tunnel at nabibigo sa lahat ng ibang lugar habang perpektong malusog ang koneksyon. Ang mga magagawang sagot ay tahasang pahintulot para sa resolver ng LAN o lokal na cache na nagpapasa lamang ng zone ng kumpanya, at ang alinman sa dalawa ay eksepsyon na may may-ari, hindi depekto sa tunnel.

Ang profile na nagsusulat muli ng configuration ng resolver sa pagsisimula ng interface ay halos ganoon din ang inaasal: kapag hindi maabot ang lokal na resolver, ang mga pangalang alam lamang ng tunnel ang malulutas. Anuman ang mekanismong naaangkop, isulat kung aling mga pangalan ang dapat gumana sa bawat estado, at ibigay ang listahang iyon sa sinumang humahawak ng mga ulat.

I-verify bawat link, pagkatapos muli pagkatapos kumonekta muli

Magtanong ng isang panloob at isang pampublikong pangalan, at tingnan kung saan talaga pumupunta ang query. Sinasabi ng pahina ng pagsusuri ng leak kung aling resolver ang sumagot, hindi kung aling link ang pinili ng sistema, kaya wala itong sinasabi tungkol sa pagkakasunod-sunod na kakaset mo lang.

Patakbuhin muli ang dalawang query pagkatapos mag-disconnect at kumonekta muli. Naaangkop muli ang mga prioridad kapag nag-activate ang koneksyon, at ang lumang symbolic link ay maaaring mabuhay sa isang upgrade na walang naaalala. Ang nais mong maitala sa huli ay kung aling resolver ang may-ari ng aling suffix, kasama ang isang check na wasto pa rin bukas.