Nomes de clientes OpenVPN en dnsmasq: script ou entradas estáticas?

Os enderezos dos clientes cambian, os nomes dos servizos non. Xera os nomes dos clientes a partir da sesión VPN, fixa os nomes dos servizos nun ficheiro drop-in e despois fai que os clientes o usen.

Dous problemas de nomes aparecen en case calquera pasarela pequena de OpenVPN. Non podes chegar a un portátil conectado polo nome do seu certificado, e os servizos detrás do túnel non teñen ningún nome. Parecen un só problema e necesitan tratamentos opostos, porque un enderezo móvese con cada sesión e o outro non. Decide que tipo de nome estás engadindo antes de editar nada.

Decide por nome, non por pasarela

A proba é sinxela: cambia este enderezo cando un cliente se reconecta? Se si, o nome debe xerarse a partir da sesión VPN. Se non, pertence a unha entrada estática que podes ler e revisar.

Name kindSource of truthWhere it lives
Connected clientThe address OpenVPN just assignedGenerated hosts file, rewritten per session
Service behind the tunnelA fixed address you choseStatic address= drop-in
Anything with a certificate nameThe certificate, not the poolEither, but the name must match the certificate

Mesturalos é o fallo habitual. Un servizo fixado no ficheiro xerado desaparece a primeira vez que o script o reescribe, e un cliente escrito nunha entrada estática apunta a quen tivo ese enderezo por última vez. Ambos os erros permanecen invisibles ata que un nome se resolve na máquina equivocada. Para entón, quen depura supón que o DNS está roto e non o ficheiro.

A ruta dinámica: learn-address e o pool

OpenVPN coñece a asignación, así que deixa que cho diga. Estas opcións do servidor fan que a asignación sexa duradeira e programable:

client-config-dir /etc/openvpn/ccd
ifconfig-pool-persist /etc/openvpn/ip-pool 60
script-security 2
learn-address /etc/openvpn/learn-address.sh

learn-address executa o teu script cada vez que se engade, actualiza ou elimina un enderezo, e pasa a operación, o enderezo e o nome común. Un script mínimo engade unha liña por cliente e elimínaa ao borrar:

#!/bin/sh
HOSTS=/etc/openvpn/hosts.lan
case "$1" in
  add|update) echo "$2 $3" >> "$HOSTS" ;;
  delete)     sed -i "/^$2 /d" "$HOSTS" ;;
esac
kill -HUP $(cat /var/run/dnsmasq.pid)

Nun dispositivo tun o segundo argumento é o enderezo de túnel do cliente, así que a liña é directamente utilizábel. Nun dispositivo tap OpenVPN pasa en cambio o enderezo MAC do cliente, porque un segmento tap pode transportar protocolos distintos de IPv4, e entón tes que buscar o enderezo no ficheiro do pool polo nome común antes de escribir nada.

Ten claro que é o ficheiro xerado: unha instantánea de quen está conectado agora mesmo. Os nomes desaparecen ao desconectar, que é exactamente o que queres para portátiles que se moven entre redes e exactamente o que non queres para un servidor acendido toda a noite.

A ruta estática: address= e expansión de dominio

Apunta dnsmasq ao ficheiro xerado en lugar do ficheiro hosts do sistema, e dálle un dominio para que os nomes curtos se expandan a nomes plenamente cualificados:

domain=corp.example
no-hosts
addn-hosts=/etc/openvpn/hosts.lan
listen-address=127.0.0.1,10.8.0.1
bind-interfaces

Con domain definido, unha liña como 10.8.0.6 alice responde tanto para alice como para alice.corp.example. Mantén listen-address na pasarela do túnel e en loopback, porque un resolutor publicado por accidente na interface LAN é un servizo que non pretendías ofrecer.

Os servizos que nunca veñen do pool teñen as súas propias entradas. Ponos nun ficheiro drop-in separado dentro do directorio de configuración da distribución para que unha actualización de paquete non poida sobrescribilos:

address=/files.corp.example/10.8.0.20
address=/db.corp.example/10.9.0.5

Entrega o resolutor ou non pasará nada

Un resolutor que ninguén consulta non cambia nada. O servidor ten que anuncialo:

push "dhcp-option DNS 10.8.0.1"
push "dhcp-option DOMAIN corp.example"

Os clientes de Windows aplican ambas as opcións por si mesmos. A maioría dos clientes de Linux non: necesitan unha integración de resolutor compatible, como o gancho update-resolv-conf da distribución ou a xestión de DNS de NetworkManager, ou ben un dominio de busca e un servidor de nomes manuais. Comproba o resolutor real do cliente en lugar de supor que se respectou o push, porque un push ignorado vese exactamente como un servidor que non responde.

Verifica en tres capas

Pregunta primeiro ao servidor directamente, despois a un cliente e despois á aplicación:

dig +short @10.8.0.1 alice.corp.example
getent hosts files.corp.example

Se as consultas directas responden e a aplicación non, a culpa é da entrega ao cliente e non da zona. Se o nome se resolve e a conexión segue fallando, o nome está ben e o seguinte que hai que mirar é a ruta ou a devasa.

Anota as dúas categorías xunto á configuración: que nomes se xeran, cales están fixados e con que certificado debe coincidir cada un. A próxima persoa que engada un servidor copiará o primeiro patrón que atope.

Artigos relacionados