OpenVPN-klientnavne i dnsmasq: script eller statiske poster?

Klientadresser ændrer sig, tjenestenavne gør ikke. Generér klientnavne ud fra VPN-sessionen, fastlås tjenestenavne i en drop-in-fil, og lad derefter klienterne bruge den.

To navneproblemer dukker op på næsten enhver lille OpenVPN-gateway. Du kan ikke nå en tilsluttet bærbar computer via navnet på dens certifikat, og tjenesterne bag tunnelen har slet ingen navne. De ligner ét problem og kræver modsatte behandlinger, fordi den ene adresse flytter sig med hver session og den anden ikke. Beslut, hvilken slags navn du tilføjer, før du redigerer noget.

Beslut pr. navn, ikke pr. gateway

Testen er enkel: ændrer denne adresse sig, når en klient genopretter forbindelsen? Hvis ja, skal navnet genereres ud fra VPN-sessionen. Hvis nej, hører det til i en statisk post, du kan læse og gennemgå.

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

At blande dem er den sædvanlige fejl. En tjeneste, der er fastlåst i den genererede fil, forsvinder første gang scriptet skriver den igen, og en klient, der er skrevet ind i en statisk post, peger på den, der sidst havde adressen. Begge fejl forbliver usynlige, indtil et navn opløses til den forkerte maskine. Til den tid antager den, der fejlretter, at DNS er i stykker og ikke filen.

Den dynamiske vej: learn-address og poolen

OpenVPN kender tildelingen, så lad den fortælle dig den. Disse serverindstillinger gør tildelingen holdbar og scriptbar:

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ører dit script, hver gang en adresse tilføjes, opdateres eller slettes, og sender operationen, adressen og det fælles navn videre. Et minimalt script tilføjer én linje pr. klient og fjerner den ved sletning:

#!/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-enhed er det andet argument klientens tunneladresse, så linjen kan bruges direkte. På en tap-enhed sender OpenVPN i stedet klientens MAC-adresse, fordi et tap-segment kan bære andre protokoller end IPv4, og så skal du slå adressen op i pool-filen efter det fælles navn, før du skriver noget.

Vær klar over, hvad den genererede fil er: et øjebliksbillede af, hvem der er tilsluttet lige nu. Navne forsvinder ved afbrydelse, hvilket er præcis, hvad du vil have til bærbare computere, der flytter mellem netværk, og præcis, hvad du ikke vil have til en server, der kører hele natten.

Den statiske vej: address= og domæneudvidelse

Peg dnsmasq mod den genererede fil i stedet for systemets hosts-fil, og giv den et domæne, så korte navne udvides til fuldt kvalificerede:

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 er sat, svarer en linje som 10.8.0.6 alice både for alice og alice.corp.example. Hold listen-address til tunnelgatewayen og loopback, fordi en resolver, der ved et uheld offentliggøres på LAN-interfacet, er en tjeneste, du ikke havde til hensigt at tilbyde.

Tjenester, der aldrig kommer fra poolen, får deres egne poster. Læg dem i en separat drop-in-fil under distributionens konfigurationsmappe, så en pakkeopgradering ikke kan overskrive dem:

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

Aflever resolveren, ellers sker der intet

En resolver, som ingen spørger, ændrer intet. Serveren skal annoncere den:

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

Windows-klienter anvender begge indstillinger selv. De fleste Linux-klienter gør ikke: de har brug for en understøttet resolverintegration som distributionens update-resolv-conf-hook eller NetworkManagers DNS-håndtering, eller et manuelt søgedomæne og en navneserver. Kontroller klientens faktiske resolver i stedet for at antage, at push'et blev efterlevet, fordi et ignoreret push ser præcis ud som en server, der ikke svarer.

Bekræft på tre lag

Spørg først serveren direkte, derefter en klient og til sidst applikationen:

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

Hvis direkte forespørgsler svarer, og applikationen ikke gør, ligger fejlen i overdragelsen til klienten og ikke i zonen. Hvis navnet opløses, og forbindelsen stadig fejler, er navnet i orden, og det næste, du skal se på, er ruten eller firewallen.

Skriv de to kategorier ned ved siden af konfigurationen: hvilke navne der genereres, hvilke der er fastlåst, og hvilket certifikat hver af dem skal matche. Den næste, der tilføjer en server, kopierer det mønster, vedkommende finder først.

Relaterede artikler