Kial via /etc/hosts-enskribo ne atingas la DNS de la VPN

Vi aldonis nomon al /etc/hosts, konektis la VPN kaj atendis, ke la rikordo aperos por ĉiuj. Tio ne okazas, kaj la surprizo kutime venas kun dua simptomo: la nomo solviĝas sur via maŝino kaj malsukcesas ĉe kolego, kio aspektas kiel rompita VPN-DNS-servo kaj fakte estas la hosts-dosiero faranta ĝuste tion, por kio ĝi estis desegnita. Hosts-dosiero estas loka agordo de nom-solvado, ne zono-ĝisdatigo, kaj nenio en normala VPN-konekto alŝutas ĝin.

Hosts estas loka anstataŭigo, ne zono-ĝisdatigo

La dosiero estas listo de mapadoj, kiujn nomservaj bibliotekoj konsultas antaŭ ol demandi DNS-servilon aŭ anstataŭe. Linio kiel 10.40.0.20 build.corp.example ŝanĝas tion, kion konkludas aplikoj sur tiu unu maŝino. Ĝi ne kreas rikordon, ĝi ne vojaĝas tra la tunelo, kaj la DNS-servilo, al kiu la tunelo montras, tute ne scias, ke ĝi ekzistas.

Tial la malsukceso estas malsimetria. Via kliento ricevas respondon el la dosiero. Alia kliento demandas la VPN-DNS-servilon, kiu redonas nenion, kaj la aplikaĵo raportas, ke la nomo ne ekzistas. Ambaŭ maŝinoj kondutas ĝuste; nur unu el ili havas anstataŭigon, kiun la alia neniam vidis.

Du komandoj, du malsamaj komponentoj

La plej rapida maniero ĉesigi la disputon estas igi la diferencon videbla en du komandoj, ambaŭ ruligitaj sur la kliento, kiu havas la hosts-enskribon:

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

La unua demandas la propran serĉvojon de la sistemo, kiu sur tipa glibc-sistemo legas lokajn dosierojn antaŭ DNS. La dua sendas DNS-demandon rekte al la servilo ĉe tiu adreso kaj tute ne konsultas lokajn dosierojn. Kiam la unua redonas vian enskribon kaj la dua redonas NXDOMAIN, vi pruvis, ke la rikordo ne ekzistas en DNS kaj ke via maŝino respondas el loka anstataŭigo.

La ordo estas agordebla, kaj indas kontroli ĝin antaŭ ol konkludi ion pri aparta distribuo. Rigardu la linion hosts: en /etc/nsswitch.conf; hosts: files dns konsultas dosierojn unue. Ne kopiu tiun ekzemplon sur funkciantan agordon nur por ŝanĝi la ordon, ĉar realaj sistemoj ofte listigas pliajn fontojn kaj kondiĉajn servajn enskribojn, kiujn la ekzemplo ne enhavas.

systemd-resolved malklarigas la teston

Sur sistemo uzanta systemd-resolved, la loka stub ankaŭ servas nomojn el la hosts-datumbazo. Demandado de 127.0.0.53 do ne estas sendependa testo de la fora servilo, kvankam ĝi aspektas kiel DNS-demando kaj kondutas same. Vi povas konfirmi, kion la solvilo scias kaj kiujn servilojn ĝi demandus, per:

resolvectl query build.corp.example
resolvectl status

La status-eligilo nomas la DNS-servilojn laŭ ligo, kaj tiel vi malkovras, ĉu la VPN-ligo entute ricevis solvilon. Tiu demando estas aparta de la hosts-enskribo kaj estas la inda demando, kiam privata nomo malsukcesas por ĉiu uzanto anstataŭ por unu.

Aplikoj povas aldoni ankoraŭ unu tavolon. Retumilo kun propra DNS-over-HTTPS-agordo, ujo kun propra solvila agordo, aŭ rulmedio, kiu kaŝmemoras serĉojn dum la tuta vivo de la procezo, povas ĉiu respondi alimaniere ol la sistemo. Testu la aplikaĵon, kiu gravas al vi, anstataŭ supozi, ke unu komando priskribas ĉiun programon sur la maŝino.

Kio fakte kunhavas nomon tra la VPN

Se privata nomo devas funkcii por ĉiuj, ĝi bezonas posedanton, kiun la solvilo de ĉiuj povas atingi. La pura respondo estas publikigi la rikordon en administrata zono kaj igi tiun zonon solvebla tra la celita VPN-DNS-vojo. Tiam la rikordo havas unu fonton de vero, revizian spuron kaj vivciklon, kaj neniu devas memori, kiu tekkomputilo portas lokan anstataŭigon.

Distribui hosts-dosierojn estas legitima alternativo, kaj ĝi estas finpunkta administrado anstataŭ noma servo. Se vi elektas ĝin, la dosieron devas deploji, versii kaj forigi tio, kio administras la floton, kaj ĝi devas esti tiel priskribita en la dezajno. “La VPN traktas ĝin” ne estas priskribo de tiu procezo.

Dinamika DNS-registrado estas tria mekanismo, kun propraj permesoj, ĝisdatiga aŭtentikigo kaj rikorda vivdaŭro. Ĝi ne sekvas el hosts-enskribo, kaj ĝi ankaŭ ne sekvas el kliento simple konektanta, krom se la servilo kaj la kliento ambaŭ estis agorditaj por fari ĝin. Rikordo, kiu aperas per si mem, estas signalo, ke iu ebligis sekurajn ĝisdatigojn kaj klienton, kiu registras sin, kaj tiu agordo apartenas al la dezajna rikordo anstataŭ al fadeno pri problemtrovo. Se neniu povas nomi, kiu posedas tiun agordon, traktu la aŭtomatan rikordon kiel nekonfirmita kaj tenu la administrata zonon kiel fonton de vero.

Solvita nomo ne estas vojo

Nom-solvado kaj atingeblo estas apartaj, kaj malnova loka mapado estas la klasika maniero konfuzi ilin. Hosts-enskribo, kiu montras al adreso, kiu translokiĝis, daŭre elektos la malnovan gastiganton longe post kiam DNS estis korektita, kaj la simptomo aspektas kiel vojiga malsukceso ĉe nomo, kiu solviĝas bone.

Do kiam la raporto estas “la nomo solviĝas sed la servo ne estas atingebla”, komparu la sisteman serĉon kun eksplicita demando al la VPN-DNS-servilo, poste kontrolu la adreson, kiun vi ricevis, kontraŭ tiu, kiun la servo fakte uzas. La systemd-resolved-referenco dokumentas la lokajn fontojn, kiujn ĝi konsultas, kaj tio estas la mapo, kiun vi bezonas por tiu komparo.

Poste korektu la anstataŭigon per ĝia posedanto. Forigi linion el via propra hosts-dosiero faras nenion por la dek du tekkomputiloj, kiuj ricevis la saman linion el deploja skripto, kaj tio estas la versio de ĉi tiu problemo, kiun homoj fakte havas.