Bakit nagre-resolve ang panloob na hostname sa dig pero nabibigo sa curl sa VPN

Ang laptop mo ay nasa VPN, sumasagot ang dig service.internal.example ng 10.x address, at lumalabas pa rin ang curl na may Could not resolve host. Hindi ang tunnel ang problema: dinala nito ang dig query nang walang reklamo. Ang pagkakaiba ay kung sino ang nagtatanong. Nagpapadala ang dig ng isang query sa isang server na pinangalanan mo, samantalang ang curl ay dumadaan sa lookup chain ng operating system, at may sariling mga patakaran ang chain na iyon kung aling server ang tatanungin.

Dalawang lookup para sa isang pangalan

Ang dig ay sarili nitong stub resolver. Binabasa nito ang /etc/resolv.conf, pumipili ng nameserver, nagpapadala ng isang A o AAAA query at ipinapakita ang sagot. Nilalaktawan nito nang buo ang nsswitch at walang alam sa estado kada link na itinatago ng systemd-resolved o NetworkManager sa labas ng file na iyon, kaya ang sagot ng dig ay maaaring tama at wala pa ring masabi tungkol sa makikita ng aplikasyon mo.

Tumatawag ang mga aplikasyon sa getaddrinfo, at dumadaan ang getaddrinfo sa mas mahabang chain: ang pagkakasunod-sunod ng mga module ng nsswitch, pagkatapos ang module na humahawak sa pangalan, at sa huli ang resolver na itinayo mula sa kasalukuyang link configuration. Sa isang systemd machine ang query ay pumupunta sa 127.0.0.53 at pumipili ang systemd-resolved ng upstream server kada link batay sa routing domain na nakakabit sa tun interface.

Dalawang command ang naghihiwalay sa mga layer na iyon nang hindi nanghuhula:

getent ahosts service.internal.example
resolvectl query service.internal.example

Ginagamit ng getent ang parehong landas gaya ng curl, kaya ang pagkabigo ng getent sa tabi ng gumaganang dig ay naglalagay ng sira sa patakaran ng paghahanap at hindi sa routing ng packet. Nagpapakita rin ang resolvectl query ng interface at upstream na nagbigay ng sagot, na nagpapakita kung ang link ng tunnel o ang pisikal na link ang nanalo sa desisyon.

Basahin ang resolver na aktwal na ginagamit ng aplikasyon

Ang /etc/resolv.conf ay ginagawa sa karamihan ng desktop, at may tatlong paraan ang isang VPN client para makipag-ugnayan dito: magdagdag ng nameserver sa unahan, i-overwrite ang file, o ibigay ang mga server nito sa NetworkManager at hayaang isulat muli ito ng daemon. Ang pangatlong pattern lang ang nagpapanatili ng DNS kada link, dahil nananatiling nakakabit ang mga server sa isang interface sa halip na patagin sa isang global na listahan.

Sa mga NetworkManager system ang resulta ay nakadepende sa backend sa /etc/NetworkManager/NetworkManager.conf:

[main]
dns=systemd-resolved

Sa dns=default ang mga server ng client ay pinagsama sa resolv.conf sa panalong pagkakasunod-sunod, at ang isang pribadong lookup ay maaari pa ring mapunta sa pampublikong resolver. Sa backend na nakakaintindi ng mga link, systemd-resolved o dnsmasq, nananatiling limitado sa tunnel ang mga server ng tunnel at doon lang pumupunta ang mga pangalang tumutugma sa routing domain nito. Ang limitasyong iyon ang ibig sabihin ng split DNS sa praktika, at iyon ang pirasong kadalasang kulang kapag sinasabi ng isang client na sinusuportahan nito.

Basahin ang estado bago baguhin ang anuman:

resolvectl status
resolvectl dns tun0

Gusto mong makita ang tun interface na nakalista na may DNS server at routing domain para sa pribadong suffix, na ipinapakita bilang ~internal.example. Walang server sa link ay nangangahulugang walang ipinadala ang client. Ang server na walang domain ay nangangahulugang ang mga lookup ay lahat pumupunta doon o wala, depende sa client, at hindi split DNS ang alinman sa dalawa.

Kung saan masyadong maaga ang pagtatapos ng nsswitch sa lookup

Ganito ang hitsura ng karaniwang desktop line:

hosts: files mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] dns myhostname

Hinahawakan ng mdns4_minimal ang multicast DNS at inaangkin ang bawat pangalang nagtatapos sa .local. Ang isang Kubernetes service tulad ng api.infra.svc.cluster.local ay nagtatapos din sa .local. Kapag iniulat ng mDNS module ang NOTFOUND, tinatapos ng aksyon na [NOTFOUND=return] ang buong lookup sa halip na magpatuloy sa dns module, kaya hindi kailanman naipapadala ang pangalan sa resolver ng VPN. Nilalaktawan ng dig nang lubusan ang file, at iyon mismo ang dahilan kung bakit hindi nagkakasundo ang dalawang tool.

