Gumagana ang DNS ng VPN, pero bigo pa rin ang mga pangalang .local: sino ang nagreresolba sa kanila?

Dalawang makina sa iisang VPN, parehong hostname, at isa lang sa kanila ang nagreresolba nito: ang pagkakaiba ay karaniwang hindi ang tunnel kundi kung aling resolver ang sumagot. Sa desktop na Linux, maaaring dumaan ang pangalang iyon sa switch ng mga serbisyo ng pangalan, sa stub ng systemd-resolved, o sa resolver na dinala ng aplikasyon, at bawat isa ay naglalapat ng sariling tuntunin sa parehong suffix. Sa suffix nagkakahiwalay ang mga tuntunin, dahil ang .local ay hindi neutral na label. Alamin kung aling landas ang talagang tinatahak ng programang nabibigo bago mo baguhin ang pagkakasunod-sunod ng anumang tumatakbo.

Dalawang resolver, dalawang magkaibang sagot

Ang tradisyonal na paghahanap ng glibc ay dumadaan sa linyang hosts: sa nsswitch.conf at nagtatanong sa bawat module nang sunud-sunod hanggang may sumagot. Ang client na kausap ang systemd-resolved sa pamamagitan ng stub listener ay nagtatanong sa isang proseso lamang, at inilalapat ng prosesong iyon ang patakaran bawat link at ang sarili nitong espesyal na kaso. Ang aplikasyong nagdadala ng sariling resolver, o nagli-link ng library na gumagawa nito, ay maaaring lumampas sa dalawa. Kaya ang isang hostname ay maaaring may tatlong may-ari sa isang makina, at isa lang sa kanila ang nakakaalam kung ano ang intensyon ng VPN.

Kilalanin ang may-ari bago baguhin ang anuman, dahil magkaiba ang lunas para sa bawat isa sa tatlo. Ang browser at tool sa command line sa parehong desktop ay maaaring lehitimong hindi magkasundo, at ang hindi pagkakasundong iyon ang bakas, hindi ang bug. Kung nireresolba ng browser ang pangalan at hindi ng tool, nagde-debug ka ng landas ng resolver at hindi ng ruta ng VPN. Kumpirmahin ang ruta nang hiwalay, upang ang sira sa pagruruta ay hindi mapagkamalang sira sa serbisyo ng pangalan. Kapag parehong sumang-ayon, ang sira ay nasa itaas ng host at ang configuration ng resolver dito ay hindi na sulit sa isa pang pagbabago.

Aling utos ang talagang nagtanong sa resolver mo

Dalawang utos na pagbasa lamang ang sumasagot sa magkaugnay na tanong, at ang paghahambing sa kanila ay naglolokalisa ng problema nang mas mabilis kaysa pagbasa ng configuration. Gumamit ng totoong panloob na pangalan at panatilihing pribado ang output, dahil panloob pa rin ang panloob na tala. Patakbuhin ang dalawa sa parehong session kung saan tumatakbo ang programang nabibigo:

getent ahosts files.corp.local
resolvectl query files.corp.local
resolvectl status

Ang una ay nagtatanong sa pamamagitan ng mga naka-configure na module, na siyang nararanasan ng karaniwang programa. Ang pangalawa ay direktang nagtatanong sa systemd-resolved at iniuulat ang link, protocol at server na sumagot. Ang pagtatanong sa corporate server sa pamamagitan ng address ay nagpapatunay lamang na hawak ng server ang tala, dahil wala itong sinasabi tungkol sa kung tinanong ito ng aplikasyon. Basahin ang link na nagdadala ng VPN at ang mga domain na inaangkin nito, pagkatapos ay ihambing ang listahang iyon sa suffix sa pangalang nabibigo.

Bakit nilalampasan ng .local ang iyong unicast zone

