DNS v VPN deluje, vendar imena .local še vedno ne uspejo: kdo jih razreši?

Dva računalnika v istem VPN, isto ime gostitelja, in le eden od njiju ga razreši: razlika običajno ni v tunelu, ampak v tem, kateri razreševalnik je odgovoril. Na namizju Linux lahko to ime potuje skozi stikalo imenskih storitev, skozi stub systemd-resolved ali skozi razreševalnik, ki ga je prinesla aplikacija, in vsak od njih uporabi svoje pravilo za isto pripono. Prav pri priponi se pravila razhajajo, ker .local ni nevtralna oznaka. Ugotovite, katero pot v resnici ubira program, ki ne uspe, preden spremenite vrstni red, v katerem se karkoli izvaja.

Dva razreševalnika, dva različna odgovora

Tradicionalno iskanje glibc gre skozi vrstico hosts: v nsswitch.conf in sprašuje vsak modul po vrsti, dokler eden ne odgovori. Odjemalec, ki se pogovarja s systemd-resolved prek stub poslušalca, namesto tega vpraša en sam proces, in ta proces uporabi politiko za vsako povezavo plus svoje posebne primere. Aplikacija, ki prinese svoj razreševalnik ali poveže knjižnico, ki to počne, lahko obide oba. Eno ime gostitelja ima lahko zato tri lastnike na enem računalniku, in le eden od njih ve, kaj je VPN nameraval.

Preden karkoli spremenite, določite lastnika, ker je popravek za vsakega od treh drugačen. Brskalnik in orodje ukazne vrstice na istem namizju se lahko legitimno ne strinjata, in to neskladje je namig, ne napaka. Če brskalnik ime razreši, orodje pa ne, odpravljate pot razreševalnika in ne pot VPN. Potrdite pot ločeno, da se napaka usmerjanja ne zamenja z napako imenske storitve. Ko se oba strinjata, je napaka nad gostiteljem in konfiguracija razreševalnika tukaj ni vredna še ene spremembe.

Kateri ukaz je v resnici vprašal vaš razreševalnik

Dva ukaza samo za branje odgovarjata na sorodna vprašanja, njuna primerjava pa locira težavo hitreje kot branje konfiguracije. Uporabite resnično interno ime in izhod obdržite zaseben, ker notranji zapisi ostanejo notranji. Zaženite oba v isti seji, v kateri teče program, ki ne uspe:

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

Prvi sprašuje prek konfiguriranih modulov, kar doživlja tipičen program. Drugi sprašuje systemd-resolved neposredno in poroča o povezavi, protokolu in strežniku, ki je odgovoril. Poizvedba pri korporativnem strežniku po naslovu dokaže le, da strežnik ima zapis, saj ne pove ničesar o tem, ali ga je aplikacija sploh kdaj vprašala. Preberite povezavo, ki nosi VPN, in domene, ki jih zahteva, nato primerjajte ta seznam s pripono v imenu, ki ne uspe.

Zakaj .local obide vaše območje unicast

referenca systemd-resolved navaja, da imena z več oznakami, ki se končajo na .local, ob omogočenem mDNS običajno gredo v multicast DNS, ne v običajni unicast DNS. RFC 6762 si pridržuje ta imenski prostor za link-local multicast, zato ima lahko korporativno območje pravilen zapis, po katerem se za to pripono nikoli ne vpraša. Tunel lahko razreševalnik usmeri brezhibno in vseeno izgubi tekmo. Uspešen ping iz predpomnilnika ne pove ničesar o iskanju, ki se je pravkar zgodilo.

Obstaja dokumentirana izjema in reši večino teh primerov: ko povezava razglasi to pripono kot iskalno domeno ali usmerjevalno domeno, jo demonski proces obdrži na poti unicast in preskoči poseben primer multicast. To je politika za vsako povezavo in ne globalna prednost. Dva računalnika z istim strežnikom VPN se lahko obnašata različno, ko en omrežni profil domeno razglasi, drugi pa ne, zato berite aktivni profil in ne tistega, za katerega se spomnite, da ste ga urejali.

Ozka izjema premaga globalno preurejanje

Za obstoječe območje, ki ga ne morete preimenovati, naj lastniki razreševalnika in VPN razglasijo domeno na povezavi, ki jo nosi. Vnos usmerjevalne domene za to eno pripono skupaj z načrtovanim naslovom strežnika je majhna sprememba z imenovanim lastnikom in živi s povezavo, ne v ročno urejeni datoteki.

Prestane tudi prekinitev, ker se politika povezave znova uporabi, ko se povezava vrne. Urejanje skupnega nsswitch.conf je vabljiva in dražja alternativa, ker spremeni vedenje iskanja za vsako ime na računalniku, vključno z lokalnim odkrivanjem. Tudi onemogočanje demonskega procesa multicast ni enakovredno: odstrani lokalno vedenje, ne da bi kateri koli razreševalnik naučilo korporativnega območja. Če je storitev nova in ne podedovana, jo postavite pod poddomeno, ki jo nadzoruje vaša organizacija, in tekmovanje popolnoma preskočite. Izberite ozko izjemo, ko je ime fiksno v strojni programski opremi ali natisnjeno na nalepki, in novo poddomeno, ko še vedno nadzorujete odjemalca.

Kaj dokazati po spremembi

Dokažite popravek z lastnim iskanjem aplikacije in ne z orodjem, ki ste ga namestili za testiranje, ter počistite vsak predpomnilnik, ki bi lahko odgovoril namesto nje. Nato potrdite pot razreševalnika in povezavo, ki je dala odgovor. Nazadnje preverite, ali se lokalno odkrivanje obnaša kot pred spremembo, ker je tiskalnik, ki se preneha pojavljati, tisti del, ki ga ljudje opazijo nazadnje. Ti trije ukazi preverjajo ime, pot in identiteto TLS v tem vrstnem redu:

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

Pravilen naslov z napačnim potrdilom še vedno pusti strogega odjemalca brez uspeha, zato preverite ime, ki ga aplikacija pričakuje, ko razreševanje deluje. Potrdite, da storitev sprejema povezave z naslova VPN in ne le iz pisarniškega obsega. Zapišite obseg domene, strežnik in lastnika v dokumentacijo povezave. Sicer se bo naslednja oseba, ki bo naletela na to napako, lotila iste globalne spremembe, ki ste se ji pravkar izognili.