Jeden účet VPN na dvou serverech: tři evidence stavu

Jeden účet, který se může přihlásit ke kterémukoli ze dvou uzlů VPN, otevírá otázku návrhu dávno před otázkou softwaru. Pohled na účet, síť, kterou každý uzel vlastní, a relace, kterou drží připojený klient, jsou tři různé druhy stavu a selhávají různě, když je kopírujete sem a tam. Zkopírovat všechny tři do jednoho systému je běžný způsob, jak o jeden z nich přijít.

Projděte tři evidence níže v pořadí. Každá se ptá, co je autoritativní, co je místní a co se stane, když druhý uzel není, a odpovědi na sebe nenavazují.

Kdo se smí připojit: jedna autorita, mnoho uzlů

Začněte evidencí přijímání: který zdroj identity je autoritativní, kterým vydavatelům certifikátů se věří, které účty jsou způsobilé, který druhý faktor platí a kam až každý účet dosáhne. Pak zapište, jak se každý uzel dozvídá o změnách a jak rychle.

Sdílená databáze je jednou z možných součástí této odpovědi. Není důkazem, že v ní žije každá relevantní politika nebo že každý uzel použije změnu ve stejný okamžik. Účet deaktivovaný na uzlu A, ale stále přijímaný na uzlu B, znamená, že proces odchodu není dokončen.

Rozhodněte, co uzel udělá, když je autorita nedostupná. Přijímat během výpadku uložené přihlašovací údaje je politické rozhodnutí s cenou za bezpečnost a odmítat je je politické rozhodnutí s cenou za dostupnost. Obojí je obhajitelné; nechat to nedokumentované není.

Držte autoritu vydavatele odděleně od dat účtu. Několik bran může důvěřovat stejné CA, aniž by držely její podpisový klíč, a každý uzel přesto potřebuje vlastní serverový certifikát a vlastní vztah důvěry na straně klienta.

Co uzel vlastní: adresy a trasy

Druhá evidence je místní pro každý uzel: adresa naslouchání, identita serveru, fond adres, trasy k privátním prostředkům, politika překladače a jak provoz odchází k internetu. Stejný účet může obsluhovat kterýkoli uzel, zatímco tyto objekty zůstávají odlišné.

Zpáteční cesta je část, na kterou se zapomíná. Pokud oba uzly přidělují adresy ze stejného fondu, privátní síť nemůže určit, kterému uzlu daný klient patří, a odpověď může být odeslána na špatné místo. Různé fondy také potřebují trasy a oprávnění, takže odlišný rozsah čísel není úplný návrh.

Nasměrujte klienty k uzlu záměrně. Volba DNS, seznamy koncových bodů klienta a front-endová služba jsou různé mechanismy s různým chováním při zdraví a při selhání. Vybrat jeden je v pořádku; považovat „vyvažování zátěže“ za návrh nechává zpáteční cestu a chování při selhání nedefinované.

Zdokumentovaný příklad produktu zde pomáhá. Dokumentace replikace Pritunl bere síť VPN jako objekt pro každou repliku a klienti na různých replikách potřebují další trasy a konektivitu, aby se navzájem dostihli. To je uspořádání specifické pro produkt, ne recept pro Community OpenVPN, ale ukazuje, proč přidání repliky mění síť, a ne jen úložiště účtů.

Co je relace: živý stav, ne řádek

Třetí evidence je živá relace. Připojený klient má stav protokolu a síťové přidělení na uzlu, který ho přijal. To, že je účet znám na druhém uzlu, tomu uzlu nedává relaci, klíče ani schopnost pokračovat v paketech.

Buďte výslovně konkrétní, co se stane, když uzel selže. Podporovaným výsledkem může být opětovné připojení k druhému uzlu s novým ověřením a novou adresou, načež se aplikace zotaví po svém. Pokud je vyžadováno nepřerušované předání, tento požadavek potřebuje výslovnou podporu v implementaci, ne odvození z replikace databáze. Zapište odpověď tam, kde ji službukonající inženýr najde.

Pravidla kapacity potřebují stejné zacházení. Limit dvou současných relací na účet lze mezi uzly vynutit jen tehdy, má-li nějaká autorita koordinovaný pohled na obsazená místa. Seznamy místní pro uzly a historický záznam účtu se v takový pohled nesčítají.

Testování tří evidencí

Procvičte každou zvlášť. Přihlaste se přes uzel A, pak přes uzel B a potvrďte, že oba uspějí s očekávanými rozsahy adres. Odeberte identitu a zkontrolujte oba uzly, ne jen ten, který jste náhodou testovali. Potom zastavte jeden uzel a sledujte, co klient a privátní aplikace skutečně dělají.

Zahrňte zpáteční cestu do akceptačního testu. Klient, který se připojí k B, ale nemůže přijímat odpovědi od prostředku za A, prošel kontrolou přijímání a selhal v síťové, a tento rozdíl by se měl objevit ve zprávě.

Návrh účtu pro více uzlů je úplný jen tehdy, když všechny tři evidence mají výslovného vlastníka, cestu změny a chování při selhání. Kopírování konfiguračního souboru mezi uzly neodpovídá na žádnou z těchto otázek.