DNS de OpenVPN na pasarela: dnsmasq e alcance da devasa

Execute dnsmasq no enderezo do túnel, permita DNS só desde o conxunto de clientes, propague o resolutor e despois probe consultas directas e a busca propia da aplicación.

Os clientes do túnel poden chegar á pasarela, e a pasarela pode chegar ao resolutor interno, así que DNS debería funcionar. Non funciona, porque son dous permisos distintos e un servizo DNS operativo é unha terceira cousa. O escoitador debe existir nun enderezo ao que cheguen os clientes, a devasa debe permitir consultas a ese enderezo, e hai que dicirlle ao cliente que o use. Abrir o túnel en ambos os sentidos resolve os dous primeiros por casualidade e deixa o terceiro sen facer.

O escoitador é un servizo local con dúas direccións

De entrada, un cliente envía unha consulta ao enderezo do túnel da pasarela no porto 53. De saída, o daemon reenvía esa consulta ao seu servidor ascendente configurado. As dúas metades deben funcionar, e fallan de maneiras distintas.

Un tempo de espera informado polo cliente e un tempo de espera visto na pasarela non son a mesma avaría.

Vincule o enderezo do túnel, non todos os enderezos

Unha instancia dedicada de dnsmasq para esta tarefa necesita un enderezo de escoita explícito, un modo de vinculación que tolere a aparición do túnel despois do arranque e un ascendente claro. Esta é a versión máis pequena que uso:

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

bind-dynamic vincula os enderezos individuais e admite que tun0 apareza máis tarde, o que importa nun equipo onde o servizo VPN se reinicia. Listar loopback mantén as ferramentas locais funcionando sen engadir un escoitador público. no-resolv evita que o daemon herde ascendentes da configuración do resolutor do equipo, e no-hosts evita que esta instancia publique o ficheiro hosts da pasarela. Ningunha desas opcións dá permiso a ninguén para consultar o servizo.

Comprobe se hai un escoitador existente no porto 53 antes de iniciar un segundo daemon, e use o propietario de configuración da distribución en lugar dun ficheiro perdido no directorio equivocado.

Permita a entrada de DNS, non o tránsito do túnel

As regras de devasa que fan que isto funcione son regras de entrada local limitadas á interface do túnel, o conxunto de clientes, o enderezo da pasarela e o porto 53. Dúas regras, unha por protocolo, abondan:

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, así que unha regra só para UDP deixa as respostas grandes fallando dun xeito que parece intermitente. Estas non son ufw route permisos, e non deben converterse nun permiso amplo en tun0. A orde importa tanto como o contido: unha regra anterior que descarte toda a entrada de tun0 segue gañando, e engadir un permiso baixo un descarte terminal non crea nada.

Se o DNS da pasarela agora forma parte do deseño, revise esa política anterior a propósito e anote por que.

A metade ascendente é un camiño aparte

As consultas saen da pasarela desde o seu propio enderezo cara ao resolutor ascendente, así que a ruta da pasarela e a política de saída cara a ese resolutor deben permitir o intercambio. É unha regra distinta da que deixa aos clientes chegar ao escoitador, e falla cun síntoma distinto.

Non engada saída de túnel sen restricións para que funcionen as respostas; as respostas rastrexadas non o necesitan.

Propague a opción e despois comprobe a entrega

O servidor pode anunciar o resolutor aos clientes cunha opción propagada. Iso é unha opción, non unha instrución que o sistema operativo deba obedecer:

push "dhcp-option DNS 10.90.0.1"

Un cliente de Linux en liña de ordes pode necesitar a integración do resolutor do seu xestor de conexións, e un dispositivo xestionado pode necesitar o seu perfil de xestión actualizado. Confirme o resolutor activo no cliente tras conectar en lugar de supoñer que a propagación se aplicou. Cando dous mecanismos tentan establecer DNS á vez, prodúcese unha carreira que se presenta como resolución intermitente.

A meta é un único propietario da configuración do resolutor do cliente, e a propagación adoita ser ese propietario só cando a plataforma do cliente está de acordo.

Probe o que realmente construíu

Consulte un nome privado totalmente cualificado e un nome externo permitido directamente contra o enderezo do túnel, por UDP e TCP. Despois repítao pola ruta de busca habitual da aplicación.

Se as consultas directas funcionan e a aplicación segue fallando, a avaría está na entrega e non no servidor:

  • O cliente nunca aplicou a opción propagada.
  • Outro resolutor estableceuse despois e gañou a carreira.
  • A aplicación usa a súa propia biblioteca de resolutores ou unha resposta na caché.

Remate confirmando que unha fonte fóra da ruta VPN aprobada non pode usar o escoitador en absoluto. Unha resolución correcta non autoriza o enderezo que devolveu, así que manteña esas dúas preguntas separadas.

Artigos relacionados