DNS i VPN-së funksionon, por emrat .local ende dështojnë: kush i zgjidh ata?

Dy makina në të njëjtën VPN, i njëjti emër hosti, dhe vetëm njëra prej tyre e zgjidh atë: ndryshimi zakonisht nuk është tuneli, por cili zgjidhës u përgjigj. Në një desktop Linux ai emër mund të kalojë përmes ndërprerësit të shërbimeve të emrave, përmes stub-it të systemd-resolved ose përmes një zgjidhësi që aplikacioni e solli me vete, dhe secili prej tyre zbaton rregullin e vet në të njëjtin sufiks. Është pikërisht në sufiks që rregullat ndahen, sepse .local nuk është etiketë neutrale. Zbuloni cilën rrugë ndjek në të vërtetë programi që dështon, përpara se të ndryshoni rendin në të cilin ekzekutohet diçka.

Dy zgjidhës, dy përgjigje të ndryshme

Një kërkim tradicional i glibc kalon nëpër rreshtin hosts: në nsswitch.conf dhe pyet çdo modul me radhë derisa njëri të përgjigjet. Një klient që flet me systemd-resolved përmes dëgjuesit stub pyet në vend të kësaj një proces të vetëm, dhe ai proces zbaton politikën për çdo lidhje plus rastet e veta të veçanta. Një aplikacion që sjell zgjidhësin e vet, ose që lidh një bibliotekë që e bën këtë, mund t'i anashkalojë të dyja. Kështu një emër hosti mund të ketë tre pronarë në një makinë, dhe vetëm njëri prej tyre e di se çfarë synonte VPN-ja.

Identifikoni pronarin përpara se të ndryshoni diçka, sepse rregullimi është i ndryshëm për secilin nga të tre. Një shfletues dhe një mjet rreshti komandash në të njëjtin desktop mund të mos pajtohen në mënyrë legjitime, dhe ai mosmarrëveshje është gjurmë, jo gabim. Nëse shfletuesi e zgjidh emrin dhe mjeti jo, po korrigjoni një rrugë zgjidhësi dhe jo një rrugë VPN. Konfirmoni rrugën veçmas, që një defekt rrugëtimi të mos ngatërrohet me një defekt të shërbimit të emrave. Kur të dyja pajtohen, defekti është mbi hostin dhe konfigurimi i zgjidhësit këtu nuk vlen për një redaktim tjetër.

Cila komandë e pyeti vërtet zgjidhësin tuaj

Dy komanda vetëm-lexim përgjigjen pyetjeve të lidhura, dhe krahasimi i tyre e lokalizon problemin më shpejt sesa leximi i konfigurimit. Përdorni një emër të vërtetë të brendshëm dhe mbajeni daljen private, sepse regjistrimet e brendshme mbeten të brendshme. Ekzekutoni të dyja në të njëjtën sesion në të cilin ekzekutohet programi që dështon:

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

E para pyet përmes moduleve të konfiguruara, që është ajo që përjeton një program tipik. E dyta pyet drejtpërdrejt systemd-resolved dhe raporton lidhjen, protokollin dhe serverin që u përgjigj. Pyetja e serverit të korporatës sipas adresës provon vetëm se serveri e mban regjistrimin, sepse nuk thotë asgjë nëse aplikacioni e pyeti ndonjëherë. Lexoni lidhjen që mban VPN-në dhe domenet që pretendon, më pas krahasoni atë listë me sufiksin në emrin që dështon.

Pse .local e anashkalon zonën tuaj unicast

referenca e systemd-resolved thotë se emrat me shumë etiketa që mbarojnë me .local zakonisht shkojnë në DNS multicast kur mDNS është i aktivizuar, në vend të DNS unicast të zakonshëm. RFC 6762 e rezervon atë hapësirë emrash për multicast link-local, kështu që një zonë korporative mund të mbajë një regjistrim të saktë për të cilin nuk pyetet kurrë për atë sufiks. Tuneli mund ta rrugëtojë zgjidhësin në mënyrë të përsosur dhe prapë të humbasë garën. Një ping i suksesshëm nga cache nuk thotë asgjë për kërkimin që sapo ndodhi.

Ekziston një përjashtim i dokumentuar, dhe ai zgjidh shumicën e këtyre rasteve: kur një lidhje e deklaron atë sufiks si domen kërkimi ose domen rrugëtimi, demoni e mban atë në rrugën unicast dhe e anashkalon rastin e veçantë të multicast. Kjo është politikë për çdo lidhje dhe jo preferencë globale. Dy makina me të njëjtin server VPN mund të sillen ndryshe kur një profil rrjeti e deklaron domenin dhe tjetri jo, prandaj lexoni profilin aktiv dhe jo atë që mendoni se e keni redaktuar.

Përjashtimi i ngushtë mund të gjithë rirenditjen globale

Për një zonë ekzistuese që nuk mund ta riemëroni, kërkoni nga pronarët e zgjidhësit dhe të VPN-së ta deklarojnë domenin në lidhjen që e mban. Një hyrje e domenit të rrugëtimit për atë sufiksin e vetëm plus adresa e serverit të synuar është një ndryshim i vogël me një pronar të emërtuar, dhe jeton me lidhjen në vend të një skedari të redaktuar me dorë.

Ajo i mbijeton edhe një shkëputjeje, sepse politika e lidhjes rizbatohet kur lidhja kthehet. Redaktimi i nsswitch.conf të përbashkët është alternativa joshëse dhe më e kushtueshme, sepse ndryshon sjelljen e kërkimit për çdo emër në makinë, përfshirë zbulimin lokal. Çaktivizimi i demonit multicast nuk është gjithashtu ekuivalent: heq sjelljen lokale pa i mësuar asnjë zgjidhësi zonën korporative. Nëse shërbimi është i ri dhe jo i trashëguar, vendoseni nën një nëndomen që kontrollohet nga organizata juaj dhe anashkalojeni garën plotësisht. Zgjidhni përjashtimin e ngushtë kur emri është i fiksuar në firmware ose i shtypur në një etiketë, dhe zgjidhni një nëndomen të ri kur ju ende kontrolloni klientin.

Çfarë duhet vërtetuar pas ndryshimit

Vërtetoni rregullimin me kërkimin e vetë aplikacionit dhe jo me një mjet që e instaloni për testim, dhe pastroni çdo cache që mund të përgjigjet në vend të tij. Më pas konfirmoni rrugën e zgjidhësit dhe lidhjen që dha përgjigjen. Së fundi kontrolloni që zbulimi lokal sillet si përpara ndryshimit, sepse printeri që ndalon së shfaquri është pjesa që njerëzit e vërejnë të fundit. Këto tre komanda kontrollojnë emrin, rrugën dhe identitetin TLS në atë rend:

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

Një adresë e saktë me certifikatë të gabuar prapë dështon një klient të rreptë, prandaj kontrolloni emrin që aplikacioni pret pasi zgjidhja të funksionojë. Konfirmoni që shërbimi pranon lidhje nga adresa e VPN-së dhe jo vetëm nga diapazoni i zyrës. Shkruani shtrirjen e domenit, serverin dhe pronarin në dokumentacionin e lidhjes. Përndryshe personi tjetër që ndeshet me këtë defekt do të kapet pas të njëjtit redaktim global që sapo shmangët.