Pływająca trasa zapasowa VPN nie przejmuje ruchu: lista kontrolna przełączenia

Pływające trasy statyczne czekają na kwalifikowalność, a nie na zatrzymanie pakietów. Sześć uporządkowanych kontroli ścieżki sondy, progów i powrotu w zapasie VPN.

Twoja pływająca trasa VPN jest skonfigurowana, odległość zapasu jest większa niż trasy podstawowej, a mimo to nic się nigdy nie przesuwa. Albo się przesuwa, a potem wraca po kilku minutach, gdy łącze bezprzewodowe wciąż jest wyłączone. W obu przypadkach o kwalifikowalności trasy decyduje coś innego niż awaria, która cię interesuje.

Wykonaj te kontrole po kolei. Każda ma warunek zatrzymania, a nieudanej kontroli nie uratują następne. Przykłady używają składni RouterOS, ponieważ odległość, osiągalność bramy i rekurencyjny następny skok są tam widoczne w konfiguracji, ale kolejność dotyczy każdego routera ze śledzonymi trasami statycznymi.

Nazwij awarię, którą zapas musi pokryć

„Trasa podstawowa nie działa” to cztery różne obserwacje. Radio, które traci partnera, interfejs, który traci nośnik, zdalna brama, która przestaje odpowiadać, i aplikacja, która przestaje działać, wyglądają różnie z miejsca routera. Zapisz, dla której z nich jest projekt, zanim ktoś zmieni wartość odległości.

Następnie sprawdź niezależność. Jeśli zewnętrzny transport VPN biegnie tą samą ścieżką bezprzewodową lub łączem dostępowym współdzielącym ten sam upstream, zapas nie jest drugą domeną awarii i będzie wyłączony dokładnie wtedy, gdy będzie potrzebny. Wyciągnij podstawowy kabel na papierze: jeśli transport samego tunelu ginie razem z nim, pływająca trasa pokrywa tylko błędy konfiguracji, a nie przerwy.

Przestań wymagać od odległości wykrywania czegokolwiek

Większa odległość czyni trasę mniej preferowaną. To cała praca. Dopóki podstawowa trasa statyczna pozostaje kwalifikowalna, pływająca trasa pozostaje nieaktywna, i jest to poprawne zachowanie, a nie błąd. Awaria staje się widoczna dopiero wtedy, gdy podstawowa trasa zostanie wycofana lub oznaczona jako nieosiągalna.

Dla tras statycznych wymaga to jawnego obserwatora:

/ip route
add dst-address=10.20.0.0/24 gateway=192.0.2.1 distance=1 check-gateway=ping
add dst-address=10.20.0.0/24 gateway=wg-backup distance=10

Przeczytaj, co to testuje: następny skok, a nie cel. Radio, które wciąż odpowiada po swojej lokalnej stronie, ale przekazywanie dalej jest zepsute, utrzymuje podstawową trasę aktywną. To jest cichy przypadek, a odległość plus kontrola bramy go nie złapią. Jeśli ten przypadek ma znaczenie, wykrywanie musi pochodzić od czegoś, co obserwuje drugą stronę: sąsiedztwa protokołu routingu lub sondy, której ścieżkę i regułę wyniku sam określiłeś.

Prześledź, dokąd trafiają pakiety samej sondy

Sonda kondycji też ma trasę. Gdy ruch danych przejdzie na VPN, nieograniczona sonda do tego samego zdalnego adresu może go śledzić, odnieść sukces i zostać odczytana jako dowód, że podstawowa trasa wróciła. Ruch wraca na zepsutą ścieżkę i cykl się powtarza.

Przypnij sondę do ścieżki, którą ma oceniać. W RouterOS zwykle stosuje się trasę hosta do celu monitoringu przez podstawową bramę, z zasięgiem na tyle małym, by żadna inna trasa nie mogła jej rozwiązać, i właśnie to buduje przykład rekurencyjnego przełączenia w podręczniku RouterOS. Potwierdź to w żywej tabeli przy aktywnym zapasie, a nie z komentarza w konfiguracji:

/ip route print detail where dst-address=203.0.113.10
# gateway should still be the primary next hop

Zdefiniuj, co oznacza wynik sondy, zanim dodasz cele

Jeden cel, który odrzuca ICMP lub przechodzi w tryb konserwacji, wygląda dokładnie jak awaria ścieżki, a trzy cele bez reguły dają tylko trzy opinie. Najpierw zdecyduj regułę, potem ją wdróż: na przykład podstawowa trasa liczy się jako wyłączona, gdy dwa z trzech celów zawiodą przez dwa kolejne interwały, zapisane w podręczniku operacyjnym, gdzie następna osoba to znajdzie.

Ustaw progi awarii i odzyskania tak, by jeden zgubiony pakiet nie przesuwał lokalizacji. Histereza kosztuje trochę czasu wykrywania i odkupuje stabilność. Wybierz interwał na podstawie tego, jak długo przerwa jest tolerowana, a nie jak szybko może działać sonda, i utrzymuj powrót wolniejszy niż przełączenie, aby podstawowa trasa musiała udowodnić siebie, zanim odzyska ruch.

Sprawdź ścieżkę powrotną i historię sesji

Przełączenie działające tylko na zewnątrz to połowa projektu. Zdalna lokalizacja potrzebuje trasy powrotnej do twojego zakresu źródłowego przez VPN, w przeciwnym razie ruch powrotny przychodzi z nieoczekiwanego adresu i trafia na stan zapory, który już nie pasuje. Istniejące sesje zerwą się nawet wtedy, gdy nowe połączenia działają, więc wpisz to do kryteriów akceptacji zamiast obiecywać przetrwanie transferu.

Trzymaj dostęp administracyjny poza testowaną ścieżką. Jeśli jedynym wejściem jest trasa podstawowa, test przełączenia zamyka cię poza urządzeniem, które zachowuje się źle.

Wykonaj sekwencję akceptacji

Trzy testy pokrywają większość terenu: fizyczna utrata podstawowej trasy, cicha awaria przekazywania przy wciąż podniesionym interfejsie i przywrócenie podstawowej trasy. Dla każdego zapisz źródło i następny skok sondy, aktywną trasę docelową oraz świeżą dozwoloną wymianę aplikacji w obu kierunkach.

Cichy przypadek jest tym, który rozdziela projekty. Jeśli zapas tam nie przejmie, zbudowałeś monitor łącza, a nie monitor ścieżki. Zdecyduj, czy to akceptowalne, i zapisz ograniczenie tam, gdzie inżynier dyżurny je przeczyta. Drugi podłączony tunel sam w sobie nie jest gotową polityką zapasową.

Powiązane artykuły