WireGuard nu împinge DNS: servirea unei zone BIND private

Strângerea de mână transportă chei și IP-uri permise, niciodată un resolver. Iată o zonă BIND 9 privată gata făcută plus politica de client pe legătură care o face să se rezolve.

Ați ridicat WireGuard, tunelul trece trafic, iar numele intern tot nu se rezolvă. Următorul pas este de obicei căutarea unei setări DNS în configurația WireGuard, ca și cum un peer ar putea împinge un resolver așa cum fac alte VPN-uri. Nu poate. Strângerea de mână transportă chei, adrese de interfață și IP-uri permise și nu are câmp pentru servere DNS sau domenii de căutare. Politica resolverului trăiește pe client, și acolo îi este locul corecției.

Tunelul și resolverul sunt contracte separate

WireGuard este mic dinadins. Mută pachete pentru adresele pe care le enumerați și autentifică peerii; tot ce este deasupra acelui strat este proiectul dumneavoastră. OpenVPN poate împinge un dhcp-option DNS pentru că canalul său de control transportă configurație, iar diferența aceea îi împiedică pe cei care trec între cele două.

Deci un tunel funcțional nu spune nimic despre rezolvarea numelor. Clientul poate avea o rută perfectă către 10.90.0.1 și totuși să trimită interogările la un resolver public, de aceea simptomul arată ca “VPN-ul a stricat DNS”, deși DNS nu a fost niciodată îndreptat spre VPN.

Serviți zona fără a deveni un resolver recursiv

Partea de server este o zonă autoritativă mică, nu un resolver general. În acest exemplu gateway-ul este 10.90.0.1, clienții sunt 10.90.0.0/24, iar aplicația care vă interesează răspunde la 10.60.0.20.

Fuzionați aceste setări în blocul options existent în loc să creați unul al doilea:

options {
    listen-on { 127.0.0.1; 10.90.0.1; };
    listen-on-v6 { none; };
    allow-query { 127.0.0.1; 10.90.0.0/24; };
    allow-transfer { none; };
    recursion no;
};

Apoi declarați zona și fișierul ei:

zone "corp.example" {
    type primary;
    file "/etc/bind/db.corp.example";
};
$TTL 300
@ IN SOA ns.corp.example. hostmaster.corp.example. ( 1 3600 600 604800 300 )
@      IN NS ns.corp.example.
ns     IN A  10.90.0.1
portal IN A  10.60.0.20

Validați înainte de reîncărcare, pentru că o eroare de sintaxă la reîncărcare doboară tot serverul pentru fiecare zonă pe care o servește:

named-checkconf
named-checkzone corp.example /etc/bind/db.corp.example

Deschideți UDP și TCP 53 doar pe interfața VPN. Publicarea unei autorități private pe interfața publică invită atât interogări, cât și enumerare, iar allow-transfer ar trebui să rămână închis dacă un secundar nu are cu adevărat nevoie.

Îndreptați clientul spre ea, pe fiecare legătură

Presupuneți că NetworkManager deține conexiunea și că resolverul este systemd-resolved. Citiți mai întâi politica existentă, mai ales orice domeniu de rutare rădăcină, pentru că o intrare ~. va depăși ce sunteți pe punctul de a adăuga.

nmcli connection modify wg-office +ipv4.dns 10.90.0.1
nmcli connection modify wg-office +ipv4.dns-search '~corp.example'

Tilda este caracterul important. Ea marchează domeniul ca doar-rută: numele de sub corp.example merg la serverul DNS al acestei legături, iar domeniul nu este adăugat ca sufix de căutare pentru nume scurte. Fără ea, tastarea portal începe să rezolve portal.corp.example, ceea ce este comod pentru dumneavoastră și surprinzător pentru toți ceilalți. Țineți tilda între ghilimele, pentru că una fără ghilimele este o expansiune shell care așteaptă să indice directorul dumneavoastră home.

Aplicați schimbarea prin managerul care deține interfața, apoi reconectați conexiunea. Nu porniți o a doua instanță wg-quick pentru aceeași interfață; doi proprietari se vor certa pe rute și unul dintre ei va câștiga în cel mai rău moment.

Verificați calea înainte de nume

Interogați numele de pe client și confirmați atât răspunsul, cât și serverul care l-a produs:

resolvectl query portal.corp.example

Dacă asta returnează 10.60.0.20, contractul DNS este îndeplinit. Dacă expiră, verificați mai întâi ruta către 10.90.0.1, apoi regula de firewall, apoi allow-query pe server. Eșecurile de rezolvare a numelor în această configurație sunt aproape întotdeauna accesibilitate sau un ACL, nu fișierul de zonă. Lucrați de la client spre exterior, pentru că serverul nu vă poate spune de ce o interogare nu a ajuns niciodată.

Amintiți-vă că aplicația are în continuare nevoie de propria rută și de propria permisiune de serviciu. Un nume rezolvat care indică o adresă inaccesibilă este altă defecțiune în aceleași haine.

Ce încă nu este automat

Aplicațiile cu logică proprie de resolver ignoră complet resolverul sistemului, și nicio cantitate de nmcli nu schimbă asta. Implementările care validează DNSSEC au nevoie de un proiect explicit de ancoră de încredere pentru zona privată; răspunsul nu este o instrucțiune generală de a dezactiva validarea. Testați cu același software client pe care îl rulează utilizatorii dumneavoastră, nu cu un instrument care folosește din întâmplare resolverul sistemului. Diferența dintre cele două este tot raportul de eroare.

Flotele pot automatiza această politică de client prin sistemul lor de provizionare, dar politica rămâne un obiect separat cu un proprietar. Referința BIND 9 acoperă controalele de ascultare și de interogare folosite mai sus, și este locul potrivit pentru a confirma comportamentul pentru versiunea instalată.

Pasul următor: adăugați incrementarea numărului de serie al zonei și comenzile de verificare în procedura dumneavoastră de schimbare, ca o editare de înregistrare să nu poată ajunge în producție neverificată.

Articole similare