OpenVPN-klientnomoj en dnsmasq: skripto aŭ statikaj rikordoj?

Klientaj adresoj ŝanĝiĝas, servonomoj ne. Generu klientnomojn el la VPN-sesio, fiksu servonomojn en drop-in dosiero, poste igi klientojn uzi ĝin.

Du nomaj problemoj aperas sur preskaŭ ĉiu malgranda OpenVPN-pordego. Vi ne povas atingi konektitan tekkomputilon per la nomo sur ĝia atestilo, kaj la servoj malantaŭ la tunelo tute ne havas nomojn. Ili aspektas kiel unu problemo kaj bezonas kontraŭajn traktadojn, ĉar unu adreso moviĝas kun ĉiu sesio kaj la alia ne. Decidu, kian nomon vi aldonas, antaŭ ol vi redaktas ion ajn.

Decidu laŭ nomo, ne laŭ pordego

La testo estas simpla: ĉu tiu adreso ŝanĝiĝas, kiam kliento rekonektiĝas? Se jes, la nomo devas esti generita el la VPN-sesio. Se ne, ĝi apartenas al statika rikordo, kiun vi povas legi kaj revizii.

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

Miksi ilin estas la kutima malsukceso. Servo fiksita en la generitan dosieron malaperas la unuan fojon, kiam la skripto reskribas ĝin, kaj kliento skribita en statikan rikordon montras al tiu, kiu laste tenis tiun adreson. Ambaŭ eraroj restas nevideblaj ĝis nomo solviĝas al la malĝusta maŝino. Ĝis tiam la persono, kiu sencimigas, supozas, ke DNS estas rompita, ne la dosiero.

La dinamika vojo: learn-address kaj la naĝejo

OpenVPN scias la atribuon, do lasu ĝin diri al vi. Ĉi tiuj servilaj opcioj faras la atribuon daŭra kaj skriptebla:

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 rulas vian skripton ĉiam, kiam adreso aldoniĝas, ĝisdatiĝas aŭ foriĝas, kaj transdonas la operacion, la adreson kaj la komunan nomon. Minimuma skripto aldonas unu linion por kliento kaj forigas ĝin ĉe forigo:

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

Sur tun-aparato la dua argumento estas la tunela adreso de la kliento, do la linio estas rekte uzebla. Sur tap-aparato OpenVPN transdonas anstataŭe la MAC-adreson de la kliento, ĉar tap-segmento povas porti ankaŭ aliajn protokolojn ol IPv4, kaj tiam vi devas serĉi la adreson en la naĝeja dosiero laŭ la komuna nomo antaŭ ol skribi ion ajn.

Estu klara pri tio, kio estas la generita dosiero: momenta bildo de tio, kiu estas konektita nun. Nomoj malaperas ĉe malkonekto, kio estas ĝuste tio, kion vi volas por tekkomputiloj, kiuj moviĝas inter retoj, kaj ĝuste tio, kion vi ne volas por servilo, kiu restas ŝaltita dum la tuta nokto.

La statika vojo: address= kaj domajna etendo

Direktu dnsmasq al la generita dosiero anstataŭ al la sistema hosts-dosiero, kaj donu al ĝi domajnon, por ke mallongaj nomoj etendiĝu al plene kvalifikitaj:

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

Kun domain agordita, linio kiel 10.8.0.6 alice respondas kaj por alice kaj por alice.corp.example. Tenadu listen-address nur ĉe la tunela pordego kaj loopback, ĉar solvilo hazarde publikigita sur la LAN-interfaco estas servo, kiun vi ne intencis proponi.

Servoj, kiuj neniam venas el la naĝejo, ricevas proprajn rikordojn. Metu ilin en apartan drop-in dosieron en la agorda dosierujo de la distribuo, por ke pakaĝa ĝisdatigo ne povu superskribi ilin:

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

Transdonu la solvilon, alie nenio okazos

Solvilo, kiun neniu demandas, ŝanĝas nenion. La servilo devas anonci ĝin:

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

Windows-klientoj mem aplikas ambaŭ opciojn. Plej multaj Linux-klientoj ne: ili bezonas subtenatan solvilan integriĝon kiel la update-resolv-conf hokon de la distribuo aŭ la DNS-traktadon de NetworkManager, aŭ permane agorditan serĉdomajnon kaj nomservilon. Kontrolu la faktan solvilon de la kliento anstataŭ supozi, ke la push estis observita, ĉar ignorita push aspektas same kiel servilo, kiu ne respondas.

Kontrolu ĉe tri tavoloj

Demandu unue la servilon rekte, poste klienton, poste la aplikaĵon:

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

Se rektaj demandoj respondas kaj la aplikaĵo ne, la kulpo estas en la transdono al la kliento, ne en la zono. Se la nomo solviĝas kaj la konekto ankoraŭ malsukcesas, la nomo estas bona kaj la sekva afero rigardenda estas la itinero aŭ la fajroŝirmilo.

Skribu la du kategoriojn apud la agordo: kiuj nomoj estas generitaj, kiuj estas fiksitaj kaj kun kiu atestilo ĉiu devas kongrui. La sekva persono, kiu aldonos servilon, kopios tiun ŝablonon, kiun ĝi unue trovos.

Rilataj artikoloj