Adresele stabile OpenVPN ar trebui să urmeze identitatea, nu IP-ul sursă
O adresă statică este o afirmație despre o identitate, nu despre un IP sursă. Alegeți cheia, țineți rezervările în afara pool-ului, apoi alegeți proprietarul alocării.
Planurile de adrese care spun „acest laptop primește 10.90.0.10” sunt de fapt afirmații despre identitate: ce dispozitiv autentificat poate deține acea adresă. IP-ul public actual al acelui dispozitiv aproape nu are legătură cu asta, pentru că NAT și roaming îl schimbă fără a schimba cine este utilizatorul. Construirea planului pe adresa sursă produce reguli care se strică în prima rețea de hotel. Construirea lui pe identitatea autentificată produce un plan care supraviețuiește călătoriilor.
Începeți de la ce poate verifica serverul, apoi decideți pentru ce este adresa.
Alegeți cheia de identitate înainte de adresă
Un certificat de client separat pentru fiecare dispozitiv îi dă serverului o cheie stabilă și verificabilă pentru fiecare membru, care este cea mai curată bază pentru o alocare statică. O implementare cu autentificare pe utilizator poate folosi în schimb numele de utilizator, atâta timp cât selecția configurației urmează același câmp. Amestecarea celor două modele produce alocări care corespund unui certificat pentru un client și unui nume de utilizator pentru altul, și nimeni nu poate prezice care va câștiga. Decideți ce cheie folosește planul înainte de a scrie măcar o rezervare.
Cu duplicate-cn, mai multe sesiuni simultane pot prezenta același nume comun, așa că o singură adresă fixată nu le poate identifica individual. Aceasta este o proprietate a modelului de identitate, nu ceva ce un plan de adrese mai bun poate repara.
Rezervați adrese în afara intervalului dinamic
Într-o rețea cu topologie de subrețea precum 10.90.0.0/24, păstrați adresele joase pentru membrii numiți și puneți pool-ul dinamic într-un interval separat. O alocare pentru un membru fixat arată astfel ifconfig-push 10.90.0.10 255.255.255.0 în fișierul pe care serverul îl selectează pentru acea identitate. Al doilea argument înseamnă altceva sub net30, deci exemplul nu este neutru față de topologie. Citiți topologia înainte de a-l copia.
Persistența pool-ului înregistrează lease-urile recente și tinde să returneze aceeași adresă, ceea ce este o comoditate, nu o rezervare. Nu lăsați fișierul de persistență să devină registrul de proprietate, pentru că se schimbă cu istoricul conexiunilor, nu cu politica.
Prioritatea alocării decide cine câștigă
Manualul documentează o ordine: o alocare explicită generată în timpul client-connect poate intra în vigoare înaintea unei intrări client-config-dir, care la rândul ei precede alocarea obișnuită din pool. Acea ordine explică majoritatea rapoartelor „adresa fixată nu s-a aplicat”. Înseamnă și că un alocator dinamic care scrie configurație pe sesiune poate suprascrie silențios un fișier static pe care îl considerați autoritativ.
Alegeți un singur strat care deține alocările și faceți celelalte doar citire. Două straturi care ambele pretind că decid produc alocări dependente de moment.
Un alocator dinamic are nevoie de același model
O integrare client-connect care distribuie adrese pe sesiune este un alocator mic cu problemele obișnuite ale alocatoarelor. Trebuie să valideze identitatea solicitantă, să rezerve o adresă atomic, să emită doar ieșirea pe conexiune acceptată și să elibereze rezervarea la deconectare sau eșec. Cererile concurente au nevoie de o blocare sau de o constrângere de bază de date, nu de o secvență citire-apoi-scriere. Fără curățare, pool-ul pierde adrese până la o repornire.
Țineți starea alocatorului acolo unde următorul operator o poate citi și înregistrați decizia identitate-către-adresă, nu doar adresa.
Decideți dacă adresa este politică sau comoditate
Dacă o regulă de firewall sau o rută permite trafic dintr-o adresă de tunel, atunci adresa participă la politica de acces și o realocare moștenește acea permisiune. Coordonați ciclul de viață al identității, adresei și firewall-ului, sau legați regula de ceva ce nu poate fi realocat. Adresarea stabilă face configurația lizibilă; nu înlocuiește autentificarea.
Scrieți planul ca inventar cu un proprietar pe intrare, apoi revizuiți-l când un dispozitiv este scos din uz. Rezervarea neutilizată este cea care este refolosită din greșeală.