Un cont VPN pe două servere: trei registre de stare

Un cont care se poate autentifica pe oricare dintre două noduri VPN ridică o întrebare de proiectare mult înainte de a ridica o întrebare de software. Vederea contului, rețeaua pe care o deține fiecare nod și sesiunea pe care o ține un client conectat sunt trei tipuri diferite de stare, și eșuează în moduri diferite când le copiați dintr-un loc în altul. Copierea tuturor trei într-un singur sistem este o modalitate obișnuită de a pierde unul dintre ele.

Parcurgeți cele trei registre de mai jos în ordine. Fiecare întreabă ce este autoritativ, ce este local și ce se întâmplă când celălalt nod lipsește, iar răspunsurile nu decurg unul din altul.

Cine se poate conecta: o autoritate, multe noduri

Începeți cu registrul de admitere: ce sursă de identitate este autoritativă, căror emitenți de certificate li se acordă încredere, ce conturi sunt eligibile, ce al doilea factor se aplică și la ce poate ajunge fiecare cont. Apoi notați cum află fiecare nod despre schimbări și cât de repede.

O bază de date partajată este o componentă posibilă a acelui răspuns. Nu este dovada că fiecare politică relevantă locuiește acolo sau că fiecare nod aplică o schimbare în același moment. Un cont dezactivat pe nodul A, dar încă acceptat pe nodul B, înseamnă că procesul de ieșire nu s-a încheiat.

Decideți ce face un nod când autoritatea nu este accesibilă. Acceptarea acreditărilor din cache în timpul unei întreruperi este o alegere de politică cu un cost de securitate, iar respingerea lor este o alegere de politică cu un cost de disponibilitate. Ambele sunt de apărat; lăsarea nedocumentată nu este.

Țineți autoritatea emitentului separată de datele contului. Mai multe gateway-uri pot avea încredere în același CA fără a deține cheia sa de semnare, iar fiecare nod are în continuare nevoie de propriul certificat de server și de propria relație de încredere pe partea clientului.

Ce deține un nod: adrese și rute

Al doilea registru este local fiecărui nod: adresa de ascultare, identitatea serverului, pool-ul de adrese, rutele către resurse private, politica resolver-ului și modul în care traficul iese spre internet. Același cont poate fi servit de oricare dintre cele două noduri, în timp ce aceste obiecte rămân distincte.

Calea de întoarcere este partea care se uită. Dacă ambele noduri distribuie adrese din același pool, rețeaua privată nu poate spune cărui nod îi aparține un anumit client, iar răspunsul poate fi trimis în locul greșit. Pool-urile diferite au nevoie și de rute și permisiuni, așa că un interval de numere distinct nu este un proiect complet.

Direcționați clienții către un nod în mod deliberat. Alegerea DNS, listele de puncte finale ale clientului și un serviciu de front-end sunt mecanisme diferite cu comportamente diferite de sănătate și de comutare la eșec. Alegerea unuia este în regulă; tratarea „echilibrării încărcării” ca proiect lasă calea de întoarcere și comportamentul la eșec nedefinite.

Un exemplu de produs documentat ajută aici. Documentația de replicare a Pritunl tratează rețeaua VPN ca un obiect pe replică, iar clienții de pe replici diferite au nevoie de rute și conectivitate suplimentare pentru a se atinge. Este o aranjare specifică produsului, nu o rețetă pentru Community OpenVPN, dar arată de ce adăugarea unei replici schimbă rețeaua și nu doar depozitul de conturi.

Ce este o sesiune: stare vie, nu un rând

Al treilea registru este sesiunea activă. Un client conectat are stare de protocol și o alocare de rețea pe nodul care l-a acceptat. Faptul că contul este cunoscut pe celălalt nod nu îi dă acelui nod sesiunea, cheile sau capacitatea de a continua pachetele.

Fiți explicit cu privire la ce se întâmplă când un nod eșuează. Rezultatul acceptat poate fi o reconectare la celălalt nod cu autentificare nouă și o adresă nouă, după care aplicația își revine în felul ei. Dacă se cere o predare fără întrerupere, acea cerință are nevoie de suport explicit în implementare, nu de o deducție din replicarea bazei de date. Scrieți răspunsul acolo unde inginerul de gardă îl poate găsi.

Regulile de capacitate au nevoie de același tratament. O limită de două sesiuni simultane pe cont poate fi impusă între noduri doar dacă o autoritate are o vedere coordonată a locurilor ocupate. Listele locale nodurilor și o evidență istorică a contului nu se adună într-o astfel de vedere.

Încercarea celor trei registre

Exersați fiecare separat. Conectați-vă prin nodul A, apoi prin nodul B, și confirmați că ambele reușesc cu intervalele de adrese așteptate. Retrageți o identitate și verificați ambele noduri, nu doar pe cel pe care l-ați testat din întâmplare. Apoi opriți un nod și observați ce fac de fapt clientul și aplicația privată.

Includeți calea de întoarcere în testul de acceptare. Un client care se conectează la B, dar nu poate primi răspunsuri de la o resursă din spatele lui A, a trecut verificarea de admitere și a eșuat pe cea de rețea, iar această distincție ar trebui să apară în raport.

Proiectul unui cont cu mai multe noduri este complet doar când toate cele trei registre au un proprietar explicit, o cale de schimbare și un comportament la eșec. Copierea unui fișier de configurare între noduri nu răspunde la niciuna dintre aceste întrebări.