OpenVPN împinge DNS, dar este posibil ca resolverul tău să nu-l vadă niciodată

Logul clientului arată serverul DNS împins, tunelul este conectat și un nume intern tot nu se rezolvă. Nimic nu este stricat în trimiterea în sine. Opțiunea a ajuns, iar resolverul sistemului de operare nu a folosit-o niciodată, pentru că pe majoritatea clienților Unix OpenVPN livrează valoarea și lasă aplicația platformei.

Simptomul: logul arată DNS, iar numele tot eșuează

OpenVPN dhcp-option transportă informații DNS și de domeniu, iar clientul înregistrează ce a primit. În unele implementări clientul aplică acele setări intern; în altele le exportă pentru un script de integrare sau un serviciu de rețea. Linia din log descrie doar prima jumătate a poveștii. A doua jumătate se întâmplă undeva unde clientul nu are control. Acolo locuiește de obicei defecțiunea.

De aceea un tunel conectat și un nume intern care eșuează coexistă atât de des. Valoarea este prezentă, consumatorul lipsește sau este configurat greșit, iar resolverul continuă în tăcere să folosească serverul public pe care îl folosea înainte de conexiune.

Primit nu înseamnă aplicat

Un client poate înregistra o valoare DNS împinsă în timp ce resolverul de sistem rămâne proprietatea altui serviciu. Un browser poate avea și propria politică de DNS criptat care ocolește complet resolverul de sistem, ceea ce produce situația memorabilă în care o aplicație rezolvă nume interne, iar alta nu.

Verifică integrarea acceptată a implementării în loc să presupui că fiecare client Unix rescrie același fișier. Această presupunere este motivul pentru care oamenii editează o configurație de resolver pe care nimic nu o citește.

Găsește proprietarul resolverului pe fiecare platformă

În Windows, tabelul politicii de rezolvare a numelor poate direcționa anumite sufixe către anumite servere, iar clientul VPN poate instala reguli acolo. Verifică politica, nu doar lista DNS a adaptorului. În Linux, NetworkManager sau systemd-resolved pot deține configurația, iar care dintre ele o deține determină ce păstrează o reconectare.

Citește starea efectivă cu instrumentul care răspunde cu adevărat la interogări: resolvectl query internal.example.net pe un host cu systemd-resolved, sau echivalentul platformei. Apoi compară acel răspuns cu serverul DNS pe care logul clientului susține că l-a trimis.

Evită să rulezi mai multe servicii care suprascriu setările resolverului fără coordonare. Doi proprietari produc un rezultat care pare intermitent, iar fiecare reconectare pare să îl repare sau să îl strice la întâmplare.

Scripturi și foreign_option

OpenVPN exportă opțiunile trimise către scripturi prin variabile numite foreign_option_N, iar un script le poate traduce în comenzi pentru resolver. Această aranjare este o integrare acceptată, nu un comportament automat, și trebuie instalată și invocată pe client.

Dacă te bazezi pe un script, înregistrează execuția și starea lui de ieșire. Un script care rulează dar eșuează în tăcere lasă același simptom ca niciun script, și este mai greu de observat pentru că configurația pare completă. Verifică ieșirea scriptului, nu fișierul scriptului. Un fișier care există nu este un script care a rulat.

Testează numele, nu logul

Întreabă clientul pentru un nume de gazdă doar intern după conectare, apoi întreabă un nume public, apoi verifică ce server a răspuns. Într-o configurație funcțională cele două răspunsuri vin din locuri diferite, iar ambele ar trebui să corespundă proiectului.

Dacă numele se rezolvă dar serviciul eșuează, treci la routing și accesul aplicațiilor în loc să schimbi din nou DNS. Manualul OpenVPN documentează dhcp-option și mediul de scripturi; folosește-l pentru a confirma ce se așteaptă să aplice clientul tău înainte de a edita un alt fișier de resolver.