OpenVPN a trimis un server DNS, dar Linux îl ignoră

Serverul DNS trimis este în jurnal, tunelul este activ, iar numele interne încă eșuează. Nimic nu este stricat în trimiterea în sine; setarea a ajuns și s-a oprit acolo. O opțiune DNS trimisă este un mesaj către client, nu o instrucțiune către resolverul sistemului de operare, iar predarea dintre ele este locul unde se termină majoritatea acestor cazuri. Cinci verificări, în ordine, găsesc predarea care nu a avut loc.

Verificarea unu: cum începe conexiunea

Proprietarul conexiunii determină cine poate aplica setările resolverului. O comandă openvpn directă dintr-un shell nu deține nimic în afara propriului proces, în timp ce o unitate systemd, NetworkManager sau un client al furnizorului au fiecare propria modalitate de a publica DNS. Citiți lista de procese și numele unității înainte de a presupune vreuna dintre ele.

Un proces din linia de comandă nu este automat o conexiune NetworkManager, iar o conexiune NetworkManager nu este automat ceea ce a scris resolv.conf. Aceste două presupuneri explică cea mai mare parte a orelor pierdute în această investigație. Întrebați ce componentă ar publica DNS pentru interfața pe care o vedeți de fapt.

Notați proprietarul înainte de a continua. Fiecare verificare ulterioară depinde de acesta.

Verificarea doi: ce conține de fapt legătura resolverului

Pe un host cu systemd-resolved, resolvectl status listează fiecare legătură cu serverele DNS și domeniile sale. Găsiți legătura tunelului și citiți intrările, și nu presupuneți că interfața se numește tun0, pentru că numerotarea urmează ordinea creării. Dacă adresa trimisă lipsește din legătură, a eșuat predarea, nu interogarea.

Dacă adresa este prezentă, următoarea întrebare este ce domenii revendică acea legătură. O legătură fără listă de domenii răspunde doar la numele despre care este întrebată direct, iar acest lucru este rar ceea ce vrea un deployment split-DNS. Doar adresa este necesară, dar nu suficientă.

Comparați numele legăturii din ieșirea resolverului cu numele interfeței din jurnalul VPN înainte de a trage vreo concluzie. O nepotrivire acolo înseamnă de obicei că linia din jurnal a venit de la alt proces.

Verificarea trei: dacă spațiul de nume alege acea legătură

Un resolver poate deține serverul corect și totuși să nu fie consultat. Domeniul pe legătură decide ce interogări merg către ce legătură, iar fără un domeniu de rutare spațiul de nume privat revine la ce spune legătura implicită. De aceea resolvectl query poate reuși pentru numele intern în timp ce o aplicație încă eșuează. Aplicația ar putea folosi o cale de resolver complet diferită.

Verificați atribuirea domeniului, nu doar adresa serverului. Un domeniu scris ca ~corp.example este un domeniu de rutare, iar tilde schimbă modul în care este potrivit numele.

Dacă aplicația are propriul resolver, testați cu același mecanism pe care îl folosește ea, nu cu instrumentul sistemului. Un instrument de interogare care ocolește resolverul sistemului va reuși indiferent de starea legăturii.

Verificarea patru: un proprietar, nu doi

Dacă NetworkManager gestionează deja VPN-ul și starea resolverului, adăugarea unui script hook fără legătură creează scriitori concurenți. Hook-ul oferit de pachet pentru systemd-resolved este o integrare acceptată și așteaptă un ciclu de viață anume: script-security 2, o cale up, up-restart, o cale down și down-pre. Acele opțiuni fac ca înregistrarea și eliminarea să aibă loc la momentele potrivite, nu doar la prima conexiune.

Folosiți calea instalată din pachet, nu una ilustrativă copiată dintr-un ghid. Și permisiunile contează, pentru că hook-ul rulează după ce privilegiile scad.

Editarea unui script de resolver al distribuției pentru a-i schimba ținta de ieșire înregistrează o ocolire pentru un singur host. Nu este o reparație generală.

Verificarea cinci: același rezultat după reconectare

Reconectați-vă și citiți din nou legătura. O înregistrare care apare o dată și dispare la următoarea tranziție este defecțiunea pentru care există toată această listă. Testați după o suspendare, după o reconectare forțată și după repornirea serviciului resolverului. Fiecare tranziție testează o altă presupunere despre ordine.

Numai când toate cele cinci verificări trec la o reconectare puteți spune că setările trimise sunt în uz. Orice lucru anterior este o captură a unui moment norocos.