DNS d'OpenVPN a la passarel·la: dnsmasq i abast del tallafoc

Executeu dnsmasq a l'adreça del túnel, permeteu DNS només des del conjunt de clients, envieu el resolutor, i després proveu consultes directes i la cerca pròpia de l'aplicació.

Els clients del túnel poden arribar a la passarel·la, i la passarel·la pot arribar al resolutor intern, així que DNS hauria de funcionar. No funciona, perquè són dos permisos diferents i un servei DNS operatiu és una tercera cosa. L'oient ha d'existir en una adreça que els clients puguin assolir, el tallafoc ha de permetre consultes a aquesta adreça, i cal dir al client que l'utilitzi. Obrir el túnel en tots dos sentits resol els dos primers per casualitat i deixa el tercer per fer.

L'oient és un servei local amb dues direccions

D'entrada, un client envia una consulta a l'adreça del túnel de la passarel·la al port 53. De sortida, el dimoni reenvia aquesta consulta al seu servidor ascendent configurat. Les dues meitats han de funcionar, i fallen de maneres diferents.

Un temps d'espera informat pel client i un temps d'espera vist a la passarel·la no són la mateixa avaria.

Vinculeu l'adreça del túnel, no totes les adreces

Una instància dedicada de dnsmasq per a aquesta feina necessita una adreça d'escolta explícita, un mode de vinculació que toleri l'aparició del túnel després de l'inici i un ascendent clar. Aquesta és la versió més petita que faig servir:

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

bind-dynamic vincula les adreces individuals i suporta que tun0 aparegui més tard, cosa que importa en un amfitrió on el servei VPN es reinicia. Llistar loopback manté les eines locals funcionant sense afegir un oient públic. no-resolv evita que el dimoni hereti ascendents de la configuració del resolutor de l'amfitrió, i no-hosts evita que aquesta instància publiqui el fitxer hosts de la passarel·la. Cap d'aquestes opcions no dona a ningú permís per consultar el servei.

Comproveu si hi ha un oient existent al port 53 abans d'iniciar un segon dimoni, i feu servir el propietari de configuració de la distribució en lloc d'un fitxer extraviat al directori equivocat.

Permeteu l'entrada DNS, no el trànsit del túnel

Les regles del tallafoc que fan que això funcioni són regles d'entrada local limitades a la interfície del túnel, el conjunt de clients, l'adreça de la passarel·la i el port 53. Dues regles, una per protocol, són suficients:

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 funciona sobre TCP igual que sobre UDP, així que una regla només per a UDP deixa les respostes grans fallant d'una manera que sembla intermitent. Aquestes no són ufw route permisos, i no han de convertir-se en un permís ampli a tun0. L'ordre importa tant com el contingut: una regla anterior que descarti tota l'entrada de tun0 encara guanya, i afegir un permís sota un descart terminal no crea res.

Si el DNS de la passarel·la ara forma part del disseny, reviseu aquella política anterior a propòsit i anoteu per què.

La meitat ascendent és un camí a part

Les consultes surten de la passarel·la des de la seva pròpia adreça cap al resolutor ascendent, així que la ruta de la passarel·la i la política de sortida cap a aquest resolutor han de permetre l'intercanvi. Aquesta és una regla diferent de la que deixa als clients arribar a l'oient, i falla amb un símptoma diferent.

No afegiu sortida de túnel sense restriccions perquè les respostes funcionin; les respostes rastrejades no ho necessiten.

Envieu l'opció i després comproveu el lliurament

El servidor pot anunciar el resolutor als clients amb una opció enviada. Això és una opció, no una instrucció que el sistema operatiu hagi d'obeir:

push "dhcp-option DNS 10.90.0.1"

Un client de Linux per línia d'ordres pot necessitar la integració del resolutor del seu gestor de connexions, i un dispositiu gestionat pot necessitar el perfil de gestió actualitzat. Confirmeu el resolutor actiu al client després de connectar en lloc de suposar que l'enviament s'ha aplicat. Quan dos mecanismes intenten establir DNS alhora, obteniu una cursa que es presenta com una resolució intermitent.

L'objectiu és un sol propietari de la configuració del resolutor del client, i l'enviament sol ser aquest propietari només quan la plataforma del client hi està d'acord.

Proveu el que heu construït realment

Consulteu un nom privat totalment qualificat i un nom extern permès directament contra l'adreça del túnel, per UDP i TCP. Després repetiu-ho pel camí de cerca habitual de l'aplicació.

Si les consultes directes funcionen i l'aplicació encara falla, l'avaria és en el lliurament, no al servidor:

  • El client mai no va aplicar l'opció enviada.
  • Un altre resolutor es va establir més tard i va guanyar la cursa.
  • L'aplicació fa servir la seva pròpia biblioteca de resolutors o una resposta en memòria cau.

Acabeu confirmant que una font fora del camí VPN aprovat no pot fer servir l'oient de cap manera. Una resolució correcta no autoritza l'adreça que ha retornat, així que manteniu aquestes dues preguntes separades.

Articles relacionats