Jedan VPN nalog na dva servera: tri registra stanja

Jedan nalog koji se može prijaviti na bilo koji od dva VPN čvora otvara pitanje dizajna mnogo prije nego pitanje softvera. Pogled na nalog, mreža koju svaki čvor posjeduje i sesija koju drži povezani klijent tri su različite vrste stanja i otkazuju na različite načine kada ih kopirate unaokolo. Kopiranje sva tri u jedan sistem čest je način da izgubite jedno od njih.

Prođite kroz tri registra ispod po redu. Svaki pita šta je autoritativno, šta je lokalno i šta se dogodi kada drugog čvora nema, a odgovori ne slijede jedan iz drugog.

Ko se može povezati: jedan autoritet, mnogo čvorova

Počnite s registrom prijema: koji izvor identiteta je autoritativan, kojim izdavaocima certifikata se vjeruje, koji nalozi ispunjavaju uslove, koji drugi faktor se primjenjuje i do čega svaki nalog može doći. Zatim zapišite kako svaki čvor saznaje za promjene i koliko brzo.

Dijeljena baza podataka jedan je mogući dio tog odgovora. Ona nije dokaz da svaka relevantna politika živi tamo ili da svaki čvor primjenjuje promjenu u istom trenutku. Nalog onemogućen na čvoru A, ali još prihvaćen na čvoru B, znači da proces odjave nije završen.

Odlučite šta čvor radi kada je autoritet nedostupan. Prihvatanje keširanih vjerodajnica tokom ispada politički je izbor s cijenom za sigurnost, a njihovo odbacivanje politički je izbor s cijenom za dostupnost. Oba se mogu braniti; ostaviti to nedokumentovano ne može.

Držite autoritet izdavaoca odvojeno od podataka naloga. Nekoliko pristupnika može vjerovati istom CA bez držanja njegovog ključa za potpisivanje, a svaki čvor i dalje treba vlastiti certifikat servera i vlastiti odnos povjerenja na strani klijenta.

Šta čvor posjeduje: adrese i rute

Drugi registar lokalan je za svaki čvor: adresa slušanja, identitet servera, skup adresa, rute do privatnih resursa, politika razrješavanja i kako promet izlazi prema internetu. Isti nalog može posluživati bilo koji čvor dok ti objekti ostaju različiti.

Povratni put je dio koji se zaboravlja. Ako oba čvora dodjeljuju adrese iz istog skupa, privatna mreža ne može reći kojem čvoru pripada dati klijent i odgovor može biti poslan na pogrešno mjesto. Različiti skupovi također trebaju rute i dozvole, pa poseban raspon brojeva nije potpun dizajn.

Usmjeravajte klijente na čvor svjesno. Odabir DNS-a, liste krajnjih tačaka klijenta i prednji servis različiti su mehanizmi s različitim ponašanjem zdravlja i prebacivanja pri otkazu. Odabrati jedan je u redu; tretirati „balansiranje opterećenja“ kao dizajn ostavlja povratni put i ponašanje pri otkazu nedefiniranim.

Dokumentiran primjer proizvoda ovdje pomaže. Pritunlova dokumentacija o repliciranju tretira VPN mrežu kao objekt po replici, a klijenti na različitim replikama trebaju dodatne rute i povezanost da bi dosegli jedni druge. To je raspored svojstven proizvodu, a ne recept za Community OpenVPN, ali pokazuje zašto dodavanje replike mijenja mrežu, a ne samo spremište naloga.

Šta je sesija: živo stanje, a ne red

Treći registar je živa sesija. Povezani klijent ima stanje protokola i mrežnu dodjelu na čvoru koji ga je prihvatio. To što je nalog poznat na drugom čvoru ne daje tom čvoru sesiju, ključeve ni mogućnost da nastavi pakete.

Budite jasni o tome šta se događa kada čvor otkaže. Podržani ishod može biti ponovno povezivanje na drugi čvor sa svježom autentifikacijom i novom adresom, nakon čega se aplikacija oporavlja na svoj način. Ako je potrebno neprekidno prebacivanje, taj zahtjev traži izričitu podršku u implementaciji, a ne zaključak iz replikacije baze podataka. Zapišite odgovor tamo gdje ga inženjer u dežurstvu može naći.

Pravila kapaciteta trebaju isti tretman. Ograničenje od dvije istovremene sesije po nalogu može se provesti preko čvorova samo ako neki autoritet ima usklađen pogled na zauzeta mjesta. Liste lokalne za čvorove i historijski zapis naloga ne sabiraju se u takav pogled.

Testiranje tri registra

Vježbajte svaki zasebno. Prijavite se preko čvora A, zatim preko čvora B i potvrdite da oba uspijevaju s očekivanim rasponima adresa. Povucite identitet i provjerite oba čvora, ne samo onaj koji ste slučajno testirali. Zatim zaustavite jedan čvor i promatrajte šta klijent i privatna aplikacija zaista rade.

Uključite povratni put u prijemni test. Klijent koji se poveže na B, ali ne može primati odgovore od resursa iza A, prošao je provjeru prijema i pao na mrežnoj, a ta razlika treba da se pojavi u izvještaju.

Dizajn naloga za više čvorova potpun je samo kada sva tri registra imaju izričitog vlasnika, put promjene i ponašanje pri otkazu. Kopiranje konfiguracijske datoteke preko čvorova ne odgovara ni na jedno od tih pitanja.