Imena odjemalcev OpenVPN v dnsmasqu: skript ali statični vnosi?
Naslovi odjemalcev se spreminjajo, imena storitev ne. Ustvarite imena odjemalcev iz seje VPN, imena storitev pripnite v datoteko drop-in in nato poskrbite, da jo odjemalci uporabljajo.
Skoraj na vsakem majhnem prehodu OpenVPN se pojavita dve težavi z imeni. Do povezanega prenosnika ne pridete po imenu iz njegovega potrdila, storitve za tunelom pa nimajo nobenih imen. Videti sta kot ena težava in zahtevata nasprotno obravnavo, ker se en naslov premika z vsako sejo, drugi pa ne. Odločite se, kakšno vrsto imena dodajate, preden karkoli uredite.
Odločajte se po imenu, ne po prehodu
Preizkus je preprost: ali se ta naslov spremeni, ko se odjemalec znova poveže? Če da, je treba ime ustvariti iz seje VPN. Če ne, spada v statični vnos, ki ga lahko preberete in pregledate.
| 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 |
Njuno mešanje je običajna napaka. Storitev, pripeta v ustvarjeno datoteko, izgine ob prvem prepisu s skriptom, odjemalec, zapisan v statični vnos, pa kaže na tistega, ki je imel ta naslov nazadnje. Obe napaki ostaneta nevidni, dokler se ime ne razreši na napačen stroj. Takrat tisti, ki to odpravlja, domneva, da je pokvarjen DNS in ne datoteka.
Dinamična pot: learn-address in bazen
OpenVPN pozna dodelitev, zato naj vam jo pove. Te strežniške možnosti naredijo dodelitev trajno in skriptabilno:
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 zažene vaš skript vsakič, ko je naslov dodan, posodobljen ali izbrisan, in posreduje operacijo, naslov in skupno ime. Najmanjši skript doda eno vrstico na odjemalca in jo pri brisanju odstrani:
#!/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)
Na napravi tun je drugi argument tunelski naslov odjemalca, zato je vrstico mogoče uporabiti neposredno. Na napravi tap OpenVPN namesto tega posreduje MAC naslov odjemalca, ker lahko segment tap prenaša tudi druge protokole razen IPv4, in takrat morate naslov poiskati v datoteki bazena po skupnem imenu, preden karkoli napišete.
Bodite jasni, kaj je ustvarjena datoteka: posnetek tega, kdo je trenutno povezan. Imena ob prekinitvi izginejo, kar je natanko tisto, kar želite za prenosnike, ki se selijo med omrežji, in natanko tisto, česar si ne želite za strežnik, ki dela vso noč.
Statična pot: address= in razširitev domene
Usmerite dnsmasq na ustvarjeno datoteko namesto sistemske datoteke hosts in mu dajte domeno, da se kratka imena razširijo v polno kvalificirana:
domain=corp.example
no-hosts
addn-hosts=/etc/openvpn/hosts.lan
listen-address=127.0.0.1,10.8.0.1
bind-interfaces
Ko je domain nastavljen, se vrstica, kot je 10.8.0.6 alice, odziva tako za alice kot za alice.corp.example. Naj bo listen-address samo na prehodu tunela in loopbacku, ker je razreševalnik, ki je po nesreči objavljen na vmesniku LAN, storitev, ki je niste nameravali ponuditi.
Storitve, ki nikoli ne pridejo iz bazena, dobijo svoje vnose. Dajte jih v ločeno datoteko drop-in v konfiguracijski imenik distribucije, da jih nadgradnja paketa ne more prepisati:
address=/files.corp.example/10.8.0.20
address=/db.corp.example/10.9.0.5
Predajte razreševalnik ali se ne zgodi nič
Razreševalnik, ki ga nihče ne vpraša, ničesar ne spremeni. Strežnik ga mora objaviti:
push "dhcp-option DNS 10.8.0.1"
push "dhcp-option DOMAIN corp.example"
Odjemalci Windows obe možnosti uporabijo sami. Večina odjemalcev Linux ne: potrebujejo podprto integracijo razreševalnika, kot je kavelj update-resolv-conf distribucije ali upravljanje DNS v NetworkManageru, ali ročno nastavljeno iskalno domeno in imenski strežnik. Preverite dejanski razreševalnik odjemalca, namesto da domnevate, da je bil push upoštevan, ker je prezrt push videti natanko kot strežnik, ki se ne odziva.
Preverite na treh plasteh
Najprej vprašajte strežnik neposredno, nato odjemalca, nato aplikacijo:
dig +short @10.8.0.1 alice.corp.example
getent hosts files.corp.example
Če neposredne poizvedbe odgovorijo, aplikacija pa ne, je krivda v predaji odjemalcu in ne v coni. Če se ime razreši in povezava še vedno ne uspe, je ime v redu in naslednje, kar je treba pogledati, je pot ali požarni zid.
Zapišite obe kategoriji poleg konfiguracije: katera imena se ustvarjajo, katera so pripeta in s katerim potrdilom se mora vsako ujemati. Naslednja oseba, ki doda strežnik, bo kopirala prvi vzorec, ki ga najde.