Trzy rodzaje przełączania awaryjnego OpenVPN w pfSense, trzy mechanizmy

„OpenVPN failover” w pfSense obejmuje co najmniej trzy niepowiązane ze sobą rozwiązania, a każde z nich wymaga innego mechanizmu. Utrzymanie tunelu przy życiu przez zapasowe łącze internetowe, ponowne łączenie z innym serwerem i kierowanie ruchu LAN do innego już ustanowionego tunelu nie są wariantami jednej funkcji. Wybierz awarię, przed którą się bronisz, zanim zbudujesz grupę bram. Grupa, która naprawia jedną z nich, nie robi nic dla pozostałych dwóch.

Nazwij awarię, zanim zbudujesz grupę

Zapisz zdanie, które ma być prawdziwe podczas awarii. „Tunel łączy się ponownie przez zapasowy WAN” i „oddział nadal dociera do aplikacji przez drugi tunel” to różne zdania. Tylko pierwsze dotyczy transportu.

Potem dopasuj je do mechanizmu. Utrata lokalnego WAN to problem wyboru interfejsu, martwy zdalny punkt końcowy to problem listy połączeń, a bezużyteczna ścieżka wewnątrz ustanowionego tunelu to problem rutowania i polityki.

Lokalny WAN: przenieść transport

Dla klienta OpenVPN w pfSense obsługiwany układ wielu WAN wybiera odpowiednią grupę bram jako interfejs, do którego klient się wiąże. To właśnie pozwala połączeniu zewnętrznemu wyjść przez łącze zapasowe, gdy zawiedzie podstawowe. Samo w sobie nie zmienia sposobu rutowania ruchu wewnętrznego.

Strona serwera tego samego rozwiązania jest osobna. Serwer OpenVPN, który ma być osiągalny pod kilkoma publicznymi adresami, potrzebuje nasłuchu i polityki wejściowej dla każdego z tych wpisów, a nie tylko klienta potrafiącego dzwonić przez dwa łącza. Jeden działający publiczny wpis nie jest dowodem, że drugi jest skonfigurowany.

Reguła rutowania opartego na polityce dla przekazywanych pakietów LAN nie jest ustawieniem, które przenosi lokalnie utworzone połączenie transportowe VPN. To dwa różne wyszukiwania i zmiana jednego nie zmienia drugiego.

Zdalny punkt końcowy: inny serwer

Alternatywny remote to funkcja listy połączeń. Klient próbuje następnego wpisu, gdy bieżący nie odpowiada, co jest przydatne, gdy padł konkretny host, a nie gdy padło własne łącze dosyłowe. Obie awarie wyglądają podobnie z biurka użytkownika i wymagają różnych napraw.

Każdy kandydat musi być prawdziwym zamiennikiem: zgodne uwierzytelnianie, zgodna polityka klienta i dostęp do tych samych zasobów prywatnych. Druga nazwa hosta, która wskazuje na tę samą niesprawną infrastrukturę, nie jest zapasem. Serwer bez wymaganej trasy też nie, choćby jego uzgadnianie wyglądało zdrowo.

Ten mechanizm nie sprawia też, że dwa tunele przekazują ruch jednocześnie. Zastępuje jedno połączenie drugim, sekwencyjnie, a luka między nimi jest widoczna dla wszystkiego, co działało.

Ścieżka tunelu: wybrać inne wyjście

Gdy dwa tunele są już podniesione i ruch ma korzystać ze zdrowszego, mechanizmem jest przypisany interfejs VPN z własną bramą plus wyraźna reguła polityki, która wysyła do niego właściwy ruch. Grupa bram nad tymi przypisanymi interfejsami może wyrazić priorytet i monitorowanie.

To rozwiązanie dotyczy wyboru, nie odzyskiwania. Przenoszenie nowych połączeń do drugiego tunelu nic nie mówi o sesjach już ustanowionych na pierwszym ani o tym, czy druga strona zaakceptuje nowy adres źródłowy. Traktowanie tego jako mechanizmu odzyskiwania to sposób na zbyt wysokie oczekiwania.

Jeśli wymaganiem jest, aby istniejące sesje przetrwały, powiedz to wyraźnie. Większość implementacji nie migruje żywego przepływu między tunelami, a projektowanie tak, jakby to robiły, daje przełączanie, które wygląda poprawnie na schemacie, a w praktyce zrywa każde otwarte połączenie.

Monitory, NAT i reguła fail-closed

Monitor powinien sprawdzać coś, co tunel ma dostarczać. Cel, który odpowiada od partnera tunelu, ale nie z sieci aplikacji za nim, zgłosi stan zdrowy, podczas gdy użytkownicy nic nie widzą. Nieosiągalny cel diagnostyczny zgłosi stan martwy, podczas gdy ścieżka jest w porządku. Wybierz adres świadomie i potwierdź, że jest osiągalny tylko przez zamierzony tunel.

Sprawdź wychodzący NAT dla obu wyjść. Działające tłumaczenie na podstawowym nie opisuje adresu źródłowego zapasu, a zdalna sieć prywatna potrzebuje trasy powrotnej zgodnej z adresem źródłowym, który prezentujesz. Tłumaczenie poprawne na jednej ścieżce może być po cichu błędne na drugiej.

Potem zdecyduj, co dzieje się z ruchem, który nigdy nie może korzystać z WAN. pfSense ma zdefiniowane zachowanie dla reguł, których wybrana brama jest wyłączona, a późniejsza szeroka reguła przepuszczania lub trasa domyślna mogą zniweczyć twoją intencję. Zapisz zablokowany wynik jako wymaganie i zweryfikuj go, wyłączając ścieżkę.

Testuj utratę i odzyskiwanie osobno, ruchem, który wolno ci generować, i obserwuj trzy rzeczy naraz: WAN, który niesie połączenie zewnętrzne, tunel, który niesie żądanie aplikacji, i ścieżkę, którą obiera odpowiedź. Para zielonych wskaźników bramy nie jest jedną z tych trzech. Przewodnik Netgate po wielu WAN opisuje powiązanie transportu i eksportowane warianty klienta, na których to się opiera.