OpenVPN-klientnamn i dnsmasq: skript eller statiske oppføringar?
Klientadresser endrar seg, tenestenamn gjer det ikkje. Generer klientnamn frå VPN-økta, fest tenestenamn i ei drop-in-fil og få deretter klientane til å bruke ho.
To namneproblem dukkar opp på nesten kvar liten OpenVPN-gateway. Du når ikkje ein tilkopla berbar PC via namnet på sertifikatet, og tenestene bak tunnelen har ingen namn i det heile. Dei ser ut som eitt problem og krev motsett handsaming, fordi den eine adressa flyttar seg med kvar økt og den andre ikkje. Bestem kva type namn du legg til før du redigerer noko.
Bestem per namn, ikkje per gateway
Testen er enkel: endrar denne adressa seg når ein klient koplar til på nytt? Viss ja, må namnet genererast frå VPN-økta. Viss nei, høyrer det heime i ein statisk oppføring du kan lese og gå gjennom.
| 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 |
Å blande dei er den vanlege feilen. Ei teneste som er fest i den genererte fila, forsvinn første gong skriptet skriv ho på nytt, og ein klient som er skriven inn i ein statisk oppføring, peikar på den som hadde adressa sist. Begge feila blir usynlege til eit namn blir løyst opp til feil maskin. Då trur den som feilsøkjer at DNS er øydelagd og ikkje fila.
Den dynamiske vegen: learn-address og bassenget
OpenVPN kjenner tildelinga, så lat han fortelje deg ho. Desse servervala gjer tildelinga varig og skriptbar:
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 køyrer skriptet ditt kvar gong ei adresse blir lagd til, oppdatert eller sletta, og sender operasjonen, adressa og det felles namnet vidare. Eit minimalt skript legg til éi linje per klient og fjernar ho ved sletting:
#!/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)
På ein tun-eining er det andre argumentet tunneladressa til klienten, så linja kan brukast direkte. På ei tap-eining sender OpenVPN i staden MAC-adressa til klienten, fordi eit tap-segment kan bera andre protokollar enn IPv4, og då må du slå opp adressa i bassengfila etter det felles namnet før du skriv noko.
Ver klar over kva den genererte fila er: eit augeblinksbilete av kven som er tilkopla akkurat no. Namn forsvinn ved fråkobling, som er nettopp det du vil ha for berbare PC-ar som flyttar seg mellom nettverk, og nettopp det du ikkje vil ha for ein server som står på heile natta.
Den statiske vegen: address= og domeneekspansjon
Peik dnsmasq mot den genererte fila i staden for hosts-fila til systemet, og gi ho eit domene slik at korte namn blir utvida til fullt kvalifiserte:
domain=corp.example
no-hosts
addn-hosts=/etc/openvpn/hosts.lan
listen-address=127.0.0.1,10.8.0.1
bind-interfaces
Når domain er sett, svarar ei linje som 10.8.0.6 alice både for alice og alice.corp.example. Hald listen-address til tunnelgatewayen og loopback, fordi ein resolver som ved eit uhell blir publisert på LAN-grensesnittet, er ei teneste du ikkje hadde til hensikt å tilby.
Tenester som aldri kjem frå bassenget, får eigne oppføringar. Legg dei i ei eiga drop-in-fil under konfigurasjonskatalogen til distribusjonen, slik at ein pakkeoppgradering ikkje kan skrive over dei:
address=/files.corp.example/10.8.0.20
address=/db.corp.example/10.9.0.5
Lever resolveren vidare, elles skjer ingenting
Ein resolver som ingen spør, endrar ingenting. Serveren må annonsere han:
push "dhcp-option DNS 10.8.0.1"
push "dhcp-option DOMAIN corp.example"
Windows-klientar brukar begge vala sjølve. Dei fleste Linux-klientar gjer det ikkje: dei treng ein støtta resolverintegrasjon som update-resolv-conf-kroken til distribusjonen eller DNS-handsaminga til NetworkManager, eller eit manuelt søkjedomene og namneserver. Kontroller den faktiske resolveren til klienten i staden for å gå ut frå at push-en vart følgd, fordi ein ignorert push ser nøyaktig ut som ein server som ikkje svarar.
Stadfest på tre lag
Spør serveren direkte først, deretter ein klient, deretter applikasjonen:
dig +short @10.8.0.1 alice.corp.example
getent hosts files.corp.example
Viss direkte spørjingar svarar og applikasjonen ikkje, ligg feilen i overleveringa til klienten og ikkje i sona. Viss namnet blir løyst opp og tilkoplinga framleis feilar, er namnet i orden, og det neste du bør sjå på er ruta eller brannmuren.
Skriv ned dei to kategoriane ved sida av konfigurasjonen: kva namn som blir genererte, kva som er feste, og kva sertifikat kvart av dei må samsvare med. Den neste som legg til ein server, kopierer mønsteret han finn først.