Permite DNS doar prin propriul resolver VPN: un parcurs pas cu pas

Urmărește o singură căutare de nume din momentul în care îl tastezi. Browserul întreabă sistemul de operare, sistemul de operare întreabă resolverul pe care îl alege politica lui, iar interogarea părăsește dispozitivul printr-o interfață oarecare cu un transport oarecare. Proiectul tău VPN spune că răspunsul ar trebui să vină de la un anumit resolver printr-o anumită cale. Diferența dintre aceste două afirmații este exact ce configurezi și apoi impui.

Pasul 1: numește resolverul și calea

Notează trei lucruri înainte de a atinge un firewall: adresa resolverului, protocolul și portul pe care le aștepți, și interfața prin care interogarea trebuie să iasă. Fără această listă, o regulă este o presupunere despre trafic, nu punerea în aplicare a unei decizii. Un VPN poate transporta datele aplicațiilor în timp ce DNS urmează o rânduială separată, iar asta nu este o eroare în sine. Este ceea ce se întâmplă când nimeni nu i-a spus altceva clientului.

Numirea explicită a căii este diferența dintre un proiect și un accident. Îți dă și ceva de testat mai târziu, pentru că fiecare observație poate fi comparată cu o așteptare scrisă. Ține lista în tichetul de schimbare, nu în capul cuiva.

Pasul 2: pune politica acolo unde trăiește cu adevărat

Alegerea resolverului aparține clientului: configurația de rețea a sistemului de operare, setările proprii ale clientului VPN sau o politică de browser administrată. Pune-o mai întâi acolo, cu mecanismul pe care platforma îl susține, pentru că un firewall nu poate obliga un client să aleagă un resolver despre care nu a auzit niciodată. Pe un client cu tunel divizat, spune explicit ce domenii merg la resolverul intern. Într-o flotă administrată, politica de browser este adesea singura pârghie pentru DoH, pentru că browserul își poate alege propriul resolver criptat independent de setarea sistemului.

Sari peste asta și mergi direct la firewall, și obții o regulă care permite resolverul corect plus un client care nu îl folosește niciodată. Regula pare corectă, iar jurnalele resolverului rămân goale, o pereche derutantă la depanare. Configurează mai întâi alegerea, apoi impune-o.

Pasul 3: impune calea îngust

Adaugă acum permisiunea de rețea pentru calea permisă: adresa resolverului, protocolul și portul, și interfața prin care trebuie să iasă. Ține regula limitată la acel resolver în loc să permiți tot DNS-ul de ieșire. Cele trei căi de mai jos sunt cele pe care le poate lua un client modern, și doar prima este acoperită de o regulă pentru portul 53.

A bloca DoH și DoT este legitim; a presupune că o regulă pentru portul 53 le-a blocat deja nu este. Un browser cu DoH rezolvă nume printr-o cale pe care regula ta nu a descris-o niciodată, iar o aplicație care își aduce propriul resolver face la fel. Scrie fiecare cale pe care intenționezi să o permiți și fiecare pe care intenționezi să o refuzi. O regulă care nu numește o cale nu a decis nimic despre ea.

Pasul 4: urmărește numele private și publice

DNS-ul divizat trimite intenționat doar spații de nume private către un resolver intern, în timp ce numele publice merg în altă parte, așa că mai mult de un resolver în proiect nu este o scurgere. Scurgerea este o interogare care ar fi trebuit să meargă la resolverul tău și ajunge în altă parte, sau o cale prevăzută inaccesibilă care face clientul să revină în tăcere. Aceste două cazuri sunt ce trebuie căutat. Urmărește un nume intern și un nume public sub politica prevăzută și notează care resolver a răspuns la fiecare.

Un site de test care raportează resolverul tău este un indiciu, nu o dovadă, pentru că vede doar interogările care au ajuns la el. Capturează interogarea pe partea clientului când trebuie să știi ce cale a luat de fapt, apoi compară cele două observații. Când nu sunt de acord, ai găsit o revenire pe care nimeni nu a documentat-o.

Dacă adresa resolverului este corectă dar inaccesibilă, problema este în rutare sau filtrare, nu în politică. Urmărește interogarea până la acea adresă și confirmă că răspunsul se întoarce pe interfața așteptată înainte de a schimba orice setare a resolverului.

Pasul 5: păstrează o cale de întoarcere

Înainte de a strânge accesul DNS la poartă, confirmă o metodă de recuperare care nu depinde de rezolvarea numelor. Un resolver stricat face fiecare instrument de reparare mai greu de atins, inclusiv pe cele cu care ai da înapoi schimbarea. Ține o consolă locală sau o cale în afara benzii deschisă până când noua politică este dovedită. Elimin-o doar după ce politica a supraviețuit unei reconectări.

După o reconectare sau o actualizare a politicii de browser, inspectează din nou starea efectivă, pentru că ambele pot schimba resolverul fără a schimba regula ta. Cerința este un destinatar cunoscut și o cale protejată pentru interogări, nu o etichetă de resolver liniștitoare într-o singură captură de ecran. Specificația RFC 8484 pentru DNS over HTTPS este referința pentru calea criptată pe care regula ta de port nu o vede.