Pritunl: stan kontrolny versus wygenerowany profil

Jedno archiwum przywraca działające wdrożenie Pritunl; drugie przywraca tylko jego obraz. Profil klienta, kopia konfiguracji hosta i tarball katalogu stanu wyglądają jak kopie zapasowe, a żadne z nich samo nie przywraca organizacji, użytkowników i definicji serwerów, którymi zarządza Pritunl. Różnica tkwi we własności: część stanu należy do bazy danych, część do hosta, a część to ponownie wygenerowane wyjście. Wybierz niewłaściwą warstwę, a przywracanie da serwer, który startuje, nasłuchuje i nic nie wie. To porównanie rozdziela trzy warstwy, aby archiwum, które zachowujesz, pasowało do awarii, z której się podnosisz.

Dwa obiekty wyglądają jak kopie zapasowe i tylko jeden przywraca usługę

Pobrany profil klienta zawiera certyfikat, klucz i punkt końcowy. Jest kompletny dla tego jednego urządzenia i bezużyteczny jako zapis wdrożenia: nie niesie organizacji, wyłączonych użytkowników, tras serwerów ani kont administracyjnych. Przywracanie z folderu profili daje klientów, którzy nie mogą uwierzytelnić się wobec niczego.

Kopia konfiguracji hosta jest równie częściowa. /etc/pritunl.conf zawiera ustawienia na poziomie hosta, w tym sposób dotarcia do bazy danych, i nie zawiera samych obiektów VPN.

Co należy do bazy danych, a co do hosta

Pritunl przechowuje definicje serwerów, użytkowników, organizacje i klucze w MongoDB. Ta baza danych jest autorytatywną płaszczyzną kontroli, a każdy wygenerowany plik OpenVPN na dysku jest z niej wyprowadzonym wyjściem. Zmiana wprowadzona bezpośrednio w wygenerowanym pliku przetrwa do następnej regeneracji, a potem zniknie, dlatego edytowanie plików czasu wykonania nie jest trwałą poprawką. Ta sama zasada dotyczy efektywnych tras i interfejsów: opisują one to, co wytworzyła płaszczyzna kontroli, a nie to, co powinna wytworzyć.

Host wnosi mniejszy, ale nieprzenośny zestaw wartości. Jedną z nich jest /var/lib/pritunl/pritunl.uuid, tożsamość tego konkretnego węzła.

Ta tożsamość ma największe znaczenie w klastrze. Host zastępczy potrzebuje własnej rejestracji, a nie klonu UUID aktywnego węzła, inaczej oba walczą o tę samą tożsamość. Zapisuj mapowanie między każdym hostem, jego UUID i bazą danych, na którą wskazuje, ponieważ pojedynczy zrzut bazy danych nie opisuje, jakie ustawienia hosta należały do której maszyny. Wersje oprogramowania i publiczne nazwy punktów końcowych należą do tego samego rekordu.

Zrób spójny zrzut, a nie kopię katalogu

Kopiowanie katalogu danych MongoDB podczas zapisu przez usługę tworzy pliki, które mogą nie tworzyć użytecznej bazy danych. Użyj zamiast tego obsługiwanej ścieżki zrzutu bazy danych, uruchomionej wobec topologii, którą faktycznie masz:

mongodump --uri="mongodb://127.0.0.1:27017/pritunl" --out=/var/backups/pritunl/db
sudo tar czf /var/backups/pritunl/host.tgz /etc/pritunl.conf /var/lib/pritunl/pritunl.uuid

Samodzielny host toleruje tę prostą formę. Zestaw replik potrzebuje spójnego punktu w czasie, a zrzut oparty na oplogu ma wymagania, których zwykły zrzut nie ma. Obsługiwana procedura zależy od twojej wersji i topologii MongoDB, więc nie wywnioskuj jej z obecności katalogu danych. Archiwizuj warstwę hosta obok zrzutu, w tym samym przebiegu, z tym samym znacznikiem czasu.

Przećwicz przywracanie, zanim będzie potrzebne

Kopia zapasowa, której nikt nie przywrócił, jest hipotezą. Zbuduj usługę w izolowanej sieci, przywróć zrzut i odłóż pliki hosta z powrotem:

mongorestore --uri="mongodb://127.0.0.1:27017" --drop /var/backups/pritunl/db
sudo tar xzf /var/backups/pritunl/host.tgz -C /

Następnie zweryfikuj obiekty, a nie proces: zaloguj się, potwierdź, że organizacje i użytkownicy istnieją, i uruchom jednego klienta testowego wobec rozpoznanej definicji serwera. Nie pozwól przywróconemu hostowi ogłaszać produkcyjnego punktu końcowego ani przyjmować rzeczywistych połączeń, dopóki adresy i tożsamości nie będą zamierzone. Tu też odkrywasz, że archiwum potrzebuje poświadczeń, które żyły tylko na uszkodzonej maszynie, więc przechowuj poświadczenia odzyskiwania w niezależnym miejscu. Przywracanie, które zależy od hosta, który właśnie utraciłeś, nie jest planem przywracania.

Na koniec pamiętaj, że stary snapshot przywraca stare decyzje. Jeśli administrator wyłączył tożsamość po wykonaniu zrzutu, przywracanie włącza ją ponownie. Uzgodnienie po odzyskaniu należy do procedury, a nie do doraźnej refleksji.