Noms de clients OpenVPN a dnsmasq: script o entrades estàtiques?

Les adreces dels clients canvien, els noms dels serveis no. Genereu els noms dels clients a partir de la sessió VPN, fixeu els noms dels serveis en un fitxer drop-in i feu que els clients l’utilitzin.

A gairebé cada passarel·la petita d’OpenVPN apareixen dos problemes de noms. No podeu arribar a un portàtil connectat pel nom del seu certificat, i els serveis darrere del túnel no tenen cap nom. Semblen un sol problema i necessiten tractaments oposats, perquè una adreça es mou amb cada sessió i l’altra no. Decidiu quin tipus de nom afegiu abans d’editar res.

Decidiu per nom, no per passarel·la

La prova és senzilla: aquesta adreça canvia quan un client es torna a connectar? Si sí, el nom s’ha de generar a partir de la sessió VPN. Si no, pertany a una entrada estàtica que podeu llegir i 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

Barrejar-los és el fracàs habitual. Un servei fixat al fitxer generat desapareix la primera vegada que el script el reescriu, i un client escrit en una entrada estàtica apunta a qui va tenir aquella adreça per última vegada. Tots dos errors queden invisibles fins que un nom es resol a la màquina equivocada. Llavors qui depura assumeix que el DNS està trencat i no el fitxer.

El camí dinàmic: learn-address i el pool

OpenVPN coneix l’assignació, així que deixeu que us la digui. Aquestes opcions del servidor fan l’assignació duradora i 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 el vostre script sempre que s’afegeix, actualitza o suprimeix una adreça, i passa l’operació, l’adreça i el nom comú. Un script mínim afegeix una línia per client i l’elimina en suprimir:

#!/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)

En un dispositiu tun el segon argument és l’adreça de túnel del client, així que la línia és directament utilitzable. En un dispositiu tap OpenVPN hi passa en canvi l’adreça MAC del client, perquè un segment tap pot transportar protocols que no són IPv4, i llavors heu de buscar l’adreça al fitxer del pool pel nom comú abans d’escriure res.

Sigueu clars sobre què és el fitxer generat: una instantània de qui hi ha connectat ara mateix. Els noms desapareixen en desconnectar, que és exactament el que voleu per a portàtils que es mouen entre xarxes i exactament el que no voleu per a un servidor encès tota la nit.

El camí estàtic: address= i expansió de domini

Apunteu dnsmasq al fitxer generat en lloc del fitxer hosts del sistema, i doneu-li un domini perquè els noms curts s’expandeixin a noms plenament qualificats:

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

Amb domain definit, una línia com 10.8.0.6 alice respon tant per alice com per alice.corp.example. Manteniu listen-address a la passarel·la del túnel i a loopback, perquè un resolutor publicat per accident a la interfície LAN és un servei que no volíeu oferir.

Els serveis que mai no vénen del pool tenen les seves pròpies entrades. Poseu-los en un fitxer drop-in separat dins del directori de configuració de la distribució perquè una actualització de paquet no els pugui sobreescriure:

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

Lliureu el resolutor o no passarà res

Un resolutor que ningú no consulta no canvia res. El servidor l’ha d’anunciar:

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

Els clients de Windows apliquen totes dues opcions ells mateixos. La majoria de clients Linux no: necessiten una integració de resolutor compatible, com el ganxo update-resolv-conf de la distribució o la gestió de DNS de NetworkManager, o bé un domini de cerca i un servidor de noms manuals. Comproveu el resolutor real del client en lloc d’assumir que el push s’ha respectat, perquè un push ignorat sembla exactament un servidor que no respon.

Verifiqueu a tres capes

Pregunteu primer al servidor directament, després a un client i després a l’aplicació:

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

Si les consultes directes responen i l’aplicació no, la culpa és del lliurament al client i no de la zona. Si el nom es resol i la connexió encara falla, el nom és correcte i el següent a mirar és la ruta o el tallafoc.

Anoteu les dues categories al costat de la configuració: quins noms es generen, quins estan fixats i amb quin certificat ha de coincidir cadascun. La propera persona que afegeixi un servidor copiarà el primer patró que trobi.

Articles relacionats