VPN-DNS wurket, mar .local-nammen mislearje noch: wa lost se op?

Twa masines op deselde VPN, deselde hostnamme, en mar ien fan harren lost it op: it ferskil is meastentiids net de tunnel mar hokker resolver antwurde. Op in Linux-buroblêd kin dy namme troch de nametsjinstskakel, troch de stub fan systemd-resolved of troch in resolver dy’t de applikaasje meibrocht gean, en elk fan dy past syn eigen regel ta op deselde efterheaksel. It efterheaksel is wêr’t de regels útinoar geane, want .local is gjin neutrale label. Fêststelje hokker paad it mislearjende programma echt nimt foardat jo de oarder feroarje wêryn’t eat rint.

Twa resolvers, twa ferskillende antwurden

In tradisjonele glibc-syktocht giet troch de hosts:-rigel fan nsswitch.conf en freget elk module op syn beurt oant ien antwurdet. In kliïnt dy’t troch de stub-listener mei systemd-resolved praat, freget ynstee ien proses, en dat proses past belied per keppeling ta plus syn eigen spesjale gefallen. In applikaasje dy’t syn eigen resolver meibringt, of in biblioteek keppelt dy’t dat docht, kin beide omgean. Ien hostnamme kin sadwaande trije eigners op ien masine hawwe, en mar ien fan harren wit wat de VPN bedoelde.

Identifisearje de eigner foardat jo eat feroarje, want de oplossing ferskilt foar elk fan de trije. In browser en in kommando-rigel-ark op deselde buroblêd kinne mei rjocht fan miening ferskille, en dat ferskil is it oanwizing, net de flater. As de browser de namme oplost en it ark net, debugge jo in resolverpaad en gjin VPN-rûte. Befêstigje de rûte apart, sadat in routingflater net foar in nametsjinstflater oansjoen wurdt. As beide it iens binne, leit de flater boppe de host en is de resolverkonfiguraasje hjir gjin oare bewurking wurdich.

Hokker kommando frege eins jo resolver

Twa allinne-lêzen kommando’s beantwurdzje besibbe fragen, en se fergelykje lokaliseart it probleem flugger as konfiguraasje lêze. Brûk in echte ynterne namme en hâld de útfier privee, want ynterne records bliuwe yntern. Rin beide yn deselde sesje wêryn’t it mislearjende programma rint:

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

De earste freget fia de konfigurearre modules, wat in typysk programma ûnderfynt. De twadde freget direkt systemd-resolved en rapportearret de keppeling, it protokol en de tsjinner dy’t antwurde. It opfreegjen fan de bedriuwstsjerinner op adres bewiist allinnich dat de tsjinner it record hat, want it seit neat oer de fraach oft de applikaasje him ea frege hat. Lês de keppeling dy’t de VPN draacht en de domeinen dy’t er oanspraak makket, en fergelykje dy list dan mei it efterheaksel yn ’e mislearjende namme.

Wêrom .local jo unicast-sône oerslacht

de referinsje fan systemd-resolved fermeldt dat nammen mei meardere labels dy’t einigje op .local normaal nei multicast-DNS geane as mDNS oan stiet, ynstee fan nei gewoane unicast-DNS. RFC 6762 hâldt dy nammeromte frij foar link-local multicast, sadat in bedriuwsône in korrekt record hâlde kin dêr’t nea foar dat efterheaksel frege wurdt. De tunnel kin de resolver perfekt route en dochs de wedstriid ferlieze. In ping dy’t slagget út in cache seit neat oer de syktocht dy’t krekt bart is.

Der is in dokumintearre útsûndering, en dy beslist de measte fan dizze gefallen: as in keppeling dat efterheaksel as sykdomein of routingdomein ferklearret, hâldt de daemon it op it unicast-paad en slacht it spesjale multicast-gefal oer. Dat is belied per keppeling en gjin globale foarkar. Twa masines mei deselde VPN-tsjinner kinne har oars gedrage as ien netwurkprofyl it domein ferklearret en it oare net, dus lês it aktive profyl en net dat jo jo bewurkje te hawwen.

De smelle útsûndering ferslaat in globale weromoardering

Foar in besteande sône dy’t jo net omneame kinne, lit de resolver- en VPN-eigners it domein ferklearje op ’e ferbining dy’t it draacht. In routingdomein-ynskriuwing foar dat iene efterheaksel plus it bedoelde tsjinneradres is in lytse feroaring mei in neamde eigner, en it wennet by de keppeling ynstee fan yn in mei de hân bewurke bestân.

It oerlibbet ek in ferbining ferbrekke, want it keppelingsbelied wurdt opnij tapast as de keppeling weromkomt. It bewurkjen fan ’e dielde nsswitch.conf is it ferlokjende en it djoerdere alternatyf, want it feroaret sykgedrach foar elke namme op ’e masine, ek lokale ûntdekking. It útskeakeljen fan ’e multicast-daemon is ek net gelykweardich: it hellet it lokale gedrach fuort sûnder ienige resolver oer de bedriuwsône te learen. As de tsjinst nij is ynstee fan erfd, set it ûnder in subdomein dat jo organisaasje kontrolearret en slach de kompetysje hielendal oer. Kies de smelle útsûndering as de namme yn firmware fêstlein is of op in label printe, en kies in nij subdomein as jo de kliïnt noch kontrolearje.

Wat nei de feroaring te bewizen

Bewiis de oplossing mei de eigen syktocht fan ’e applikaasje ynstee fan in ark dat jo ynstallearren om mei te testen, en leegje elke cache dy’t dêrfoar antwurdzje kin. Befêstigje dan it resolverpaad en de keppeling dy’t it antwurd tsjinne. Kontrolearje úteinlik dat lokale ûntdekking har noch hâldt sa’t it foar de feroaring die, want de printer dy’t ferdwynt is it part dat minsken it lêst merke. Dizze trije kommando’s kontrolearje de namme, it paad en de TLS-identiteit yn dy oarder:

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

In korrekt adres mei it ferkearde sertifikaat lit in strang kliïnt noch altyd mislearje, dus kontrolearje de namme dy’t de applikaasje ferwachtet as de oplossing wurket. Befêstigje dat de tsjinst ferbiningen fan it VPN-adres akseptearret en net allinnich fan it kantoarberik. Skriuw it domeinberik, de tsjinner en de eigner yn ’e dokumintaasje fan ’e ferbining. Oars grypt de folgjende persoan dy’t dizze flater treft nei deselde globale bewurking dy’t jo krekt mijden.