OpenVPN-klientnamn i dnsmasq: skript eller statiska poster?

Klientadresser ändras, tjänstenamn gör det inte. Generera klientnamn från VPN-sessionen, fäst tjänstenamn i en drop-in-fil och låt sedan klienterna använda den.

Två namnproblem dyker upp på nästan varje liten OpenVPN-gateway. Du når inte en ansluten bärbar dator via namnet på dess certifikat, och tjänsterna bakom tunneln har inga namn alls. De ser ut som ett problem och kräver motsatt behandling, eftersom den ena adressen flyttar sig med varje session och den andra inte. Bestäm vilken sorts namn du lägger till innan du redigerar något.

Bestäm per namn, inte per gateway

Testet är enkelt: ändras den här adressen när en klient återansluter? Om ja måste namnet genereras från VPN-sessionen. Om nej hör det hemma i en statisk post som du kan läsa och granska.

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

Att blanda dem är det vanliga felet. En tjänst som fästs i den genererade filen försvinner första gången skriptet skriver om den, och en klient som skrivs in i en statisk post pekar på den som hade adressen senast. Båda felen förblir osynliga tills ett namn löses upp till fel maskin. Då antar den som felsöker att DNS är trasigt och inte filen.

Den dynamiska vägen: learn-address och poolen

OpenVPN känner till tilldelningen, så låt den berätta den. De här serveralternativen gör tilldelningen varaktig och 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 kör ditt skript varje gång en adress läggs till, uppdateras eller tas bort, och skickar operationen, adressen och det gemensamma namnet. Ett minimalt skript lägger till en rad per klient och tar bort den vid borttagning:

#!/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 är det andra argumentet klientens tunneladress, så raden kan användas direkt. På en tap-enhet skickar OpenVPN i stället klientens MAC-adress, eftersom ett tap-segment kan bära andra protokoll än IPv4, och då måste du slå upp adressen i poolfilen efter det gemensamma namnet innan du skriver något.

Var tydlig med vad den genererade filen är: en ögonblicksbild av vem som är ansluten just nu. Namn försvinner vid frånkoppling, vilket är precis vad du vill ha för bärbara datorer som flyttar mellan nätverk och precis vad du inte vill ha för en server som står på hela natten.

Den statiska vägen: address= och domänutökning

Peka dnsmasq mot den genererade filen i stället för systemets hosts-fil, och ge den en domän så att korta namn utökas till fullt kvalificerade:

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 är satt svarar en rad som 10.8.0.6 alice både för alice och alice.corp.example. Håll listen-address till tunnelgatewayen och loopback, eftersom en resolver som av misstag publiceras på LAN-gränssnittet är en tjänst du inte hade för avsikt att erbjuda.

Tjänster som aldrig kommer från poolen får egna poster. Lägg dem i en separat drop-in-fil under distributionens konfigurationskatalog så att en paketuppgradering inte kan skriva över dem:

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

Lämna över resolvern, annars händer ingenting

En resolver som ingen frågar ändrar ingenting. Servern måste annonsera den:

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

Windows-klienter tillämpar båda alternativen själva. De flesta Linux-klienter gör det inte: de behöver en stödd resolverintegration som distributionens update-resolv-conf-krok eller NetworkManagers DNS-hantering, eller en manuell sökdomän och namnserver. Kontrollera klientens faktiska resolver i stället för att anta att pushen följdes, eftersom en ignorerad push ser exakt ut som en server som inte svarar.

Verifiera på tre lager

Fråga servern direkt först, sedan en klient, sedan applikationen:

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

Om direkta frågor svarar och applikationen inte, ligger felet i överlämningen till klienten och inte i zonen. Om namnet löses upp och anslutningen fortfarande misslyckas är namnet i ordning och nästa sak att titta på är rutten eller brandväggen.

Skriv ned de två kategorierna bredvid konfigurationen: vilka namn som genereras, vilka som är fästa och vilket certifikat varje måste matcha. Nästa person som lägger till en server kopierar det första mönster hen hittar.

Relaterade artiklar