Kodėl jūsų /etc/hosts įrašas nepasiekia VPN DNS

Pridėjote vardą į /etc/hosts, prisijungėte prie VPN ir tikėjotės, kad įrašas bus matomas visiems. Taip neatsitinka, o netikėtumas paprastai ateina su antru simptomu: vardas išsprendžiamas jūsų kompiuteryje ir nepavyksta kolegos kompiuteryje, o tai atrodo kaip sugedusi VPN DNS paslauga, nors iš tikrųjų hosts failas daro būtent tai, kam buvo skirtas. Hosts failas yra vietinė vardų sprendimo konfigūracija, o ne zonos atnaujinimas, ir niekas įprastame VPN ryšyje jo neįkelia.

Hosts yra vietinis perrašymas, o ne zonos atnaujinimas

Failas yra susiejimų sąrašas, į kurį vardų paslaugos bibliotekos kreipiasi prieš klausdamos DNS serverio arba jo vietoje. Eilutė, pavyzdžiui, 10.40.0.20 build.corp.example, pakeičia tai, ką nusprendžia programos tame viename kompiuteryje. Ji nesukuria įrašo, nekeliauja per tunelį, o DNS serveris, į kurį nukreipia tunelis, net nežino, kad ji egzistuoja.

Štai kodėl gedimas asimetriškas. Jūsų klientas gauna atsakymą iš failo. Kitas klientas klausia VPN DNS serverio, kuris nieko negrąžina, ir programa praneša, kad vardo nėra. Abi mašinos elgiasi teisingai; tik viena turi perrašymą, kurio kita niekada nematė.

Dvi komandos, du skirtingi komponentai

Greičiausias būdas nutraukti ginčą yra padaryti skirtumą matomą dviejose komandose, abi vykdomos tame kliente, kuriame yra hosts įrašas:

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

Pirmoji klausia pačios sistemos paieškos kelio, kuris įprastoje glibc sistemoje skaito vietinius failus prieš DNS. Antroji siunčia DNS užklausą tiesiogiai serveriui tuo adresu ir visiškai neskaito vietinių failų. Kai pirmoji grąžina jūsų įrašą, o antroji grąžina NXDOMAIN, įrodėte, kad įrašo DNS nėra ir kad jūsų kompiuteris atsako iš vietinio perrašymo.

Tvarka konfigūruojama, ir verta ją patikrinti prieš darant bet kokias išvadas apie konkrečią distribuciją. Pažiūrėkite į hosts: eilutę /etc/nsswitch.conf faile; hosts: files dns pirmiausia tikrina failus. Nekopijuokite to pavyzdžio ant veikiančios konfigūracijos vien tam, kad pakeistumėte tvarką, nes tikros sistemos dažnai išvardija papildomus šaltinius ir sąlyginius paslaugų įrašus, kurių pavyzdyje nėra.

systemd-resolved sulieja testą

Sistemoje su systemd-resolved vietinis stub taip pat teikia vardus iš hosts duomenų bazės. Todėl užklausa 127.0.0.53 nėra nepriklausomas nuotolinio serverio testas, nors ji atrodo kaip DNS užklausa ir taip elgiasi. Ką žino rezolveris ir kokių serverių jis klaustų, galite patvirtinti taip:

resolvectl query build.corp.example
resolvectl status

Status išvestis nurodo DNS serverius kiekvienai jungčiai, ir taip sužinosite, ar VPN jungtis apskritai gavo rezolverį. Šis klausimas atskiras nuo hosts įrašo ir būtent jį verta klausti, kai privatus vardas nepavyksta visiems naudotojams, o ne vienam.

Programos gali pridėti dar vieną sluoksnį. Naršyklė su savo DNS-over-HTTPS nustatymu, konteineris su savo rezolverio konfigūracija ar vykdymo aplinka, kuri kaupia paieškas visą proceso gyvavimo laiką, gali kiekviena atsakyti kitaip nei sistema. Išbandykite programą, kuri jums svarbi, o ne manykite, kad viena komanda apibūdina kiekvieną kompiuterio programą.

Kas iš tikrųjų dalijasi vardu per VPN

Jei privatus vardas turi veikti visiems, jam reikia savininko, kurį pasiektų visų rezolveris. Švarus atsakymas yra paskelbti įrašą valdomoje zonoje ir padaryti tą zoną išsprendžiamą numatytu VPN DNS keliu. Tada įrašas turi vieną tiesos šaltinį, audito pėdsaką ir gyvavimo ciklą, ir niekam nereikia atsiminti, kuris nešiojamasis kompiuteris turi vietinį perrašymą.

Hosts failų platinimas yra teisėta alternatyva, ir tai yra galinių taškų valdymas, o ne vardų paslauga. Jei pasirinksite jį, failą turi įdiegti, versijuoti ir pašalinti tai, kas valdo parką, ir taip tai turi būti aprašyta dizaine. „VPN tuo pasirūpina“ nėra to proceso aprašymas.

Dinaminė DNS registracija yra trečiasis mechanizmas, su savo leidimais, atnaujinimų autentifikavimu ir įrašo gyvavimo trukme. Ji neatsiranda iš hosts įrašo ir neatsiranda vien iš kliento prisijungimo, nebent serveris ir klientas abu būtų tam sukonfigūruoti. Savaime atsirandantis įrašas yra ženklas, kad kažkas įjungė saugius atnaujinimus ir klientą, kuris pats registruojasi, ir ta konfigūracija priklauso dizaino įrašui, o ne trikčių šalinimo gijai. Jei niekas negali įvardyti, kam priklauso tas nustatymas, laikykite automatinį įrašą nepatvirtintu ir laikykitės valdomos zonos kaip tiesos šaltinio.

Išspręstas vardas nėra maršrutas

Vardų sprendimas ir pasiekiamumas yra atskiri dalykai, o pasenęs vietinis susiejimas yra klasikinis būdas juos supainioti. Hosts įrašas, nurodantis į adresą, kuris persikėlė, toliau rinksis pasenusį mazgą dar ilgai po to, kai DNS bus pataisytas, o simptomas atrodo kaip maršrutizavimo gedimas varde, kuris gerai išsprendžiamas.

Taigi, kai ataskaita sako „vardas išsprendžiamas, bet paslauga nepasiekiama“, palyginkite sistemos paiešką su aiškia užklausa VPN DNS serveriui, tada patikrinkite gautą adresą su tuo, kurį paslauga iš tikrųjų naudoja. systemd-resolved nuoroda dokumentuoja vietinius šaltinius, į kuriuos jis kreipiasi, ir tai yra žemėlapis, kurio reikia tam palyginimui.

Tada pataisykite perrašymą per jo savininką. Vienos eilutės pašalinimas iš jūsų hosts failo nieko nepadaro dvylikai nešiojamųjų kompiuterių, kurie gavo tą pačią eilutę iš diegimo scenarijaus, ir tai yra šios problemos versija, kurią žmonės iš tikrųjų turi.