DNS divizat prin OpenVPN: ce trebuie să facă un domeniu de rutare pe fiecare sistem de operare

Fiecare cerere DNS divizată începe cu aceeași propoziție: numele companiei merg la DNS-ul companiei, iar tot restul continuă să funcționeze. Transformarea acelei propoziții într-o configurație înseamnă să răspunzi la trei întrebări pentru fiecare sistem de operare, iar răspunsurile folosesc mecanisme diferite pe fiecare. Profilurile care funcționează pe un laptop Linux eșuează adesea pe Windows din motive care nu au nimic de-a face cu tunelul. Diferența este de obicei o setare a resolverului luată drept rută.

Numiți mai întâi politica, apoi alegeți primitiva platformei care o exprimă.

Trei setări ușor de confundat

Un sufix de căutare extinde un nume scurt: tastarea files devine files.corp.example când resolverul încearcă sufixele în ordine. Un domeniu de rutare alege ce resolver răspunde interogărilor dintr-un spațiu de nume. O rută IP doar face resolverul ales accesibil. Aceste trei trăiesc în straturi diferite, iar înlocuirea uneia cu alta produce o configurație care pare corectă și nu rezolvă nimic.

Confuzia are un cost: adăugarea unui sufix de căutare trimite fiecare nume scurt la resolverul de serviciu, inclusiv nume care aparțin altundeva. Alegerea unui domeniu de rutare păstrează interogările nelegate pe resolverul local și totuși trimite *.corp.example prin tunel.

Linux: un domeniu doar de rutare, nu un sufix de căutare

Pe systemd-resolved, un domeniu prefixat cu tilde este un domeniu doar de rutare, ceea ce înseamnă că interogările pentru acel spațiu de nume merg la resolverul legat fără a deveni și un sufix de căutare. resolvectl domain tun0 '~corp.example' stabilește asta, iar resolvectl dns tun0 10.8.0.1 numește serverul. Ambele setări aparțin interfeței, așa că dispar împreună cu ea. Tilda este partea pe care oamenii o omit, iar fără ea numele scurte încep să se rezolve prin resolverul de serviciu.

Nu instalați același domeniu și ca sufix de căutare global. Cele două setări nu sunt redundante; una rutează, iar cealaltă rescrie ce ați tastat.

Windows are nevoie de o politică a spațiului de nume, nu de un sufix

Windows păstrează politica de DNS divizat în Name Resolution Policy Table, nu în sufixul DNS al adaptorului. O regulă asociază un spațiu de nume cu servere anume: Add-DnsClientNrptRule -Namespace .corp.example -NameServers 10.8.0.1. Setarea doar a sufixului schimbă felul în care arată numele scurte; nu direcționează interogarea către alt server.

Verificați politica efectivă cu Get-DnsClientNrptPolicy după conectare, fiindcă o regulă dintr-o conexiune anterioară poate supraviețui tunelului. Eliminați regulile după nume când tunelul cade și păstrați numele afișat stabil, ca curățarea să nimerească intrarea corectă.

Un singur proprietar al resolverului pe platformă

Un manager de desktop, un script up OpenVPN și un demon de resolver local pot toate încerca să scrie aceeași configurație. Când nu sunt de acord, câștigă ultimul care scrie, iar rezultatul depinde de ordinea demontării. Alegeți o componentă care deține starea resolverului, lăsați-i pe ceilalți să raporteze în loc să scrie, și testați o reconectare: politica ar trebui să o supraviețuiască fără a dubla regulile. Testați și o deconectare, fiindcă starea rămasă este cea care face următoarea conexiune să se comporte diferit.

Aplicațiile care aduc propriul resolver criptat ignoră complet politica sistemului de operare. Aceasta este o proprietate a aplicației, nu un defect al tunelului.

Verificați rezultatul, nu textul profilului

Rezolvați un nume care trebuie să treacă prin tunel și unul care nu trebuie, pe fiecare platformă, și confirmați ce server a răspuns. resolvectl query host.corp.example și Resolve-DnsName host.corp.example raportează ambele serverul care a răspuns. Repetați după o reconectare. Apoi confirmați că resolverul tunelului este accesibil la adresa pe care o împinge profilul, fiindcă o politică corectă îndreptată spre un server inaccesibil eșuează la fel ca nicio politică.

Înregistrați comportamentul dorit în notele profilului: ce sufix rutează, ce server răspunde la el și ce se întâmplă cu tot restul. Următoarea platformă pe care o veți susține va avea nevoie de acea propoziție mai mult decât de fișierul de configurare.