OpenVPN-asiakasnimet dnsmasqissa: skripti vai staattiset merkinnät?

Lähes jokaisella pienellä OpenVPN-yhdyskäytävällä ilmenee kaksi nimiongelmaa. Yhdistettyyn kannettavaan ei pääse sen varmenteessa olevalla nimellä, eikä tunnelin takana olevilla palveluilla ole lainkaan nimiä. Ne näyttävät yhdeltä ongelmalta ja vaativat vastakkaiset ratkaisut, koska toinen osoite liikkuu jokaisen istunnon mukana ja toinen ei. Päätä, millaista nimeä olet lisäämässä, ennen kuin muokkaat mitään.

Päätä nimen, älä yhdyskäytävän mukaan

Testi on yksinkertainen: muuttuuko tämä osoite, kun asiakas yhdistää uudelleen? Jos kyllä, nimi on luotava VPN-istunnosta. Jos ei, se kuuluu staattiseen merkintään, jonka voit lukea ja tarkistaa.

Niiden sekoittaminen on tavallinen virhe. Luotuun tiedostoon kiinnitetty palvelu katoaa, kun skripti kirjoittaa tiedoston ensimmäisen kerran uudelleen, ja staattiseen merkintään kirjoitettu asiakas osoittaa sille, jolla tuo osoite oli viimeksi. Molemmat virheet pysyvät näkymättöminä, kunnes nimi ratkeaa väärään koneeseen. Siihen mennessä vianetsijä olettaa DNS:n olevan rikki eikä tiedoston.

Dynaaminen polku: learn-address ja pooli

OpenVPN tuntee määrityksen, joten anna sen kertoa se. Nämä palvelinasetukset tekevät määrityksestä pysyvän ja skriptattavan:

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 suorittaa skriptisi aina, kun osoite lisätään, päivitetään tai poistetaan, ja välittää toiminnon, osoitteen ja yleisnimen. Minimaalinen skripti lisää yhden rivin asiakasta kohden ja poistaa sen poistettaessa:

#!/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-laitteella toinen argumentti on asiakkaan tunneliosoite, joten rivi on sellaisenaan käyttökelpoinen. tap-laitteella OpenVPN välittää sen sijaan asiakkaan MAC-osoitteen, koska tap-segmentti voi kuljettaa muitakin protokollia kuin IPv4, ja silloin osoite on etsittävä pooli-tiedostosta yleisnimen perusteella ennen kuin kirjoitat mitään.

Ole selvillä siitä, mikä luotu tiedosto on: tilannekuva siitä, kuka on juuri nyt yhteydessä. Nimet katoavat yhteyden katketessa, mikä on juuri se, mitä haluat verkkojen välillä liikkuville kannettaville, ja juuri se, mitä et halua palvelimelle, joka on päällä koko yön.

Staattinen polku: address= ja verkkotunnuksen laajennus

Ohjaa dnsmasq luotuun tiedostoon järjestelmän hosts-tiedoston sijaan ja anna sille verkkotunnus, jotta lyhyet nimet laajenevat täysin kelpuutetuiksi:

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

Kun domain on asetettu, rivi kuten 10.8.0.6 alice vastaa sekä alice että alice.corp.example. Pidä listen-address vain tunneliyhdyskäytävässä ja loopbackissa, koska LAN-rajapinnalle vahingossa julkaistu resolveri on palvelu, jota et aikonut tarjota.

Palvelut, jotka eivät koskaan tule poolista, saavat omat merkintänsä. Laita ne erilliseen drop-in-tiedostoon jakelun asetushakemistoon, jotta paketin päivitys ei voi korvata niitä:

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

Luovuta resolveri tai mitään ei tapahdu

Resolveri, jolta kukaan ei kysy, ei muuta mitään. Palvelimen on ilmoitettava se:

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

Windows-asiakkaat soveltavat molemmat asetukset itse. Useimmat Linux-asiakkaat eivät: ne tarvitsevat tuetun resolveri-integraation, kuten jakelun update-resolv-conf-koukun tai NetworkManagerin DNS-käsittelyn, tai käsin asetetun hakuverkkotunnuksen ja nimipalvelimen. Tarkista asiakkaan todellinen resolveri sen sijaan, että oletat pushin noudatetun, koska huomiotta jätetty push näyttää täsmälleen samalta kuin palvelin, joka ei vastaa.

Varmista kolmella tasolla

Kysy ensin palvelimelta suoraan, sitten asiakkaalta ja lopuksi sovellukselta:

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

Jos suorat kyselyt vastaavat ja sovellus ei, vika on asiakkaalle luovutuksessa eikä vyöhykkeessä. Jos nimi ratkeaa ja yhteys silti epäonnistuu, nimi on kunnossa ja seuraavaksi on katsottava reittiä tai palomuuria.

Kirjoita kaksi luokkaa asetusten viereen: mitkä nimet luodaan, mitkä on kiinnitetty ja mihin varmenteeseen kunkin on vastattava. Seuraava palvelimen lisääjä kopioi ensimmäisenä löytämänsä mallin.