Bakit ipinapakita ng resolv.conf ang DNS ng iyong VPN pero binabalewala ito ng mga paghahanap

Walang mukhang mali sa mga log: aktibo ang interface, iniuulat ng resolver ang DNS server ng VPN, at nakalista ito sa file sa disk. Gayunpaman, ang isang panloob na pangalan ng host ay nireresolba pa rin sa pamamagitan ng lokal na router. Hindi nagkakasalungat ang tatlong pahayag, dahil ang file, ang estado ng bawat link at ang landas ng paghahanap ay magkakaibang bagay na nagkataong may parehong pangalan. Ang sumusunod ay ang landas na talagang tinatahak ng isang query sa isang host na may systemd-resolved.

Tatlong bagay na tinatawag na resolv.conf

Sa isang host na may resolved, ang /etc/resolv.conf ay karaniwang simbolikong link patungo sa /run/systemd/resolve/stub-resolv.conf. Nasa target na iyon ang address ng lokal na stub listener, 127.0.0.53, kasama ang mga domain ng paghahanap na kinompute ng resolved. Ito ay tanawin ng estado, hindi ang estado mismo.

Nabubuhay ang estado sa configuration ng resolved bawat link, kaya maaaring sumalungat ang resolvectl status sa file at tama pa rin. Bawat link ay may sariling mga server at sariling mga domain ng routing, at kinokonsulta ng stub ang datos na iyon kapag may query na dumarating. Inilalarawan ng manwal ng systemd-resolved ang mga nabuong file at ang modelo bawat link; ang paghihiwalay ng tanawin at estado ang bahaging sulit tandaan. Ang pagbabago sa target ng simbolikong link ay nagbabago sa binabasa ng tradisyonal na mga client, hindi sa alam ng resolver.

Ang ikatlong bagay, /run/systemd/resolve/resolv.conf, ay nagpapadagdag ng bawat link sa isang listahan ng server. Ang programang nakaturo sa file na iyon ay nagpapadala ng mga query nang direkta sa mga nakalistang server at lumalaktaw sa stub, kaya hindi na ito saklaw ng patakaran bawat link. Kaya maaaring magkaibang sagot ang dalawang programa sa parehong makina para sa parehong pangalan, at wala sa kanila ang sira.

Sundan ang isang paghahanap sa NSS

Binabasa ng glibc ang /etc/nsswitch.conf para magpasya kung sino ang sasagot sa isang pangalan. Ang linyang hosts na may resolve ay naghahatid ng tanong sa nss-resolve, na nagtatanong sa resolved sa pamamagitan ng D-Bus at tumatanggap ng sagot bawat link. Ang linyang may files dns lamang ay nagpapadala ng query sa address na hawak ng /etc/resolv.conf.

Ang nag-iisang linyang iyon ang nagpapaliwanag sa karamihan ng hindi pagkakasundo ng browser at ng dig. Binabasa ng dig ang resolv.conf nang direkta at hindi kailanman hinahawakan ang NSS, kaya sinusubukan nito ang stub o isang upstream server sa halip na ang landas na ginagamit ng aplikasyon. Dumadaan ang getent hosts internal.example sa NSS, at ang paghahambing ng sagot nito sa sagot ng dig ang unang kapaki-pakinabang na pagsukat.

Ang mga aplikasyong may sariling resolver, o nagsasalita ng DNS sa HTTPS patungo sa isang fixed endpoint, ay lumalaktaw sa parehong landas. Walang anuman sa resolv.conf o sa estado ng resolved ang pumipigil sa kanila.

Tingnan kung kanino ang file at saan ito nakaturo

Basahin ang kadena ng link bago magbago ng anuman, dahil ang pagmamay-ari ang nagpapasya kung aling file ang awtoritatibo. Ang bawat utos sa ibaba ay nagbabasa lamang ng estado.

stat -c '%N' /etc/resolv.conf
resolvectl status --no-pager
grep '^hosts' /etc/nsswitch.conf
ls -l /run/systemd/resolve/

Ang unang linya ay nagpi-print ng link at ng target nito nang magkasama, at ang ordinaryong file na pagmamay-ari ng isang VPN script ay nangangahulugang hindi kailanman itinuturing ng resolver ang pagsulat na iyon bilang input. Inililista ng output ng estado ang mga server bawat link at ang mga domain ng routing na nagpapasya kung saan pupunta ang bawat query. Sinasabi ng linyang nsswitch kung kinokonsulta man lang ang stub, kaya ang isang stub address sa file na walang resolve doon ay nangangahulugang umaabot ang mga query sa lokal na listener habang walang namamahala sa paghahati. Mahalaga rin ang huling listahang iyon, dahil ang host na walang stub-resolv.conf ay hindi nagpapatakbo ng kaayusang inilalarawan dito.

Kung ang kadena ay nagtatapos sa isang file na pinamamahalaan ng ibang package, ang VPN client at ang package na iyon ang dalawang may-ari na kailangang pagkasunduin. Ang pagpapalit ng link ay nagtatapon ng gawa ng isang may-ari at iniiwan ang gawa ng isa pa sa kinalalagyan nito.

Ayusin sa may-ari ng link

Dapat irehistro ng isang VPN connection ang mga server at domain nito sa sarili nitong link, pagkatapos ay bawiin ang mga iyon kapag nadiskonekta. Parehong ganoon ang gumagana ng resolved integration ng NetworkManager at ng sariling helper ng client; ang script na nagsusulat muli lamang ng resolv.conf ay hindi.

Sa isang link na umiiral na, ipinapakita ng runtime settings ang mekanismo. Naglalakip ang resolvectl dns tun0 10.40.0.53 ng server, at naglalakip ang resolvectl domain tun0 '~corp.example' ng routing domain. Ang tilde ang karakter na nagdadala ng bigat: hinihigpitan nito ang mga query para sa suffix na iyon sa link na ito at hinahayaan ang lahat ng iba, samantalang ang parehong halaga na wala ito ay nagiging domain ng paghahanap at naglalaho ang paghahati. Ang mga address na iyon ay halimbawa sa laboratoryo, hindi permanenteng configuration. Kumpirmahin gamit ang resolvectl query host.corp.example at basahin kung aling link ang sumagot.

Kailangan pa rin ng ruta ng isang rehistradong server. Kapag naabot ng query ang tamang link at nag-time out, ang depekto ay nasa pag-abot sa pamamagitan ng tunnel, hindi sa pagmamay-ari ng resolver.

Ano ang hitsura ng gumaganang estado

Ang malusog na resulta ay pare-pareho sa tatlong tanawin: tumutugma ang mga server bawat link sa ibinigay ng VPN, sinasaklaw lamang ng mga routing domain ang mga panloob na suffix, at nireresolba ng mahalagang aplikasyon ang isang panloob na pangalan habang ang pampublikong pangalan ay sumusunod pa rin sa lokal na landas. Ang isang matagumpay na query ay nagpapatunay ng mas kaunti kaysa sa pagkakasundong iyon.

Pagkatapos ay idiskonekta at ulitin ang parehong query. Ang client na iniiwan ang mga domain nito na rehistrado pagkatapos ng teardown ay gumagawa ng makinang nabibigo sa mga panloob na paghahanap makalipas ang mga oras, na walang bukas na tunnel at walang malinaw na dahilan.