ang sanggunian ng systemd-resolved sinasabi na ang mga pangalang may maraming label na nagtatapos sa .local ay karaniwang pumupunta sa multicast DNS kapag naka-enable ang mDNS, sa halip na sa ordinaryong unicast DNS. Inilalaan ng RFC 6762 ang puwang ng pangalang iyon para sa link-local multicast, kaya ang isang corporate zone ay maaaring may tamang tala na hindi kailanman tinatanong para sa suffix na iyon. Maaaring maayos na iruta ng tunnel ang resolver at matalo pa rin sa karera. Ang ping na nagtagumpay mula sa cache ay wala ring sinasabi tungkol sa paghahanap na katatapos lang.

May dokumentadong eksepsiyon, at nilulutas nito ang karamihan sa mga kasong ito: kapag idineklara ng isang link ang suffix na iyon bilang search domain o routing domain, pinananatili ito ng daemon sa landas na unicast at nilalaktawan ang espesyal na kaso ng multicast. Patakaran iyon bawat link at hindi pandaigdigang kagustuhan. Dalawang makina na may parehong VPN server ay maaaring magkaibang kumilos kapag idineklara ng isang network profile ang domain at hindi ng isa, kaya basahin ang aktibong profile at hindi ang natatandaan mong na-edit mo.

Ang makitid na eksepsiyon ay nananalo sa pandaigdigang muling pag-aayos

Para sa umiiral na zone na hindi mo maaaring palitan ng pangalan, ipadeklara sa mga may-ari ng resolver at VPN ang domain sa koneksiyong nagdadala nito. Ang entry ng routing domain para sa nag-iisang suffix na iyon at ang inaasahang address ng server ay maliit na pagbabago na may pinangalanang may-ari, at nabubuhay ito kasama ng link sa halip na sa file na inedit sa kamay.

Nakaliligtas din ito sa pagkadiskonekta, dahil muling inilalapat ang patakaran ng link kapag bumalik ang link. Ang pag-edit ng pinagsamang nsswitch.conf ang nakakaakit at mas magastos na alternatibo, dahil binabago nito ang pag-uugali ng paghahanap para sa bawat pangalan sa makina, kasama ang lokal na pagtuklas. Ang pag-disable ng multicast daemon ay hindi rin katumbas: inaalis nito ang lokal na pag-uugali nang hindi nagtuturo sa anumang resolver tungkol sa corporate zone. Kung bago ang serbisyo at hindi namana, ilagay ito sa ilalim ng subdomain na kontrolado ng organisasyon mo at laktawan nang tuluyan ang kompetisyon. Piliin ang makitid na eksepsiyon kapag naka-lock ang pangalan sa firmware o nakalimbag sa label, at pumili ng bagong subdomain kapag kontrolado mo pa ang client.

Ano ang dapat patunayan pagkatapos ng pagbabago

Patunayan ang lunas sa sariling paghahanap ng aplikasyon at hindi sa tool na inilagay mo para sa pagsubok, at linisin ang anumang cache na maaaring sumagot sa halip nito. Pagkatapos ay kumpirmahin ang landas ng resolver at ang link na nagbigay ng sagot. Sa huli, tingnan kung ang lokal na pagtuklas ay kumikilos tulad ng bago ang pagbabago, dahil ang printer na tumitigil sa paglitaw ang bahaging huling napapansin ng mga tao. Sinusuri ng tatlong utos na ito ang pangalan, landas at pagkakakilanlang TLS sa ganoong pagkakasunod-sunod:

getent ahosts files.corp.local
resolvectl query files.corp.local
curl -sv --max-time 5 https://files.corp.local/ 2>&1 | head -n 20

Ang tamang address na may maling certificate ay nabibigo pa rin sa mahigpit na client, kaya tingnan ang pangalang inaasahan ng aplikasyon kapag gumana ang resolusyon. Kumpirmahin na tumatanggap ang serbisyo ng koneksiyon mula sa address ng VPN at hindi lamang mula sa saklaw ng opisina. Isulat ang saklaw ng domain, server at may-ari sa dokumentasyon ng koneksiyon. Kung hindi, ang susunod na taong makakatagpo ng kabiguang ito ay kukuha ng parehong pandaigdigang pag-edit na inilagan mo lang.