Pse zëri juaj në /etc/hosts nuk arrin te DNS i VPN-së

Keni shtuar një emër në /etc/hosts, jeni lidhur me VPN-në dhe prisnit që regjistrimi të shfaqej për të gjithë. Kjo nuk ndodh, dhe surpriza zakonisht vjen me një simptomë të dytë: emri zgjidhet në makinën tuaj dhe dështon te një koleg, gjë që duket si një shërbim DNS i VPN-së i prishur dhe në fakt është skedari hosts duke bërë pikërisht atë për të cilin është projektuar. Një skedar hosts është konfigurim lokal i zgjidhjes së emrave, jo një përditësim zone, dhe asgjë në një lidhje normale VPN nuk e ngarkon atë.

Hosts është një anashkalim lokal, jo një përditësim zone

Skedari është një listë përputhjesh që bibliotekat e shërbimit të emrave konsultojnë para, ose në vend të, pyetjes së një serveri DNS. Një rresht si 10.40.0.20 build.corp.example ndryshon atë që konkludojnë aplikacionet në atë makinë të vetme. Nuk krijon një regjistrim, nuk udhëton përmes tunelit, dhe serveri DNS drejt të cilit tregon tuneli nuk e ka idenë se ekziston.

Prandaj dështimi është asimetrik. Klienti juaj merr një përgjigje nga skedari. Një klient tjetër pyet serverin DNS të VPN-së, i cili nuk kthen asgjë, dhe aplikacioni raporton se emri nuk ekziston. Të dyja makinat sillen saktë; vetëm njëra ka një anashkalim që tjetra nuk e ka parë kurrë.

Dy komanda, dy komponentë të ndryshëm

Mënyra më e shpejtë për të ndaluar debatin është ta bësh ndryshimin të dukshëm në dy komanda, të dyja të ekzekutuara në klientin që ka zërin hosts:

getent ahosts build.corp.example
dig @10.40.0.53 build.corp.example A

E para pyet vetë rrugën e kërkimit të sistemit, e cila në një sistem tipik glibc lexon skedarë lokalë para DNS. E dyta dërgon një pyetje DNS drejtpërdrejt te serveri në atë adresë dhe nuk konsulton aspak skedarë lokalë. Kur e para kthen zërin tuaj dhe e dyta kthen NXDOMAIN, ju keni provuar se regjistrimi nuk ekziston në DNS dhe se makina juaj përgjigjet nga një anashkalim lokal.

Rendi është i konfigurueshëm, dhe ia vlen ta kontrolloni përpara se të nxirrni ndonjë përfundim për një shpërndarje të caktuar. Shikoni rreshtin hosts: në /etc/nsswitch.conf; hosts: files dns konsulton skedarët së pari. Mos e kopjoni atë shembull mbi një konfigurim që funksionon vetëm për të ndryshuar rendin, sepse sistemet reale shpesh rendisin burime shtesë dhe zëra shërbimi të kushtëzuar që shembulli nuk i përmban.

systemd-resolved e turbullon testin

Në një sistem që përdor systemd-resolved, stub-i lokal shërben gjithashtu emra nga baza e të dhënave hosts. Prandaj pyetja e 127.0.0.53 nuk është një test i pavarur i serverit të largët, edhe pse duket si një pyetje DNS dhe sillet si e tillë. Mund të konfirmoni çfarë di zgjidhësi dhe cilët serverë do të pyeste me:

resolvectl query build.corp.example
resolvectl status

Dalja e status emërton serverët DNS për çdo lidhje, dhe kështu zbuloni nëse lidhja VPN mori fare një zgjidhës. Ajo pyetje është e ndarë nga zëri hosts dhe është ajo që ia vlen të bëhet kur një emër privat dështon për çdo përdorues dhe jo për një.

Aplikacionet mund të shtojnë edhe një shtresë tjetër. Një shfletues me cilësimin e vet DNS-over-HTTPS, një kontejner me konfigurimin e vet të zgjidhësit ose një mjedis ekzekutimi që ruan kërkimet për gjithë jetën e procesit mund të përgjigjen secili ndryshe nga sistemi. Testoni aplikacionin që ju intereson në vend që të supozoni se një komandë përshkruan çdo program në makinë.

Çfarë ndan në të vërtetë një emër përmes VPN-së

Nëse një emër privat duhet të funksionojë për të gjithë, i duhet një pronar që zgjidhësi i të gjithëve mund ta arrijë. Përgjigja e pastër është të publikoni regjistrimin në një zonë të menaxhuar dhe ta bëni atë zonë të zgjidhshme përmes rrugës së synuar DNS të VPN-së. Atëherë regjistrimi ka një burim të vetëm të së vërtetës, një gjurmë auditimi dhe një cikël jete, dhe askush nuk duhet të mbajë mend cili laptop mban një anashkalim lokal.

Shpërndarja e skedarëve hosts është një alternativë legjitime, dhe është menaxhim pikash fundore dhe jo shërbim emrash. Nëse e zgjidhni, skedari duhet të vendoset, të versionohet dhe të hiqet nga ajo që menaxhon flotën, dhe ashtu duhet të përshkruhet në dizajn. „VPN-ja kujdeset për të“ nuk është përshkrim i atij procesi.

Regjistrimi dinamik DNS është mekanizmi i tretë, me lejet e veta, vërtetimin e përditësimeve dhe jetëgjatësinë e regjistrimit. Nuk rrjedh nga një zë hosts, dhe nuk rrjedh as nga një klient që thjesht lidhet, përveç nëse serveri dhe klienti janë konfiguruar të dy për këtë. Një regjistrim që shfaqet vetë është sinjal se dikush ka aktivizuar përditësime të sigurta dhe një klient që regjistron veten, dhe ai konfigurim i takon regjistrit të dizajnit dhe jo një filli zgjidhjeje problemesh. Nëse askush nuk mund të thotë kush e zotëron atë cilësim, trajtojeni regjistrimin automatik si të paverifikuar dhe mbani zonën e menaxhuar si burim të së vërtetës.

Një emër i zgjidhur nuk është rrugë

Zgjidhja e emrave dhe arritshmëria janë gjëra të ndara, dhe një përputhje lokale e vjetruar është mënyra klasike për t'i ngatërruar. Një zë hosts që tregon një adresë që është zhvendosur do të vazhdojë të zgjedhë hostin e vjetruar shumë kohë pasi DNS të jetë korrigjuar, dhe simptoma duket si një dështim rrugëtimi në një emër që zgjidhet mirë.

Prandaj kur raporti është „emri zgjidhet, por shërbimi nuk arrihet“, krahasoni kërkimin e sistemit me një pyetje të qartë drejtuar serverit DNS të VPN-së, pastaj kontrolloni adresën që morët kundrejt asaj që shërbimi përdor në të vërtetë. Referenca e systemd-resolved dokumenton burimet lokale që konsulton, dhe ajo është harta që ju nevojitet për atë krahasim.

Pastaj rregulloni anashkalimin përmes pronarit të tij. Heqja e një rreshti nga skedari juaj hosts nuk bën asgjë për dymbëdhjetë laptopët që morën të njëjtin rresht nga një skript vendosjeje, dhe kjo është versioni i këtij problemi që njerëzit kanë në të vërtetë.