Server OpenVPN cu nopool: declarați un interval de pool explicit

Utilitarele de ajutor ale serverului configurează o subrețea și apoi o umplu cu un pool dinamic ales de ele. Această valoare implicită este comodă până când unele adrese trebuie să rămână în afara alocării — fie rezervate pentru atribuiri fixe, fie păstrate pentru un segment viitor. Suprimarea pool-ului automat și declararea intervalului pe cont propriu necesită două linii și o decizie deliberată privind adresele care nu sunt pentru alocare. Restul este disciplină operațională: inventar, aplicare, verificare, revenire.

Aceasta este o modificare a unui serviciu în funcțiune, așa că tratați-o ca pe o sarcină operațională: mai întâi inventarul, apoi aplicarea prin ciclul de viață normal, verificarea cu un client nou și o revenire pregătită.

Începeți de la subrețeaua pe care o aveți deja

Citiți configurația actuală a serverului și adresele pe care clienții le dețin efectiv. Modificarea pool-ului are sens doar față de acea bază, iar baza nu este întotdeauna ceea ce sugerează fișierul, pentru că un produs gestionat sau un generator de configurație poate deține fișierul pe care îl citiți.

grep -nE '^(topology|server|ifconfig-pool|max-clients|client-config-dir)' /etc/openvpn/server/lab.conf
ip -4 addr show tun0

Confirmați topologia în vigoare. În topologia de subrețea fiecare client ia o adresă din pool; machetele net30 mai vechi alocă un bloc mic pe client, iar aritmetica este complet diferită. Dacă serverul este încă pe net30, această pagină este ghidul de migrare greșit, iar numerele pool-ului nu vor însemna ceea ce vă așteptați. Verificați acea linie înainte de a copia aritmetica adreselor de altundeva.

Notați adresa serverului însuși, fiecare atribuire fixă din directorul de configurații ale clienților și orice adresă de care depinde o rută sau o regulă de acces. Acestea sunt adresele care trebuie să rămână în afara intervalului dinamic. Faptul că le notați mai întâi este ceea ce transformă intervalul într-o decizie, nu într-o presupunere. Oferă, de asemenea, revenirii ceva concret de restaurat.

Adăugați nopool și declarați intervalul

Cuvântul-cheie auxiliar acceptă nopool, care păstrează configurația subrețelei și suprimă pool-ul dinamic automat, așa cum descrie manualul OpenVPN 2.6. Linia explicită ifconfig-pool furnizează apoi intervalul inclusiv dorit, iar masca sa de rețea corespunde subrețelei. Ambele linii aparțin aceluiași bloc de server, pentru că un pool fără subrețeaua sa nu are sens. Ordinea dintre ele contează doar pentru lizibilitate, deoarece auxiliarul desfășoară perechea la pornirea serviciului.

topology subnet
server 10.70.0.0 255.255.255.0 nopool
ifconfig-pool 10.70.0.50 10.70.0.120 255.255.255.0

Ambele limite sunt inclusive, așa că exemplul oferă șaptezeci și unu de adrese. Țineți adresa serverului și fiecare atribuire fixă în afara acelui interval; o atribuire fixă care cade în intervalul dinamic produce o coliziune dependentă de ordinea conexiunilor, iar acesta este cel mai rău tip de depanat. Lăsați o marjă între setul rezervat și interval dacă atribuirile fixe probabil vor crește.

Dimensiunea intervalului și concurența sunt limite separate. O sută de adrese nu înseamnă o sută de clienți simultani dacă max-clients spune altfel, iar un pool mai mare decât limita de concurență este normal, nu risipă. Important este ca cele două limite să fie alese deliberat, nu moștenite dintr-o valoare implicită.

Țineți atribuirile fixe în afara intervalului dinamic

Un ifconfig-push specific unui client este un mecanism diferit de alocarea din pool și trebuie să folosească parametri potriviți topologiei active. În modul subrețea este o singură adresă și o mască de rețea; preluarea unei perechi net30 pentru că a apărut într-un exemplu vechi este o greșeală frecventă.

Istoricul alocărilor este un indiciu, nu o autoritate. Un fișier persist reține ce client a avut ce adresă, astfel încât clienții care se reconectează tind să primească aceeași, și nu rezervă adrese, nu le eliberează și nu înlocuiește o atribuire fixă. Dacă un anumit dispozitiv trebuie să dețină întotdeauna o anumită adresă, folosiți o atribuire fixă în loc să vă bazați pe fișierul persist.

Apoi verificați căile care depind de adrese. O rută împinsă către clienți, o regulă de firewall care admite o subrețea sau o verificare de monitorizare care așteaptă un anumit host pot toate presupune vechiul interval. Schimbarea pool-ului fără a le citi mută defecțiunea într-un loc care pare nelegat.

Aplicați prin ciclul de viață, apoi verificați

Aplicați modificarea așa cum serviciul primește de obicei configurația — fie un fișier direct plus repornire, fie un strat de management care regenerează fișierul. O editare manuală într-un fișier generat supraviețuiește până la următoarea generare, și nu mai mult. Înregistrați ce mecanism deține fișierul, pentru că următorul operator va trebui să știe unde să facă aceeași modificare. Apoi reporniți o dată și citiți jurnalul înainte de a invita un client.

systemctl restart openvpn-server@lab
journalctl -u openvpn-server@lab -n 30 --no-pager
# on a fresh client
ip -4 addr show tun0

Conectați un client care nu fusese conectat anterior și confirmați că adresa cade în intervalul declarat și în afara setului rezervat. Apoi confirmați calea de întoarcere: clientul trebuie să ajungă la ce permite politica și nimic mai mult. O adresă care corespunde planului dar nu are o rută funcțională nu este o modificare reușită.

Reconectați un client care deținea o adresă din intervalul vechi. Ar trebui să primească o adresă din noul interval, iar orice stare la nivel de sesiune legată de adresa veche ar trebui să fi dispărut. Dacă păstrează adresa veche, altceva i-o atribuie, iar pool-ul nu este proprietarul pe care îl credeți.

Revenirea asupra unei modificări de interval

Păstrați cele trei linii anterioare în registrul de modificări, nu doar fișierul anterior. Restaurarea lor și repornirea readuc alocarea la comportamentul vechi, iar clienții care se reconectează ulterior vor primi adrese din el.

Două avertismente aparțin registrului. Clienții deja conectați când faceți revenirea își păstrează adresele actuale până la reconectare, așa că o revenire nu este instantanee în toată flota. Și dacă intervalul vechi se suprapunea cu o atribuire fixă, restaurarea lui restaurează și coliziunea; exact acea suprapunere a fost motivul modificării și necesită o soluție diferită de o revenire.

O modificare de pool este terminată când un client nou primește o adresă în interval, o adresă rezervată nu este niciodată distribuită și rutele și regulile care consumă acele adrese se comportă în continuare conform intenției. Orice mai puțin lasă următoarei persoane sarcina de a descoperi care dintre cele trei nu este adevărată.