DNS OpenVPN pe gateway: dnsmasq și sfera firewall-ului

Rulați dnsmasq pe adresa tunelului, permiteți DNS doar din grupul de clienți, împingeți resolverul, apoi testați interogări directe și căutarea proprie a aplicației.

Clienții din tunel ajung la gateway, iar gateway-ul ajunge la resolverul intern, deci DNS ar trebui să funcționeze. Nu funcționează, pentru că sunt două permisiuni diferite, iar un serviciu DNS funcțional este al treilea lucru. Ascultătorul trebuie să existe pe o adresă pe care clienții o ating, firewall-ul trebuie să permită interogări către acea adresă, iar clientului trebuie să i se spună să o folosească. Deschiderea tunelului în ambele sensuri rezolvă primele două din întâmplare și lasă al treilea nefăcut.

Ascultătorul este un serviciu local cu două direcții

La intrare, un client trimite o interogare la adresa tunelului gateway-ului pe portul 53. La ieșire, demonul trimite interogarea către serverul amonte configurat. Ambele jumătăți trebuie să funcționeze, și ele eșuează în moduri diferite.

Un timeout raportat de client și un timeout văzut pe gateway nu sunt aceeași defecțiune.

Legați adresa tunelului, nu fiecare adresă

O instanță dnsmasq dedicată acestei sarcini are nevoie de o adresă de ascultare explicită, un mod de legare care tolerează apariția tunelului după pornire și un amonte clar. Aceasta este cea mai mică versiune pe care o folosesc:

listen-address=127.0.0.1,10.90.0.1
bind-dynamic
no-resolv
no-hosts
server=192.168.50.53

bind-dynamic leagă adresele individuale și se descurcă atunci când tun0 apare mai târziu, ceea ce contează pe un host unde serviciul VPN repornește. Listarea loopback ține uneltele locale în funcțiune fără a adăuga un ascultător public. no-resolv împiedică demonul să moștenească amonte din configurația resolverului hostului, iar no-hosts împiedică această instanță să publice fișierul hosts al gateway-ului. Niciuna dintre aceste opțiuni nu dă cuiva permisiunea de a interoga serviciul.

Verificați dacă există un ascultător deja existent pe portul 53 înainte de a porni un al doilea demon, și folosiți proprietarul configurației distribuției în locul unui fișier rătăcit în directorul greșit.

Permiteți intrarea DNS, nu tranzitul tunelului

Regulile de firewall care fac asta să funcționeze sunt reguli de intrare locală limitate la interfața tunelului, grupul de clienți, adresa gateway-ului și portul 53. Două reguli, una pe protocol, sunt suficiente:

sudo ufw allow in on tun0 proto udp from 10.90.0.0/24 to 10.90.0.1 port 53
sudo ufw allow in on tun0 proto tcp from 10.90.0.0/24 to 10.90.0.1 port 53

DNS rulează prin TCP la fel ca prin UDP, așa că o regulă doar pentru UDP lasă răspunsurile mari eșuând într-un mod care pare intermitent. Acestea nu sunt ufw route permisiuni și nu trebuie să devină o permisiune largă pe tun0. Ordinea contează la fel de mult ca conținutul: o regulă anterioară care aruncă toată intrarea din tun0 câștigă în continuare, iar adăugarea unei permisiuni sub o aruncare terminală nu creează nimic.

Dacă DNS-ul gateway-ului face acum parte din proiect, revizuiți acea politică anterioară intenționat și notați de ce.

Jumătatea amonte este o cale separată

Interogările părăsesc gateway-ul de la propria adresă spre resolverul amonte, deci ruta gateway-ului și politica de ieșire către acel resolver trebuie să permită schimbul. Este o regulă diferită de cea care lasă clienții să ajungă la ascultător, și eșuează cu un simptom diferit.

Nu adăugați ieșire de tunel nerestricționată pentru ca răspunsurile să funcționeze; răspunsurile urmărite nu au nevoie de ea.

Împingeți opțiunea, apoi verificați predarea

Serverul poate anunța resolverul către clienți printr-o opțiune împinsă. Aceasta este o opțiune, nu o instrucțiune pe care sistemul de operare trebuie să o asculte:

push "dhcp-option DNS 10.90.0.1"

Un client Linux din linia de comandă poate avea nevoie de integrarea resolverului în managerul său de conexiuni, iar un dispozitiv administrat poate avea nevoie de un profil de administrare actualizat. Confirmați resolverul activ pe client după conectare în loc să presupuneți că împingerea a fost aplicată. Când două mecanisme încearcă să seteze DNS simultan, apare o cursă care se prezintă ca rezolvare intermitentă.

Scopul este un singur proprietar al configurației resolverului clientului, iar împingerea este acel proprietar de obicei doar când platforma clientului este de acord.

Testați ceea ce ați construit de fapt

Interogați un nume privat complet calificat și un nume extern permis direct împotriva adresei tunelului, prin UDP și TCP. Apoi repetați pe calea obișnuită de căutare a aplicației.

Dacă interogările directe funcționează și aplicația tot eșuează, defecțiunea este în predare, nu pe server:

  • Clientul nu a aplicat niciodată opțiunea împinsă.
  • Un alt resolver a fost setat mai târziu și a câștigat cursa.
  • Aplicația folosește propria bibliotecă de resolver sau un răspuns din cache.

Încheiați confirmând că o sursă din afara căii VPN aprobate nu poate folosi deloc ascultătorul. O rezolvare reușită nu autorizează adresa returnată, așa că țineți aceste două întrebări separate.

Articole similare