OpenVPN-kliensnevek a dnsmasqban: szkript vagy statikus bejegyzések?

Szinte minden kis OpenVPN-átjárón két névprobléma bukkan fel. Egy csatlakozott laptopot nem ér el a tanúsítványán szereplő néven, az alagút mögötti szolgáltatásoknak pedig egyáltalán nincs nevük. Egyetlen problémának tűnnek, mégis ellentétes kezelést kívánnak, mert az egyik cím minden munkamenettel mozog, a másik nem. Döntse el, milyen fajta nevet ad hozzá, mielőtt bármit szerkesztene.

Névenként döntsön, ne átjárónként

A próba egyszerű: változik ez a cím, amikor egy kliens újracsatlakozik? Ha igen, a nevet a VPN-munkamenetből kell előállítani. Ha nem, akkor egy statikus bejegyzésbe tartozik, amelyet elolvashat és átnézhet.

A keverésük a szokásos hiba. A generált fájlba rögzített szolgáltatás eltűnik, amikor a szkript először újraírja a fájlt, a statikus bejegyzésbe írt kliens pedig arra mutat, akinél az a cím legutóbb volt. Mindkét hiba láthatatlan marad, amíg egy név a rossz gépre nem oldódik fel. Addig a hibakereső azt feltételezi, hogy a DNS romlott el, nem a fájl.

A dinamikus út: learn-address és a pool

OpenVPN ismeri a hozzárendelést, hát hagyja, hogy elmondja. Ezek a kiszolgálóbeállítások tartóssá és szkriptelhetővé teszik a hozzárendelést:

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 minden alkalommal lefuttatja a szkriptjét, amikor egy címet hozzáadnak, frissítenek vagy törölnek, és átadja a műveletet, a címet és a közös nevet. Egy minimális szkript kliensenként egy sort fűz hozzá, és törléskor eltávolítja:

#!/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-eszközön a második argumentum a kliens alagútcíme, így a sor közvetlenül használható. tap-eszközön az OpenVPN helyette a kliens MAC-címét adja át, mert egy tap-szegmens IPv4-től eltérő protokollokat is szállíthat, és akkor a címet a közös név alapján kell megkeresnie a pool-fájlban, mielőtt bármit ír.

Legyen tisztában azzal, mi a generált fájl: pillanatkép arról, ki van most csatlakozva. A nevek lecsatlakozáskor eltűnnek, ami pontosan az, amit a hálózatok között mozgó laptopoknál szeretne, és pontosan az, amit egy egész éjjel futó kiszolgálónál nem szeretne.

A statikus út: address= és tartománykiterjesztés

Irányítsa a dnsmasqot a generált fájlra a rendszer hosts fájlja helyett, és adjon neki tartományt, hogy a rövid nevek teljesen minősített nevekké bővüljenek:

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

Ha a domain be van állítva, egy 10.8.0.6 alice alakú sor a alice és a alice.corp.example nevet is kiszolgálja. Tartsa a listen-address beállítást csak az alagút átjáróján és loopbacken, mert a LAN-interfészen véletlenül közzétett feloldó olyan szolgáltatás, amelyet nem szándékozott nyújtani.

A poolból soha nem érkező szolgáltatások saját bejegyzést kapnak. Tegye őket külön drop-in fájlba a disztribúció konfigurációs könyvtárában, hogy egy csomagfrissítés ne írja felül őket:

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

Adja át a feloldót, különben semmi sem történik

Az a feloldó, amelyet senki sem kérdez, semmit sem változtat. A kiszolgálónak hirdetnie kell:

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

A Windows-kliensek maguk alkalmazzák mindkét beállítást. A legtöbb Linux-kliens nem: támogatott feloldóintegrációra van szükségük, például a disztribúció update-resolv-conf hookjára vagy a NetworkManager DNS-kezelésére, esetleg kézi keresési tartományra és névkiszolgálóra. Ellenőrizze a kliens tényleges feloldóját ahelyett, hogy feltételezné a push betartását, mert a figyelmen kívül hagyott push pontosan úgy néz ki, mint egy nem válaszoló kiszolgáló.

Három rétegen ellenőrizze

Először közvetlenül a kiszolgálót kérdezze, aztán egy klienst, végül az alkalmazást:

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

Ha a közvetlen lekérdezések válaszolnak és az alkalmazás nem, a hiba a kliensnek való átadásban van, nem a zónában. Ha a név feloldódik és a kapcsolat mégis meghiúsul, a név rendben van, és a következő, amit nézni kell, az útvonal vagy a tűzfal.

Írja fel a két kategóriát a konfiguráció mellé: mely nevek generálódnak, melyek rögzítettek, és melyik tanúsítványhoz kell mindegyiknek illeszkednie. A következő ember, aki kiszolgálót ad hozzá, az elsőként talált mintát fogja másolni.