OpenVPN-kliëntname in dnsmasq: skrip of statiese inskrywings?

Twee naamprobleme kom op byna elke klein OpenVPN-poort voor. Jy kan nie 'n gekoppelde skootrekenaar bereik met die naam op sy sertifikaat nie, en die dienste agter die tonnel het glad geen name nie. Hulle lyk soos een probleem en hulle het teenoorgestelde behandelings nodig, want die een adres beweeg met elke sessie en die ander een nie. Besluit watter soort naam jy byvoeg voordat jy enigiets wysig.

Besluit per naam, nie per poort nie

Die toets is eenvoudig: verander hierdie adres wanneer 'n kliënt weer aansluit? Indien ja, moet die naam uit die VPN-sessie gegenereer word. Indien nee, hoort dit in 'n statiese inskrywing wat jy kan lees en hersien.

Om hulle te meng is die gewone fout. 'n Diens wat in die gegenereerde lêer vasgepen is, verdwyn die eerste keer wanneer die skrip dit herskryf, en 'n kliënt wat in 'n statiese inskrywing geskryf is, wys na wie ook al daardie adres laas gehad het. Beide foute bly onsigbaar totdat 'n naam na die verkeerde masjien opgelos word. Teen daardie tyd aanvaar die persoon wat dit ontfout dat DNS stukkend is eerder as die lêer.

Die dinamiese pad: learn-address en die poel

OpenVPN ken die toewysing, so laat dit jou vertel. Hierdie bedieneropsies maak die toewysing duursaam en skripbaar:

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 voer jou skrip uit wanneer 'n adres bygevoeg, opgedateer of uitgevee word, en gee die bewerking, die adres en die algemene naam deur. 'n Minimale skrip voeg een reël per kliënt by en verwyder dit by uitvee:

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

Op 'n tun-toestel is die tweede argument die kliënt se tonneladres, so die reël is direk bruikbaar. Op 'n tap-toestel gee OpenVPN eerder die kliënt se MAC-adres deur, want 'n tap-segment kan ander protokolle as IPv4 dra, en dan moet jy die adres in die poellêer volgens algemene naam opsoek voordat jy enigiets skryf.

Wees duidelik oor wat die gegenereerde lêer is: 'n momentopname van wie nou gekoppel is. Name verdwyn by ontkoppeling, wat presies is wat jy wil hê vir skootrekenaars wat tussen netwerke beweeg, en presies wat jy nie wil hê vir 'n bediener wat die hele nag aan is nie.

Die statiese pad: address= en domeinuitbreiding

Wys dnsmasq na die gegenereerde lêer in plaas van die stelsel se hosts-lêer, en gee dit 'n domein sodat kort name na volledig gekwalifiseerde name uitbrei:

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

Met domain ingestel, antwoord 'n reël soos 10.8.0.6 alice vir beide alice en alice.corp.example. Hou listen-address by die tonnelpoort en loopback, want 'n oplosser wat per ongeluk op die LAN-koppelvlak gepubliseer word, is 'n diens wat jy nie bedoel het om te bied nie.

Dienste wat nooit uit die poel kom nie, kry hul eie inskrywings. Sit hulle in 'n aparte drop-in-lêer onder die verspreiding se konfigurasiegids sodat 'n pakketopgradering hulle nie kan oorskryf nie:

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

Gee die oplosser oor, of niks gebeur nie

'n Oplosser wat niemand navra nie, verander niks. Die bediener moet dit adverteer:

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

Windows-kliënte pas beide opsies self toe. Die meeste Linux-kliënte doen dit nie: hulle het 'n ondersteunde oplosserintegrasie nodig soos die verspreiding se update-resolv-conf-haak of NetworkManager se DNS-hantering, of 'n handmatige soekdomein en naambediener. Kontroleer die kliënt se werklike oplosser eerder as om te aanvaar dat die stoot uitgevoer is, want 'n stoot wat geïgnoreer word, lyk presies soos 'n bediener wat nie antwoord nie.

Verifieer op drie vlakke

Vra eers die bediener direk, dan 'n kliënt, dan die toepassing:

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

As direkte navrae antwoord en die toepassing nie, is die fout die kliënt-oordrag eerder as die sone. As die naam oplos en die verbinding steeds misluk, is die naam reg en is die roete of vuurmuur die volgende ding om na te kyk.

Skryf die twee kategorieë neer langs die konfigurasie: watter name gegenereer word, watter vasgepen is, en met watter sertifikaat elkeen moet ooreenstem. Die volgende persoon wat 'n bediener byvoeg, sal die patroon kopieer wat hy eerste vind.