OpenVPN-klientnavn i dnsmasq: skript eller statiske oppføringer?
Klientadresser endres, tjenestenavn gjør det ikke. Generer klientnavn fra VPN-økten, fest tjenestenavn i en drop-in-fil og få deretter klientene til å bruke den.
To navneproblemer dukker opp på nesten enhver liten OpenVPN-gateway. Du når ikke en tilkoblet bærbar PC via navnet på sertifikatet, og tjenestene bak tunnelen har ingen navn i det hele tatt. De ser ut som ett problem og krever motsatt behandling, fordi den ene adressen flytter seg med hver økt og den andre ikke. Bestem hvilken type navn du legger til før du redigerer noe.
Bestem per navn, ikke per gateway
Testen er enkel: endres denne adressen når en klient kobler til på nytt? Hvis ja, må navnet genereres fra VPN-økten. Hvis nei, hører det hjemme i en statisk oppføring du kan lese og gjennomgå.
| 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 dem er den vanlige feilen. En tjeneste som er festet i den genererte filen, forsvinner første gang skriptet skriver den på nytt, og en klient som er skrevet inn i en statisk oppføring, peker på den som hadde adressen sist. Begge feilene forblir usynlige til et navn løses opp til feil maskin. Da antar den som feilsøker at DNS er ødelagt og ikke filen.
Den dynamiske veien: learn-address og poolen
OpenVPN kjenner tildelingen, så la den fortelle deg den. Disse servervalgene gjør tildelingen 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 kjører skriptet ditt hver gang en adresse legges til, oppdateres eller slettes, og sender operasjonen, adressen og det felles navnet videre. Et minimalt skript legger til én linje per klient og fjerner den 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å en tun-enhet er det andre argumentet klientens tunneladresse, så linjen kan brukes direkte. På en tap-enhet sender OpenVPN i stedet klientens MAC-adresse, fordi et tap-segment kan bære andre protokoller enn IPv4, og da må du slå opp adressen i pool-filen etter det felles navnet før du skriver noe.
Vær klar over hva den genererte filen er: et øyeblikksbilde av hvem som er tilkoblet akkurat nå. Navn forsvinner ved frakobling, som er nettopp det du vil ha for bærbare PC-er som flytter seg mellom nettverk, og nettopp det du ikke vil ha for en server som står på hele natten.
Den statiske veien: address= og domeneekspansjon
Pek dnsmasq mot den genererte filen i stedet for systemets hosts-fil, og gi den et domene slik at korte navn utvides 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 satt, svarer en linje som 10.8.0.6 alice både for alice og alice.corp.example. Hold listen-address til tunnelgatewayen og loopback, fordi en resolver som ved et uhell publiseres på LAN-grensesnittet, er en tjeneste du ikke hadde til hensikt å tilby.
Tjenester som aldri kommer fra poolen, får egne oppføringer. Legg dem i en egen drop-in-fil under distribusjonens konfigurasjonskatalog, slik at en pakkeoppgradering ikke kan overskrive dem:
address=/files.corp.example/10.8.0.20
address=/db.corp.example/10.9.0.5
Lever resolveren videre, ellers skjer ingenting
En resolver som ingen spør, endrer ingenting. Serveren må annonsere den:
push "dhcp-option DNS 10.8.0.1"
push "dhcp-option DOMAIN corp.example"
Windows-klienter bruker begge valgene selv. De fleste Linux-klienter gjør det ikke: de trenger en støttet resolverintegrasjon som distribusjonens update-resolv-conf-krok eller NetworkManagers DNS-håndtering, eller et manuelt søkedomene og navneserver. Kontroller klientens faktiske resolver i stedet for å anta at push-en ble etterlevd, fordi en ignorert push ser nøyaktig ut som en server som ikke svarer.
Bekreft på tre lag
Spør serveren direkte først, deretter en klient, deretter applikasjonen:
dig +short @10.8.0.1 alice.corp.example
getent hosts files.corp.example
Hvis direkte spørringer svarer og applikasjonen ikke, ligger feilen i overleveringen til klienten og ikke i sonen. Hvis navnet løses opp og tilkoblingen fortsatt feiler, er navnet i orden, og det neste du bør se på er ruten eller brannmuren.
Skriv ned de to kategoriene ved siden av konfigurasjonen: hvilke navn som genereres, hvilke som er festet, og hvilket sertifikat hvert av dem må samsvare med. Den neste som legger til en server, kopierer mønsteret hen finner først.