Iyon ang pinakamatalas na kontrast sa problemang ito, at bumababa ito sa isang salita sa isang configuration file na mas matanda pa sa VPN mo. Ang pagpapalit ng aksyon sa [NOTFOUND=continue] ay nagpapanatili ng mDNS para sa mga printer at lokal na device habang hinahayaang makita ng DNS ang pangalan. Gumagana rin ang pagpapalit ng linya ng hosts: files dns at ito ay mas magaspang: inaalis nito ang .local resolution para sa printer na aktwal mong ginagamit.

Mga pangalang naninirahan sa isang network lang

Ang mga pribadong zone ay awtoritatibo sa isang lugar lang. Ang isang AWS name tulad ng ip-10-0-4-31.eu-west-1.compute.internal ay sinasagot sa pamamagitan ng VPC resolver ng rehiyon na iyon, at habang nasa parehong rehiyon ang VPN endpoint mo at ang resource. Kumonekta sa isang endpoint sa Frankfurt, magtanong ng compute.internal name mula sa Ireland, at wala mang lokal na setting ang makakatulong: ang zone na may hawak ng record ay hindi maabot mula roon.

Ang mga search domain ay gumagawa ng salamin ng larawan. Ang hubad na service ay kinukumpleto ng suffix na sa tingin ng resolver ay naaangkop, at sa isang VPN link ay maaaring talunin ng lokal na domain ang corporate. Magtanong na may tuldok sa dulo para alisin ang hula, getent ahosts service.internal.example., at kung gumagana iyon habang nabibigo ang maikling pangalan, ang pagwawasto ay ang search domain sa tunnel, hindi ang address ng server.

Ang mga managed client ay nagdadagdag ng pangatlong layer sa ibabaw ng resolver ng system. Ang isang Windows VPN profile ay maaaring magdala ng sarili nitong patakaran sa pag-resolve ng pangalan, mga patakaran kada app at isang NRPT table na nalalapat kahit patay ang tunnel. Ang mga aplikasyong may sariling DNS cache, karaniwan sa .NET at Java runtime, ay nagpapanatili ng lumang pagkabigo nang matagal matapos maayos ang chain. Ang mga Apple client ay nagko-configure ng split DNS sa pamamagitan ng match domain sa DNS settings sa halip na sa resolv.conf, at ang Chromium o Firefox sa secure-DNS mode ay maaaring lumaktaw sa resolver ng system para sa mga pampublikong pangalan. Inilalarawan ng reference ng Microsoft sa VPN name resolution ang panig Windows ng layer ng patakarang iyon.

Magpasya kung aling layer ang aayusin

Magtrabaho mula sa sintomas patungo sa layer sa halip na subukan ang mga pagwawasto nang sunud-sunod:

Dalawang row ang may pinakamabigat na dalahin. Ang timeout ay problema sa maabot: hindi sumasagot ang pribadong resolver sa pamamagitan ng tunnel, kaya suriin ang ruta patungo sa address nito at kung ang DNS server sa link ay ang inaakala mo. Ang NXDOMAIN ay problema sa awtoridad: may sumagot at hindi kilala ang pangalan, na tumuturo sa zone, rehiyon o resolver na hindi dapat tumanggap ng query.

Ang huling row ang madalas laktawan dahil mukhang tagumpay ang dalawang kalahati. Ang maikling pangalang nagre-resolve nang iba sa FQDN ay hindi pagtutugma ng suffix, at ang muling pagkonekta ng tunnel ay hindi magbabago kung anong suffix ang ipinapadala ng client.

Itala ang estado bago mag-edit ng configuration file, para masabi mo kung may nagawa ang edit:

resolvectl status > before.txt
getent ahosts service.internal.example >> before.txt

Patakbuhin ang mga pagsusuri sa ganitong pagkakasunod-sunod at huminto sa unang nabibigo. Dapat magkasundo ang getent at resolvectl query; kung nabibigo ang getent habang sumasagot ang dig, manatili sa lookup chain at huwag hawakan ang routing. Dapat ipakita ng resolvectl status ang DNS server at routing domain sa tun interface. Hindi dapat maagang bumalik ang nsswitch na may NOTFOUND para sa suffix na sinusubukan mo. Dapat awtoritatibo ang pangalan sa network kung saan nakakabit ang endpoint mo, sinubukan na may tuldok sa dulo. Hindi dapat magtago ng sariling cache o secure-DNS override ang aplikasyon.

Ayusin lang ang unang layer na nabibigo, pagkatapos ay patakbuhin muli ang parehong mga command. Ang dalawang pagbabago nang sabay ay hindi ka makapagsasabi kung alin ang mahalaga, at ang susunod na outage ay magsisimula ng imbestigasyon sa zero.