Miks teie /etc/hosts kirje ei jõua VPN-i DNS-ini
VPN-iga ühendamine ei laadi /etc/hosts üles. Eraldage süsteemi otsing otsesest DNS-päringust ja avaldage seejärel privaatsed nimed hallatava tsooni kaudu.
Lisasite nime /etc/hosts-i, ühendasite VPN-iga ja eeldasite, et kirje ilmub kõigile. Nii ei juhtu ja üllatus tuleb tavaliselt teise sümptomiga: nimi laheneb teie masinas ja ebaõnnestub kolleegi masinas, mis näeb välja nagu katkine VPN-i DNS-teenus, kuid tegelikult teeb hosts-fail täpselt seda, milleks see loodi. Hosts-fail on kohalik nime lahendamise konfiguratsioon, mitte tsooni uuendus, ja miski tavapärases VPN-ühenduses ei laadi seda üles.
Hosts on kohalik alistamine, mitte tsooni uuendus
Fail on vastete loend, mida nime teenuse teegid konsulteerivad enne DNS-serveri käest küsimist või selle asemel. Rida nagu 10.40.0.20 build.corp.example muudab seda, mida rakendused sellel ühel masinal järeldavad. See ei loo kirjet, ei liigu tunnelist läbi ja DNS-server, millele tunnel osutab, ei tea sellest midagi.
Seetõttu on tõrge asümmeetriline. Teie klient saab vastuse failist. Teine klient küsib VPN-i DNS-serveri käest, mis ei tagasta midagi, ja rakendus teatab, et nime ei ole olemas. Mõlemad masinad käituvad õigesti; ainult ühel on alistamine, mida teine pole kunagi näinud.
Kaks käsku, kaks erinevat komponenti
Kiireim viis vaidluse lõpetamiseks on teha erinevus nähtavaks kahes käsus, mis mõlemad käivitatakse kliendil, kus hosts-kirje on:
getent ahosts build.corp.example
dig @10.40.0.53 build.corp.example A
Esimene küsib süsteemi enda otsingutee käest, mis tüüpilisel glibc-süsteemil loeb kohalikke faile enne DNS-i. Teine saadab DNS-päringu otse sellel aadressil asuvale serverile ega konsulteeri kohalikke faile üldse. Kui esimene tagastab teie kirje ja teine tagastab NXDOMAIN, olete tõestanud, et kirjet DNS-is ei ole ja et teie masin vastab kohalikust alistamisest.
Järjekord on konfigureeritav ja seda tasub kontrollida enne, kui teete järeldusi konkreetse distributsiooni kohta. Vaadake rida hosts: failis /etc/nsswitch.conf; hosts: files dns konsulteerib faile esimesena. Ärge kopeerige seda näidet töötava konfiguratsiooni peale ainult järjekorra muutmiseks, sest päris süsteemid loetlevad sageli täiendavaid allikaid ja tingimuslikke teenusekirjeid, mida näites ei ole.
systemd-resolved hägustab testi
Süsteemis, mis kasutab systemd-resolvedi, teenindab kohalik stub ka nimesid hosts-andmebaasist. Seetõttu ei ole 127.0.0.53 päring kaugserveri sõltumatu test, kuigi see näeb välja nagu DNS-päring ja käitub nii. Mida resolver teab ja milliseid servereid ta küsiks, saate kinnitada nii:
resolvectl query build.corp.example
resolvectl status
Status-väljund nimetab DNS-serverid lingi kohta ja nii saate teada, kas VPN-link sai üldse resolveri. See küsimus on hosts-kirjest eraldi ja just seda tasub küsida siis, kui privaatne nimi ebaõnnestub kõigil kasutajatel, mitte ühel.
Rakendused võivad lisada veel ühe kihi. Brauser oma DNS-over-HTTPS-seadistusega, konteiner oma resolveri konfiguratsiooniga või käituskeskkond, mis vahemällu salvestab otsinguid kogu protsessi eluea jooksul, võivad igaüks vastata süsteemist erinevalt. Testige rakendust, mis teile oluline on, selle asemel et eeldada, et üks käsk kirjeldab masina iga programmi.
Mis tegelikult jagab nime üle VPN-i
Kui privaatne nimi peab töötama kõigi jaoks, vajab see omanikku, kelleni kõigi resolver jõuab. Puhas vastus on avaldada kirje hallatavas tsoonis ja muuta see tsoon kavandatud VPN-i DNS-tee kaudu lahendatavaks. Siis on kirjel üks tõeallikas, auditijälg ja elutsükkel ning keegi ei pea mäletama, milline sülearvuti kannab kohalikku alistamist.
Hosts-failide levitamine on seaduslik alternatiiv ja see on lõpp-punktide haldus, mitte nime teenus. Kui valite selle, peab faili juurutama, versioonima ja eemaldama see, mis haldab laevastikku, ja nii tuleb seda ka disainis kirjeldada. „VPN tegeleb sellega“ ei ole selle protsessi kirjeldus.
Dünaamiline DNS-registreerimine on kolmas mehhanism, millel on oma load, uuenduste autentimine ja kirje eluiga. See ei tulene hosts-kirjest ja ei tulene ka kliendi lihtsast ühendumisest, kui server ja klient pole mõlemad selleks konfigureeritud. Kirje, mis ilmub iseenesest, on signaal, et keegi lubas turvalised uuendused ja klient, mis registreerib end ise, ning see konfiguratsioon kuulub disaini kirjesse, mitte tõrkeotsingu lõime. Kui keegi ei oska öelda, kellele see seade kuulub, käsitlege automaatset kirjet kinnitamata kirjena ja hoidke hallatavat tsooni tõeallikana.
Lahendatud nimi ei ole marsruut
Nimede lahendamine ja kättesaadavus on eraldi ning aegunud kohalik vastendus on klassikaline viis nende segamiseks. Hosts-kirje, mis osutab aadressile, mis on kolinud, valib aegunud hosti veel kaua pärast DNS-i parandamist, ja sümptom näeb välja nagu marsruutimistõrge nimel, mis laheneb hästi.
Nii et kui aruanne on „nimi laheneb, kuid teenus pole kättesaadav“, võrrelge süsteemi otsingut otsese päringuga VPN-i DNS-serverile ja seejärel kontrollige saadud aadressi selle vastu, mida teenus tegelikult kasutab. systemd-resolvedi viide dokumenteerib kohalikud allikad, mida see konsulteerib, ja see on kaart, mida selleks võrdlemiseks vajate.
Seejärel parandage alistamine selle omaniku kaudu. Rea eemaldamine teie enda hosts-failist ei tee midagi kaheteistkümnele sülearvutile, mis said sama rea juurutusskriptist, ja see on selle probleemi versioon, mis inimestel tegelikult on.