DNS-ul VPN-ului funcționează, dar numele .local tot eșuează: cine le rezolvă?

Două mașini în același VPN, același nume de gazdă, și doar una dintre ele îl rezolvă: diferența nu este de obicei tunelul, ci care resolver a răspuns. Pe un desktop Linux acel nume poate trece prin comutatorul serviciilor de nume, prin stub-ul systemd-resolved sau printr-un resolver adus de aplicație, și fiecare aplică propria regulă aceluiași sufix. La sufix diverg regulile, pentru că .local nu este o etichetă neutră. Aflați ce cale urmează de fapt programul care eșuează înainte de a schimba ordinea în care rulează ceva.

Două resolvere, două răspunsuri diferite

O căutare tradițională glibc parcurge linia hosts: din nsswitch.conf și întreabă fiecare modul pe rând până când unul răspunde. Un client care vorbește cu systemd-resolved prin stub listener întreabă în schimb un singur proces, iar acel proces aplică politica pe legătură plus cazurile sale speciale. O aplicație care își aduce propriul resolver, sau care leagă o bibliotecă ce face asta, poate ocoli ambele. Așadar un nume de gazdă poate avea trei proprietari pe o singură mașină, și doar unul dintre ei știe ce intenționa VPN-ul.

Identificați proprietarul înainte de a schimba ceva, pentru că remedierea diferă pentru fiecare dintre cei trei. Un browser și un instrument de linie de comandă pe același desktop pot fi legitim în dezacord, iar acel dezacord este indiciul, nu eroarea. Dacă browserul rezolvă numele și instrumentul nu, depanați o cale de resolver și nu o rută VPN. Confirmați ruta separat, ca o defecțiune de rutare să nu fie confundată cu o defecțiune a serviciului de nume. Când ambele sunt de acord, defecțiunea este deasupra gazdei și configurația resolverului de aici nu merită încă o modificare.

Ce comandă a întrebat de fapt resolverul dumneavoastră

Două comenzi doar pentru citire răspund la întrebări înrudite, iar compararea lor localizează problema mai repede decât citirea configurației. Folosiți un nume intern real și păstrați ieșirea privată, pentru că înregistrările interne rămân interne. Rulați ambele în aceeași sesiune în care rulează programul care eșuează:

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

Prima întreabă prin modulele configurate, ceea ce experimentează un program tipic. A doua întreabă direct systemd-resolved și raportează legătura, protocolul și serverul care a răspuns. Interogarea serverului corporativ după adresă dovedește doar că serverul deține înregistrarea, pentru că nu spune nimic despre dacă aplicația l-a întrebat vreodată. Citiți legătura care transportă VPN-ul și domeniile pe care le revendică, apoi comparați acea listă cu sufixul din numele care eșuează.

De ce .local ocolește zona unicast

referința systemd-resolved arată că numele cu mai multe etichete care se termină în .local merg de obicei la DNS multicast când mDNS este activat, nu la DNS unicast obișnuit. RFC 6762 rezervă acel spațiu de nume pentru multicast link-local, așa că o zonă corporativă poate avea o înregistrare corectă care nu este niciodată interogată pentru acel sufix. Tunelul poate ruta resolverul perfect și tot poate pierde cursa. Un ping reușit din cache nu spune nimic despre căutarea care tocmai a avut loc.

Există o excepție documentată, și rezolvă majoritatea acestor cazuri: când o legătură declară acel sufix ca domeniu de căutare sau domeniu de rutare, daemonul îl păstrează pe calea unicast și sare peste cazul special multicast. Aceasta este politică pe legătură și nu o preferință globală. Două mașini cu același server VPN se pot comporta diferit când un profil de rețea declară domeniul, iar celălalt nu, așa că citiți profilul activ și nu pe cel pe care vă amintiți că l-ați editat.

Excepția îngustă învinge o reordonare globală

Pentru o zonă existentă pe care nu o puteți redenumi, cereți proprietarilor resolverului și VPN-ului să declare domeniul pe conexiunea care îl transportă. O intrare de domeniu de rutare pentru acel singur sufix plus adresa de server prevăzută este o schimbare mică cu un proprietar numit, și trăiește cu legătura în loc de un fișier editat manual.

Supraviețuiește și unei deconectări, pentru că politica legăturii este reaplicată când legătura revine. Editarea nsswitch.conf partajat este alternativa tentantă și mai costisitoare, pentru că schimbă comportamentul de căutare pentru fiecare nume de pe mașină, inclusiv descoperirea locală. Dezactivarea daemonului multicast nu este nici ea echivalentă: elimină comportamentul local fără a învăța vreun resolver despre zona corporativă. Dacă serviciul este nou și nu moștenit, puneți-l sub un subdomeniu controlat de organizația dumneavoastră și săriți complet peste competiție. Alegeți excepția îngustă când numele este fixat în firmware sau tipărit pe o etichetă, și alegeți un subdomeniu nou când încă controlați clientul.

Ce trebuie demonstrat după modificare

Demonstrați remedierea cu căutarea proprie a aplicației și nu cu un instrument instalat pentru testare, și goliți orice cache care ar putea răspunde în locul ei. Apoi confirmați calea resolverului și legătura care a furnizat răspunsul. În final verificați că descoperirea locală se comportă ca înainte de modificare, pentru că imprimanta care nu mai apare este partea pe care oamenii o observă ultima. Aceste trei comenzi verifică numele, calea și identitatea TLS în această ordine:

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

O adresă corectă cu certificatul greșit tot face un client strict să eșueze, așa că verificați numele pe care aplicația îl așteaptă după ce rezolvarea funcționează. Confirmați că serviciul acceptă conexiuni din adresa VPN și nu doar din intervalul biroului. Scrieți domeniul de aplicare, serverul și proprietarul în documentația conexiunii. Altfel următoarea persoană care întâlnește această defecțiune va apela la aceeași editare globală pe care tocmai ați evitat-o.