OpenVPN-klantnammen yn dnsmasq: skript of statyske ynfieringen?
Klantadressen feroarje, tsjinstnammen net. Generearje klantnammen út de VPN-sesje, pin tsjinstnammen yn in drop-in-bestân en lit klanten it dan brûke.
Twa namproblemen komme op hast elke lytse OpenVPN-poarte foar. Do kinst in ferbûn laptop net berikke by de namme op syn sertifikaat, en de tsjinsten efter de tunnel hawwe hielendal gjin nammen. Se lykje ien probleem en se freegje om tsjinstelde behannelingen, want de iene adres ferskoot mei elke sesje en de oare net. Beslis hokker soarte namme do tafoegest foardat do eat bewurkest.
Beslis per namme, net per poarte
De test is ienfâldich: feroaret dit adres as in klant wer ferbynt? As ja, dan moat de namme út de VPN-sesje generearre wurde. As nee, dan heart er yn in statyske ynfiering dy’t do lêze en neisjen kinst.
| Name kind | Source of truth | Where it lives |
|---|---|---|
| Connected client | The address OpenVPN just assigned | Generated hosts file, rewritten per session |
| Service behind the tunnel | A fixed address you chose | Static address= drop-in |
| Anything with a certificate name | The certificate, not the pool | Either, but the name must match the certificate |
Se trochinoar helje is de gewoane flater. In tsjinst dy’t yn it generearre bestân fêstset is, ferdwynt de earste kear as it skript it oerskriuwt, en in klant dy’t yn in statyske ynfiering skreaun is, wiist nei wa’t dat adres it lêst hie. Beide flaters bliuwe ûnsichtber oant in namme nei de ferkearde masine oplost. Tsjin dy tiid nimt de persoan dy’t it ûntbrekt oan dat DNS stikken is en net it bestân.
It dynamyske paad: learn-address en de pool
OpenVPN wit de tawizing, lit it dy dus fertelle. Dizze serveropsjes meitsje de tawizing duorsum en skriptber:
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 fiert dyn skript út eltse kear as in adres tafoege, bywurke of fuorthelle wurdt, en jout de operaasje, it adres en de mienskiplike namme troch. In minimaal skript foeget ien rigel per klant ta en hellet dy by fuortheljen fuort:
#!/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 in tun-apparaat is it twadde argumint it tunneladres fan de klant, dus de rigel is direkt brûkber. Op in tap-apparaat jout OpenVPN ynstee it MAC-adres fan de klant troch, want in tap-segment kin ek oare protokollen as IPv4 drage, en dan moatst it adres yn it poolbestân by de mienskiplike namme sykje foardat do eat skriuwst.
Wês dúdlik oer wat it generearre bestân is: in momintopname fan wa’t no ferbûn is. Nammen ferdwine by it ferbrekken, en dat is krekt wat do wolst foar laptops dy’t tusken netwurken ferhúzje en krekt wat do net wolst foar in server dy’t de hiele nacht oan stiet.
It statyske paad: address= en domeinútwreiding
Rjochtsje dnsmasq op it generearre bestân ynstee fan it hosts-bestân fan it systeem, en jou it in domein sadat koarte nammen útwreidzje nei folslein kwalifisearre nammen:
domain=corp.example
no-hosts
addn-hosts=/etc/openvpn/hosts.lan
listen-address=127.0.0.1,10.8.0.1
bind-interfaces
Mei domain ynsteld, antwurdet in rigel lykas 10.8.0.6 alice foar sawol alice as alice.corp.example. Hâld listen-address by de tunnelpoarte en loopback, want in resolver dy’t by ûngelok op de LAN-interface publisearre wurdt is in tsjinst dy’t do net fan doel wie oan te bieden.
Tsjinsten dy’t nea út de pool komme, krije har eigen ynfieringen. Set se yn in apart drop-in-bestân ûnder de konfiguraasjemap fan de distribúsje sadat in pakketfernijing se net oerskriuwe kin:
address=/files.corp.example/10.8.0.20
address=/db.corp.example/10.9.0.5
Jou de resolver oer, oars bart der neat
In resolver dêr’t nimmen oan freget, feroaret neat. De server moat him oankundigje:
push "dhcp-option DNS 10.8.0.1"
push "dhcp-option DOMAIN corp.example"
Windows-klanten tapasse beide opsjes sels. De measte Linux-klanten dogge dat net: se hawwe in stipe resolveryntergraasje nedich, lykas de update-resolv-conf-heak fan de distribúsje of de DNS-ôfhanneling fan NetworkManager, of in hânmjittich sykdom ein en nammentsjinner. Kontrolearje de werklike resolver fan de klant ynstee fan oan te nimmen dat de push neikommen is, want in negearre push liket krekt op in server dy’t net antwurdet.
Ferifiearje op trije lagen
Freegje earst de server direkt, dan in klant, dan de applikaasje:
dig +short @10.8.0.1 alice.corp.example
getent hosts files.corp.example
As direkte fragen antwurde en de applikaasje net, dan leit de flater by de oerdracht oan de klant en net by de sône. As de namme oplost en de ferbining dochs mislearret, dan is de namme goed en is de rûte of de firewall it folgjende om nei te sjen.
Skriuw de twa kategoryen njonken de konfiguraasje: hokker nammen generearre wurde, hokker fêstset binne en mei hokker sertifikaat elk oerienkomme moat. De folgjende persoan dy’t in server tafoeget, kopiearret it patroan dat er earst fynt.