Drugi punkt końcowy VPN: co obejmuje, a czego nie

Dwa punkty końcowe na papierze wyglądają jak nadmiarowość. W praktyce drugi adres pomaga tylko wtedy, gdy klienci mogą do niego dotrzeć i gdy pozwala uniknąć awarii, na którą się przygotowujesz. Dwa serwery za tym samym łączem dostępowym, tym samym kontem lub tą samą siecią docelową zawodzą razem. Użyteczne pytanie brzmi, którą pojedynczą awarię usuwa drugi punkt końcowy.

Porównaj, co oba punkty końcowe dzielą

Wypisz, co oba punkty końcowe mają wspólne, zanim policzysz, co duplikują. Lokalizacja hostingu, konto dostawcy, tranzyt nadrzędny, hosting DNS, źródło tożsamości i prywatny zasób za tunelem oznaczają zależność wspólną albo niezależną. Dwie maszyny wirtualne w jednym regionie dzielą awarię dostawcy. Dwa regiony pod jednym kontem nadal dzielą relację rozliczeniową i płaszczyznę sterowania, która je tworzy.

Sieć docelowa zasługuje na takie samo podejście. Zdrowa brama zapasowa nie przywróci NAS-a, który jest offline, ani nie dotrze do sieci biurowej, której łącze nadrzędne padło. Jeśli oba punkty końcowe kończą się w tej samej podsieci prywatnej, drugi dodaje tylko ścieżkę do celu, który już jest jedynym punktem awarii.

Tożsamość to zależność, o której się zapomina. Klonowanie certyfikatu i konfiguracji na drugi host tworzy dwa miejsca, w których można skopiować te same dane logowania, i nic nie mówi o tym, jak unieważnienia docierają do obu.

Zdecyduj, jak klient się przełącza

Drugi punkt końcowy jest użyteczny tylko wtedy, gdy klient o nim wie i może go wybrać bez telefonu do wsparcia. Profile połączenia OpenVPN mogą zawierać kilka wierszy remote z polityką wyboru, a większość klientów oferuje alternatywny profil w menu. Niezależnie od mechanizmu zapisz, który mają twoi użytkownicy, bo profil, którego nie potrafią znaleźć, nie jest przełączeniem awaryjnym.

Przeczytaj dokumentację klienta o zmianach adresu w trakcie sesji. Niektóre implementacje zachowują pierwotnego peera przez cały czas życia tunelu i sięgają po alternatywy dopiero przy ponownym połączeniu. Ta różnica decyduje, czy martwy punkt końcowy da krótką przerwę, czy sesję, która nigdy się nie podniesie. Przetestuj ścieżkę ponownego połączenia, zamiast zakładać, że zachodzi.

Zmieniony adres wyjścia psuje też stan aplikacji. Przełączenie awaryjne to odzyskiwanie, a opisywanie go jako nieprzerwanej ciągłości tworzy oczekiwanie, którego transport nie może spełnić.

Przetestuj jedną rzeczywistą awarię

Wybierz jedną kontrolowaną awarię i przeprowadź ją od początku do końca, zamiast ufać dokumentowi projektowemu. Zatrzymaj główny punkt końcowy, a następnie potwierdź, że uprawniony klient dociera do zamierzonej aplikacji przez alternatywę, podczas gdy nieuprawnieni klienci nadal nie mogą. Zapisz, ile trwało przełączenie i co zobaczyła aplikacja.

dig +short vpn2.example.net
ip route get 10.20.30.41
journalctl -u openvpn@backup --since '-10 min'

Pierwsze polecenie potwierdza, że nazwa zapasowa rozwiązuje się na coś trasowalnego, zanim będzie potrzebna, i to najtańszy test tutaj. Drugie pokazuje, którego interfejsu jądro użyłoby dla celu prywatnego, gdy alternatywa będzie podniesiona. Trzecie daje dziennik klienta z nazwą peera, z którym faktycznie się połączono, i to jedyny dowód, że przełączenie nastąpiło. Obserwuj też zachowanie blokowania w trakcie luki, bo polityka, która przy przełączaniu przepuszcza ruch, jest gorsza niż krótka przerwa.

Potem przywróć oryginał i potwierdź, czy klient wraca. Powrót, który zdarza się przypadkiem, to zachowanie, którego nikt nie zaplanował.

Zapisz, co daje drugi adres

Podsumuj pokrycie w jednym akapicie: którą awarię usuwa drugi punkt końcowy, które awarie dzieli z pierwszym i na jakich założeniach opiera się przełączenie. Wymień mechanizm po stronie klienta oraz prywatne trasy i zachowanie DNS, które muszą istnieć w obu miejscach. Publiczne wyjście do internetu nie zastępuje prywatnej bramy, a dokument, który traktuje je jako wymienne, zostanie uwierzony. Dodaj wykonany test odzyskiwania, z datą i wynikiem.

Niezależność od jednego serwera nie jest niezależnością od współdzielonego konta ani sieci docelowej. Właśnie akapit, który mówi to wprost, powstrzymuje sprzedawanie drugiego adresu wewnętrznie jako wysokiej dostępności. Mówi też następnemu operatorowi, co sprawdzić najpierw, gdy para zawiedzie razem.