Numele clienților OpenVPN în dnsmasq: script sau intrări statice?

Adresele clienților se schimbă, numele serviciilor nu. Generați numele clienților din sesiunea VPN, fixați numele serviciilor într-un fișier drop-in, apoi faceți clienții să îl folosească.

Aproape pe fiecare gateway OpenVPN mic apar două probleme de nume. Nu puteți ajunge la un laptop conectat după numele din certificatul lui, iar serviciile din spatele tunelului nu au deloc nume. Par o singură problemă și cer tratamente opuse, pentru că o adresă se mișcă la fiecare sesiune, iar cealaltă nu. Decideți ce fel de nume adăugați înainte de a edita ceva.

Decideți pe nume, nu pe gateway

Testul este simplu: această adresă se schimbă când un client se reconectează? Dacă da, numele trebuie generat din sesiunea VPN. Dacă nu, aparține unei intrări statice pe care o puteți citi și revizui.

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

Amestecarea lor este eșecul obișnuit. Un serviciu fixat în fișierul generat dispare prima dată când scriptul îl rescrie, iar un client scris într-o intrare statică arată spre cel care a avut acea adresă ultima dată. Ambele greșeli rămân invizibile până când un nume se rezolvă la mașina greșită. Până atunci, cel care depanează presupune că DNS-ul e stricat, nu fișierul.

Calea dinamică: learn-address și pool-ul

OpenVPN cunoaște alocarea, așa că lăsați-l să vă spună. Aceste opțiuni de server fac alocarea durabilă și scriptabilă:

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 rulează scriptul dvs. de fiecare dată când o adresă este adăugată, actualizată sau ștearsă, și transmite operația, adresa și numele comun. Un script minim adaugă o linie pentru fiecare client și o elimină la ștergere:

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

Pe un dispozitiv tun al doilea argument este adresa de tunel a clientului, deci linia poate fi folosită direct. Pe un dispozitiv tap OpenVPN transmite în schimb adresa MAC a clientului, pentru că un segment tap poate transporta și alte protocoale decât IPv4, iar atunci trebuie să căutați adresa în fișierul pool după numele comun înainte de a scrie ceva.

Fiți clari cu privire la ce este fișierul generat: o instantanee a cine este conectat acum. Numele dispar la deconectare, ceea ce este exact ce doriți pentru laptopuri care se mută între rețele și exact ce nu doriți pentru un server pornit toată noaptea.

Calea statică: address= și extinderea domeniului

Îndreptați dnsmasq spre fișierul generat în locul fișierului hosts al sistemului, și dați-i un domeniu ca numele scurte să se extindă în nume complet calificate:

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

Cu domain setat, o linie precum 10.8.0.6 alice răspunde atât pentru alice, cât și pentru alice.corp.example. Țineți listen-address doar pe gateway-ul tunelului și pe loopback, pentru că un resolver publicat din greșeală pe interfața LAN este un serviciu pe care nu intenționați să îl oferiți.

Serviciile care nu vin niciodată din pool au propriile intrări. Puneți-le într-un fișier drop-in separat în directorul de configurare al distribuției, ca o actualizare de pachet să nu le poată suprascrie:

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

Predați resolverul sau nu se întâmplă nimic

Un resolver pe care nimeni nu îl întreabă nu schimbă nimic. Serverul trebuie să îl anunțe:

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

Clienții Windows aplică singuri ambele opțiuni. Majoritatea clienților Linux nu: au nevoie de o integrare de resolver acceptată, cum ar fi cârligul update-resolv-conf al distribuției sau gestionarea DNS din NetworkManager, ori de un domeniu de căutare și un nameserver setate manual. Verificați resolverul real al clientului în loc să presupuneți că push-ul a fost respectat, pentru că un push ignorat arată exact ca un server care nu răspunde.

Verificați pe trei straturi

Întrebați mai întâi serverul direct, apoi un client, apoi aplicația:

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

Dacă interogările directe răspund și aplicația nu, vina este la predarea către client, nu la zonă. Dacă numele se rezolvă și conexiunea tot eșuează, numele este în regulă și următorul lucru de verificat este ruta sau firewall-ul.

Notați cele două categorii lângă configurație: ce nume sunt generate, care sunt fixate și cu ce certificat trebuie să corespundă fiecare. Următoarea persoană care adaugă un server va copia primul model pe care îl găsește.

Articole similare