Adrese de client OpenVPN statice în spatele OPNsense

Numele au nevoie de adrese care nu se mișcă, iar fișierul de pool al OpenVPN doar face o adresă lipicioasă. Pierdeți acel fișier sau reemiteți un certificat sub un alt nume comun, iar clientul care revine aterizează în altă parte în pool, în timp ce înregistrarea lui DNS indică în continuare adresa veche. Răspunsul durabil este o suprascriere specifică clientului care fixează adresa, plus o rețea de tunel mai largă, astfel încât adresele fixate să stea în afara intervalului dinamic. Aritmetica din spatele acelei lărgiri este locul unde trăiește cea mai mare parte a confuziei.

OPNsense păstrează aceste suprascrieri în setările specifice clientului ale serverului, cheiate pe numele comun al certificatului, ceea ce face din numele comun o parte a planului de adrese.

O închiriere lipicioasă nu este o adresă statică

Fișierul de pool scrie mapări adresă-client și le returnează când un client cunoscut se reconectează. Aceasta este o comoditate, nu un contract: fișierul poate fi regenerat, maparea dispare când identitatea clientului se schimbă, iar două servere care partajează un pool nu vor fi de acord. O suprascriere specifică clientului funcționează diferit, pentru că adresa vine din configurație, nu din istoric. Supraviețuiește și unei reporniri și unei reinstalări a aparatului, cu condiția ca suprascrierea să fie salvată împreună cu restul configurației.

Alternativa dinamică, conectarea VPN-ului la DNS cu un script de conectare a clientului și actualizări dinamice, funcționează și necesită un resolver care acceptă actualizări plus un script la fiecare conectare. Pe un aparat ești limitat la pachetele livrate de producător, și de obicei acolo se oprește acel plan.

Aritmetica /30 pe care nimeni nu o agreează

În topologia net30 implicită, fiecare client primește propriul /30: prima adresă utilizabilă merge la partea serverului, a doua la client. Prin urmare, suprascrierile trebuie să stea în afara rețelei de tunel dinamice a serverului, ceea ce înseamnă că rețeaua trebuie mai întâi lărgită. Un server pe 10.8.0.0/24 poate trece la 10.8.0.0/23, lăsând jumătate din intervalul vechi pentru clienții dinamici și cealaltă jumătate pentru suprascrieri. Adăugați /24 original ca rețea locală IPv4 suplimentară, astfel încât traficul către ambele jumătăți să intre în tunel.

Fiecare adresă de suprascriere trebuie să cadă pe o frontieră /30, deci ultimul octet este un multiplu de patru. Un /30 pe 10.8.1.0 îi dă clientului 10.8.1.2, iar aceasta este adresa pe care o poartă înregistrarea DNS. Alegerea lui 10.8.1.3 în schimb produce un client care se conectează și nu poate trece trafic, pentru că adresa aparține unei subrețele pe care topologia nu i-a atribuit-o niciodată.

Planul este mai ușor de menținut dacă suprascrierile sunt alocate de sus în jos din intervalul lărgit, astfel încât pool-ul dinamic să se extindă în spațiul liber, nu în jurul unor insule fixe.

Rețele locale și zona pe care o interoghează clienții

Traficul de la client la client are nevoie de propria permisiune. Lista de rețele locale IPv4 a serverului trebuie să includă ambele jumătăți ale intervalului, dinamică și statică; fără ea, serverul acceptă un pachet de la un client și nu are nicio politică ce îl lasă să treacă la altul. Simptomul se citește ca o defecțiune DNS, pentru că numele se rezolvă și conexiunea tot eșuează. Verificați în același timp setarea client-la-client, deoarece o singură intrare de rețea locală nu activează redirecționarea între parteneri.

Publicați înregistrările în zona pe care clienții la distanță o interoghează efectiv. O înregistrare într-o zonă deservită doar de resolver-ul LAN este invizibilă pentru un client al cărui resolver împins indică în altă parte, iar adăugarea mai multor înregistrări în zona greșită nu repară niciodată asta. Confirmați opțiunea DNS împinsă și domeniul de căutare înainte de a adăuga orice.

Ce trebuie verificat la o conexiune nouă

Reconectați clientul și confirmați că adresa atribuită corespunde suprascrierii sale înainte de a testa orice altceva. Apoi rezolvați numele de la un al doilea client și conectați-vă la serviciu după nume, ceea ce testează împreună înregistrarea DNS, ruta și firewall-ul. Confirmați calea de răspuns pe partea serverului, pentru că un nume care se rezolvă în timp ce serviciul rămâne inaccesibil este o problemă de rutare sau de politică, nu de denumire. Țineți tabelul de suprascrieri lângă lista de certificate, astfel încât ambele să fie revizuite împreună.

Un certificat reemis sub un alt nume comun nu mai corespunde suprascrierii sale și readuce clientul în pool-ul dinamic. Așteptați-vă la asta după orice schimbare de identitate.