Dwa aktywne tunele IPsec nadal wymagają planu drogi powrotnej

Otwórz terminal na stacji roboczej w jednej lokalizacji i połącz się z serwerem w drugiej. Ta jedna rozmowa TCP musi teraz przejść przez cztery bramy zamiast dwóch, a ciekawe nie jest to, czy działa w dobry dzień. Ciekawe jest to, którą parę bram wybrał kierunek wyjściowy, którą parę wybiera odpowiedź i kto trzyma stan przepływu, gdy to się dzieje. Nic w tablicy routingu tego za ciebie nie decyduje.

Narysuj cztery bramy, zanim narysujesz trasę

Podwójnie aktywny projekt z dwiema niezależnymi zaporami VPN na lokalizację, jedna para na dostawcę, daje dwie użyteczne ścieżki i trzy sposoby na ich zepsucie. Zapisz adresy, zanim cokolwiek skonfigurujesz: klienta tak, jak widać go przed każdą bramą i po niej, serwer tak samo, następny skok w wyjściu i następny skok w powrocie.

Ta tablica to projekt. Wszystko po niej to pytanie, czy urządzenia zgadzają się z tablicą.

Jak wybierana jest droga wyjściowa

Warstwa routingu wielościeżkowego o równym koszcie rozdziela przepływy na kolejne skoki, haszując pola nagłówka, co RFC 2992 opisuje szczegółowo. Ten wybór może być całkowicie bezstanowy: nie potrzebuje wpisu śledzenia połączeń, tylko stabilnego hasza po niezmienionych polach. Utrzymuj zbiór ścieżek i wejścia hasza na stałym poziomie, a każdy pakiet przepływu wybierze ten sam następny skok.

Wybór na przepływ unika przestawiania, które powodowałoby równoważenie pakiet po pakiecie na łączach o różnych opóźnieniach. Nie obiecuje, że równy koszt routingu oznacza równy zmierzony czas opóźnienia, bo tak nie jest. A gdy zmienia się skład ścieżek, przepływy są mapowane ponownie, więc przetrwanie połączenia podczas awarii jest osobnym wymaganiem od wyboru ścieżki.

Czego naprawdę potrzebuje droga powrotna

Tutaj wędrówka przestaje być symetryczna. Stabilny hasz wyjściowy nie mówi nic o tym, co zrobi z odpowiedzią zdalna lokalizacja. Jeśli niezależna zapora musi widzieć oba kierunki połączenia, aby utrzymać użyteczny stan, trasa powrotna, która ją omija, zostawia ruch niepasujący do niczego. Dwa pudła z podobnymi zestawami reguł to nie wspólny stan.

Potwierdź wdrożone zachowanie dwukierunkowe albo napisz jawną politykę, która utrzymuje wymagane granice spójnymi. Domysł tutaj wychodzi na jaw podczas awarii, przez ludzi, którym to nie sprawia przyjemności.

Gdzie tłumaczenie decyduje za ciebie

NAT to druga dźwignia i jest opcjonalny, a nie obowiązkowy. Tożsamości tłumaczone specyficzne dla ścieżki mogą kierować odpowiedzi z powrotem do bramy trzymającej stan, co jest uzasadnionym projektem. Dodają jednak mapowania, trasy powrotne i właściciela tego stanu, więc przyjmij obciążenie tylko dla wymagania, które potrafisz wypowiedzieć na głos.

Jeśli wymaganiem jest po prostu to, że obie ścieżki niosą ruch i każda z nich przetrwa utratę dostawcy, zwykły wielościeżkowy przepływ ze spójnym routingiem powrotnym jest zwykle mniejszym projektem.

Przejdź odbiór po kolei

Testuj w tej kolejności i zapisuj adresy na każdym kroku: nowe połączenie na ścieżce A i jego droga odpowiedzi, to samo na ścieżce B, potem utrata jednego dostawcy, potem przywrócenie. Dla każdego wyniku zanotuj, które ustalone przepływy się przesunęły, które musiały połączyć się ponownie i dokąd potem poszły nowe przepływy. Najpierw zapisz oczekiwaną wartość, a potem porównaj ją z przechwyceniem. Dwa ustalone tunele niczego z tego nie dowodzą.

Projekt jest gotowy, gdy napisana przez ciebie tablica zgadza się z tym, co pokazuje przechwycenie, a nie gdy oba tunele są podniesione.