Jeden VPN účet na dvoch serveroch: tri registre stavu

Jeden účet, ktorý sa môže prihlásiť na ktorýkoľvek z dvoch uzlov VPN, otvára otázku dizajnu dávno pred otázkou softvéru. Pohľad na účet, sieť, ktorú vlastní každý uzol, a relácia, ktorú drží pripojený klient, sú tri rôzne druhy stavu a zlyhávajú rôzne, keď ich kopírujete sem a tam. Skopírovať všetky tri do jedného systému je bežný spôsob, ako o jeden z nich prísť.

Prejdite tri registre nižšie v poradí. Každý sa pýta, čo je autoritatívne, čo je lokálne a čo sa stane, keď druhý uzol nie je, a odpovede na seba nenadväzujú.

Kto sa smie pripojiť: jedna autorita, mnoho uzlov

Začnite registrom prijímania: ktorý zdroj identity je autoritatívny, ktorým vydavateľom certifikátov sa verí, ktoré účty sú spôsobilé, ktorý druhý faktor platí a kam až každý účet dosiahne. Potom zapíšte, ako sa každý uzol dozvedá o zmenách a ako rýchlo.

Zdieľaná databáza je jednou z možných súčastí tejto odpovede. Nie je dôkazom, že v nej žije každá relevantná politika alebo že každý uzol použije zmenu v rovnakom okamihu. Účet deaktivovaný na uzle A, ale stále prijímaný na uzle B, znamená, že proces odchodu nie je dokončený.

Rozhodnite, čo uzol urobí, keď je autorita nedostupná. Prijímať počas výpadku uložené prihlasovacie údaje je politické rozhodnutie s cenou za bezpečnosť a odmietať ich je politické rozhodnutie s cenou za dostupnosť. Oboje je obhájiteľné; nechať to nedokumentované nie je.

Držte autoritu vydavateľa oddelene od údajov účtu. Niekoľko brán môže dôverovať tej istej CA bez toho, aby držali jej podpisový kľúč, a každý uzol napriek tomu potrebuje vlastný serverový certifikát a vlastný vzťah dôvery na strane klienta.

Čo uzol vlastní: adresy a trasy

Druhý register je lokálny pre každý uzol: adresa počúvania, identita servera, fond adries, trasy k privátnym prostriedkom, politika prekladača a ako premávka odchádza k internetu. Ten istý účet môže obsluhovať ktorýkoľvek uzol, zatiaľ čo tieto objekty zostávajú odlišné.

Spätná cesta je časť, na ktorú sa zabúda. Ak oba uzly prideľujú adresy z toho istého fondu, privátna sieť nemôže určiť, ktorému uzlu daný klient patrí, a odpoveď môže byť odoslaná na nesprávne miesto. Rôzne fondy tiež potrebujú trasy a oprávnenia, takže odlišný rozsah čísel nie je úplný návrh.

Nasmerujte klientov k uzlu zámerne. Voľba DNS, zoznamy koncových bodov klienta a front-endová služba sú rôzne mechanizmy s rôznym správaním pri zdraví a pri zlyhaní. Vybrať jeden je v poriadku; považovať „vyvažovanie záťaže“ za návrh necháva spätnú cestu a správanie pri zlyhaní nedefinované.

Zdokumentovaný príklad produktu tu pomáha. Dokumentácia replikácie Pritunl berie sieť VPN ako objekt pre každú repliku a klienti na rôznych replikách potrebujú ďalšie trasy a konektivitu, aby sa navzájom dostihli. To je usporiadanie špecifické pre produkt, nie recept pre Community OpenVPN, ale ukazuje, prečo pridanie repliky mení sieť, a nie len úložisko účtov.

Čo je relácia: živý stav, nie riadok

Tretí register je živá relácia. Pripojený klient má stav protokolu a sieťové pridelenie na uzle, ktorý ho prijal. To, že je účet známy na druhom uzle, tomu uzlu nedáva reláciu, kľúče ani schopnosť pokračovať v paketoch.

Buďte výslovne konkrétni, čo sa stane, keď uzol zlyhá. Podporovaným výsledkom môže byť opätovné pripojenie k druhému uzlu s novým overením a novou adresou, načo sa aplikácia zotaví po svojom. Ak sa vyžaduje neprerušované odovzdanie, táto požiadavka potrebuje výslovnú podporu v implementácii, nie odvodenie z replikácie databázy. Zapíšte odpoveď tam, kde ju službukonajúci inžinier nájde.

Pravidlá kapacity potrebujú rovnaké zaobchádzanie. Limit dvoch súčasných relácií na účet možno medzi uzlami vynútiť len vtedy, ak má nejaká autorita koordinovaný pohľad na obsadené miesta. Zoznamy lokálne pre uzly a historický záznam účtu sa do takého pohľadu nesčítavajú.

Precvičenie troch registrov

Precvičte každý zvlášť. Prihláste sa cez uzol A, potom cez uzol B a potvrďte, že oba uspejú s očakávanými rozsahmi adries. Odoberte identitu a skontrolujte oba uzly, nie len ten, ktorý ste náhodou testovali. Potom zastavte jeden uzol a sledujte, čo klient a privátna aplikácia skutočne robia.

Zahrňte spätnú cestu do akceptačného testu. Klient, ktorý sa pripojí k B, ale nemôže prijímať odpovede od prostriedku za A, prešiel kontrolou prijímania a zlyhal v sieťovej, a tento rozdiel by sa mal objaviť v správe.

Návrh účtu pre viac uzlov je úplný len vtedy, keď všetky tri registre majú výslovného vlastníka, cestu zmeny a správanie pri zlyhaní. Kopírovanie konfiguračného súboru medzi uzlami neodpovedá na žiadnu z týchto otázok.