Jedno konto VPN na dwóch serwerach: trzy rejestry stanu

Jedno konto, które może się zalogować do dowolnego z dwóch węzłów VPN, stawia pytanie projektowe znacznie wcześniej, niż staje się pytaniem o oprogramowanie. Widok konta, sieć, którą posiada każdy węzeł, i sesja trzymana przez podłączonego klienta to trzy różne rodzaje stanu, i zawodzą na różne sposoby, gdy się je kopiuje. Kopiowanie wszystkich trzech do jednego systemu to częsty sposób utraty jednego z nich.

Przejdź przez trzy poniższe rejestry po kolei. Każdy pyta, co jest autorytatywne, co jest lokalne i co się dzieje, gdy drugiego węzła nie ma, a odpowiedzi nie wynikają jedna z drugiej.

Kto może się połączyć: jedna władza, wiele węzłów

Zacznij od rejestru dopuszczania: które źródło tożsamości jest autorytatywne, którym wystawcom certyfikatów się ufa, które konta są uprawnione, który drugi czynnik obowiązuje i do czego każde konto może dotrzeć. Następnie zapisz, jak każdy węzeł dowiaduje się o zmianach i jak szybko.

Wspólna baza danych to jeden z możliwych elementów tej odpowiedzi. Nie jest dowodem, że każda istotna polityka mieszka właśnie tam albo że każdy węzeł stosuje zmianę w tej samej chwili. Konto wyłączone w węźle A, ale nadal akceptowane w węźle B, oznacza, że proces odchodzenia nie został zakończony.

Zdecyduj, co robi węzeł, gdy władza jest nieosiągalna. Akceptowanie buforowanych danych logowania podczas awarii to wybór polityki z kosztem bezpieczeństwa, a ich odrzucanie to wybór polityki z kosztem dostępności. Oba są obronne; pozostawienie tego bez dokumentacji nie jest.

Trzymaj władzę wystawcy osobno od danych konta. Wiele bram może ufać temu samemu CA bez posiadania jego klucza podpisującego, a każdy węzeł nadal potrzebuje własnego certyfikatu serwera i własnej relacji zaufania po stronie klienta.

Co posiada węzeł: adresy i trasy

Drugi rejestr jest lokalny dla każdego węzła: adres nasłuchu, tożsamość serwera, pula adresów, trasy do prywatnych zasobów, polityka resolvera i sposób, w jaki ruch wychodzi do internetu. To samo konto może być obsługiwane przez każdy z dwóch węzłów, podczas gdy te obiekty pozostają odrębne.

Droga powrotna to część, o której się zapomina. Jeśli oba węzły rozdają adresy z tej samej puli, sieć prywatna nie może powiedzieć, do którego węzła należy dany klient, a odpowiedź może trafić w złe miejsce. Różne pule też potrzebują tras i uprawnień, więc odrębny zakres numerów nie jest kompletnym projektem.

Kieruj klientów do węzła świadomie. Wybór DNS, listy punktów końcowych klienta i usługa front-endu to różne mechanizmy o odmiennym zachowaniu przy sprawdzaniu zdrowia i przełączaniu awaryjnym. Wybór jednego jest w porządku; traktowanie „równoważenia obciążenia“ jako projektu pozostawia drogę powrotną i zachowanie przy awarii niezdefiniowane.

Udokumentowany przykład produktu pomaga. Dokumentacja replikacji Pritunl traktuje sieć VPN jako obiekt na replikę, a klienci na różnych replikach potrzebują dodatkowych tras i łączności, aby się nawzajem osiągnąć. To układ specyficzny dla produktu, nie przepis dla Community OpenVPN, ale pokazuje, dlaczego dodanie repliki zmienia sieć, a nie tylko magazyn kont.

Czym jest sesja: żywy stan, nie wiersz

Trzeci rejestr to aktywna sesja. Podłączony klient ma stan protokołu i przydział sieciowy w węźle, który go zaakceptował. To, że konto jest znane w drugim węźle, nie daje temu węzłowi sesji, kluczy ani możliwości kontynuowania pakietów.

Bądź wyraźny co do tego, co się dzieje, gdy węzeł zawiedzie. Obsługiwanym wynikiem może być ponowne połączenie z drugim węzłem z nowym uwierzytelnieniem i nowym adresem, po czym aplikacja odzyskuje sprawność na swój sposób. Jeśli wymagane jest nieprzerwane przekazanie, to wymaganie potrzebuje wyraźnego wsparcia w implementacji, a nie wniosku z replikacji bazy danych. Zapisz odpowiedź tam, gdzie inżynier dyżurny ją znajdzie.

Reguły pojemności wymagają takiego samego podejścia. Limit dwóch jednoczesnych sesji na konto można egzekwować między węzłami tylko wtedy, gdy jakaś władza ma spójny obraz zajętych miejsc. Lokalne listy węzłów i historyczny zapis konta nie sumują się do takiego obrazu.

Wypróbowanie trzech rejestrów

Przećwicz każdy osobno. Zaloguj się przez węzeł A, potem przez węzeł B, i potwierdź, że oba się udają z oczekiwanymi zakresami adresów. Wycofaj tożsamość i sprawdź oba węzły, nie tylko ten, który przypadkiem testowałeś. Następnie zatrzymaj jeden węzeł i obserwuj, co faktycznie robią klient i aplikacja prywatna.

Uwzględnij drogę powrotną w teście akceptacyjnym. Klient, który łączy się z B, ale nie może odbierać odpowiedzi z zasobu za A, przeszedł kontrolę dopuszczania i oblał kontrolę sieci, a ta różnica powinna pojawić się w raporcie.

Projekt konta wielowęzłowego jest kompletny tylko wtedy, gdy wszystkie trzy rejestry mają wyraźnego właściciela, ścieżkę zmiany i zachowanie przy awarii. Kopiowanie pliku konfiguracji między węzłami nie odpowiada na żadne z tych pytań.