OpenVPN-i kliendinimed dnsmasqis: skript või staatilised kirjed?

Kliendi aadressid muutuvad, teenuste nimed mitte. Genereerige kliendinimed VPN-seansist, kinnitage teenuste nimed drop-in faili ja pange kliendid seda kasutama.

Peaaegu igal väiksel OpenVPN-lüüsil ilmneb kaks nimeprobleemi. Ühendatud sülearvutini ei saa selle sertifikaadil oleva nime kaudu, ja tunnelitagustel teenustel pole üldse nimesid. Need näivad ühe probleemina ja vajavad vastupidist käsitlust, sest üks aadress liigub iga seansiga ja teine mitte. Otsustage, millist tüüpi nime te lisate, enne kui midagi muudate.

Otsustage nime, mitte lüüsi kaupa

Test on lihtne: kas see aadress muutub, kui klient uuesti ühendub? Kui jah, tuleb nimi genereerida VPN-seansist. Kui ei, kuulub see staatilisse kirjesse, mida saate lugeda ja üle vaadata.

Name kindSource of truthWhere it lives
Connected clientThe address OpenVPN just assignedGenerated hosts file, rewritten per session
Service behind the tunnelA fixed address you choseStatic address= drop-in
Anything with a certificate nameThe certificate, not the poolEither, but the name must match the certificate

Nende segamine on tavaline viga. Genereeritud faili kinnitatud teenus kaob esimesel korral, kui skript selle üle kirjutab, ja staatilisse kirjesse kirjutatud klient osutab sellele, kellel oli see aadress viimasena. Mõlemad vead jäävad nähtamatuks, kuni nimi laheneb vale masinani. Selleks ajaks eeldab siluja, et DNS on katki, mitte fail.

Dünaamiline tee: learn-address ja pool

OpenVPN teab määramist, las ta ütleb selle teile. Need serveri valikud muudavad määramise püsivaks ja skriptitavaks:

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äivitab teie skripti alati, kui aadress lisatakse, uuendatakse või kustutatakse, ja edastab toimingu, aadressi ja ühisnime. Minimaalne skript lisab kliendi kohta ühe rea ja eemaldab selle kustutamisel:

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

tun-seadmel on teine argument kliendi tunneliaadress, seega on rida otse kasutatav. tap-seadmel edastab OpenVPN selle asemel kliendi MAC-aadressi, sest tap-segment võib kanda ka muid protokolle peale IPv4, ja siis tuleb aadress enne millegi kirjutamist poolifailist ühisnime järgi üles otsida.

Olge selge, mis genereeritud fail on: hetktõmmis sellest, kes on praegu ühendatud. Nimed kaovad ühenduse katkemisel, mis on täpselt see, mida soovite võrgu vahel liikuvate sülearvutite jaoks ja täpselt see, mida te ei soovi serveri jaoks, mis töötab terve öö.

Staatiline tee: address= ja domeeni laiendamine

Suunake dnsmasq genereeritud failile süsteemse hosts-faili asemel ja andke sellele domeen, et lühikesed nimed laieneksid täielikult kvalifitseeritud nimedeks:

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

Kui domain on seatud, vastab rida nagu 10.8.0.6 alice nii alice kui ka alice.corp.example kohta. Hoidke listen-address ainult tunnelilüüsil ja loopbackil, sest LAN-liidesele kogemata avaldatud resolver on teenus, mida te ei kavatsenud pakkuda.

Teenused, mis ei tule kunagi poolist, saavad oma kirjed. Pange need eraldi drop-in faili distributsiooni konfiguratsioonikataloogi, et paketi uuendus ei saaks neid üle kirjutada:

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

Andke resolver üle, muidu ei juhtu midagi

Resolverit, millelt keegi ei küsi, ei muuda midagi. Server peab seda reklaamima:

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

Windowsi kliendid rakendavad mõlemat valikut ise. Enamik Linuxi kliente ei tee seda: neil on vaja toetatud resolveri integratsiooni, näiteks distributsiooni update-resolv-conf konksu või NetworkManageri DNS-käsitlust, või käsitsi seatud otsingudomeeni ja nimeserverit. Kontrollige kliendi tegelikku resolverit, selle asemel et eeldada, et push järgiti, sest ignoreeritud push näeb välja täpselt nagu server, mis ei vasta.

Kontrollige kolmel tasandil

Küsige esmalt otse serverilt, seejärel kliendilt ja lõpuks rakenduselt:

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

Kui otsesed päringud vastavad ja rakendus mitte, on viga kliendile üleandmises, mitte tsoonis. Kui nimi laheneb ja ühendus siiski ebaõnnestub, on nimi korras ja järgmisena tuleb vaadata marsruuti või tulemüüri.

Kirjutage kaks kategooriat konfiguratsiooni kõrvale: millised nimed genereeritakse, millised on kinnitatud ja millise sertifikaadiga peab igaüks sobima. Järgmine inimene, kes serveri lisab, kopeerib mustri, mille ta esimesena leiab.

Seotud artiklid