Domeniul dvs. VPN din dnsmasq nu este un transfer de zonă
Un domeniu împins este politică, nu un fișier de zonă, iar localhost din resolv.conf poate fi corect. Urmați setarea acceptată până la backend-ul care rulează de fapt.
Căutați zona corporativă în configurația dnsmasq a clientului, nu o găsiți și concluzionați că VPN-ul nu și-a împins domeniul. Ce a fost împins este un indiciu de rutare, nu o zonă. Clientul înregistrează domeniul și resolver-ul care ar trebui să răspundă pentru el, iar backend-ul administrat transformă asta în redirecționare condiționată. Căutarea în locul greșit produce un diagnostic sigur și complet fals.
Ce a acceptat clientul nu este ce a oferit gateway-ul
Un gateway poate oferi un resolver, un domeniu și ruta necesară pentru a ajunge la acel resolver, iar clientul poate accepta toate trei sau niciunul. Un profil importat, un script auxiliar sau o politică ce ignoră opțiunile împinse pot lăsa setul acceptat gol în timp ce partea de server pare corectă. Începeți de la starea înregistrată a clientului, nu de la configurația serverului, pentru că acea stare este ce primește de fapt resolver-ul. Dacă domeniul acceptat lipsește, nimic mai departe nu va mai conta. Verificați proprietățile DNS ale conexiunii înainte de a inspecta vreun cache.
Această distincție explică majoritatea rapoartelor despre un domeniu care nu a ajuns niciodată. A fost oferit și nu a fost aplicat.
Două tipuri de intrări de domeniu
O conexiune poate purta domenii de căutare obișnuite și domenii doar pentru rutare, iar al doilea tip începe cu o tildă. Un domeniu de căutare atât rutează interogările, cât și permite extinderea numelor scurte, ceea ce este comod pe o stație de lucru și surprinzător pe un server. Un domeniu doar pentru rutare spune că interogările pentru acel sufix trebuie să meargă la servere anume fără a schimba modul în care se rezolvă numele scurte. Scrierea aceluiași domeniu în ambele moduri nu este redundanță, pentru că cele două intrări fac treburi diferite.
Pentru un spațiu de nume privat, forma doar pentru rutare este de obicei cea dorită. Menține sufixul corporativ îndreptat spre resolver-ul corporativ și lasă restul în pace.
localhost în resolv.conf nu este o eroare
Când se folosește un resolver local de cache, fișierul de sistem indică adresa de loopback și nimic altceva. Acea intrare identifică ascultătorul local, nu serverele din amonte pe care managerul i le-a dat. Adresa corporativă va lipsi în mod legitim din fișier.
Înlocuirea acelei intrări cu un resolver public este corectarea greșită clasică. Restabilește rezolvarea publică a numelor și aruncă politica condiționată în aceeași modificare.
Nu confundați backend-urile
O instanță dnsmasq administrată și un resolver de sistem sunt programe diferite cu configurație diferită și vizualizări de stare diferite. O comandă de stare pentru unul nu spune nimic util despre celălalt.
Stabiliți ce backend este configurat să folosească managerul, apoi citiți configurația generată a acelui backend în locul unui fișier la nivel de distribuție care se întâmplă să existe. Managerul își scrie propria configurație de instanță și acceptă opțiuni personalizate pentru acea instanță, așa că editarea unui fișier global nelegat nu schimbă nimic și arată ca o modificare fără efect. Pornirea unui al doilea daemon pe portul 53 este mai rău decât inutil, pentru că acum două programe nu sunt de acord cine deține portul. Stabiliți mai întâi proprietarul, apoi editați acolo unde acel proprietar citește.
Testați spațiul de nume, nu doar răspunsul
Interogați un nume privat permis și un nume de control public prin calea normală a aplicației. O interogare directă către serverul corporativ dovedește că înregistrarea există; nu dovedește că clientul a ales acel server. A doua interogare este cea care testează politica.
Apoi repetați după o reconectare și după o deconectare. Asocierea ar trebui să urmeze ciclul de viață al conexiunii, iar numele private ar trebui să nu mai fie rezolvate când tunelul dispare, în loc să cadă înapoi pe un resolver public care răspunde pentru același sufix. Dacă totuși cad înapoi, ați găsit o scurgere, care este un defect diferit de o căutare defectuoasă. Notați ce backend rula, ce domenii au fost aplicate și ce a returnat fiecare interogare.