Jak zbudować politykę przełączania awaryjnego VPN na routerze bez wycieków

Przełączanie awaryjne zadziałało dokładnie tak, jak je skonfigurowano, i to był właśnie problem. Gdy tunel główny padł, router przeniósł trasę domyślną na modem kablowy, laptopy dalej przeglądały sieć i nikt nie zadzwonił. Dwa dni później ktoś zauważył, że udział finansowy był dostępny przez otwartą ścieżkę internetową przez sześć godzin. Polityka przełączania awaryjnego VPN na routerze nie jest sztuczką routingu; to decyzja o tym, co ma robić ruch, gdy preferowana ścieżka zniknie, a ta decyzja musi istnieć, zanim ścieżka zniknie.

Zdecyduj o wyniku, zanim wybierzesz detektor

Zwykle w grę wchodzą trzy wyniki: wysłanie dotkniętych klientów przez tunel zapasowy, pozwolenie im na zwykły WAN albo całkowita blokada. Zapisz, który z nich dotyczy której sieci VLAN, SSID lub klasy urządzeń. Jedna płaska reguła „przełącz na WAN” sprawiła, że wspomniany udział finansowy trafił na publiczną ścieżkę.

Te trzy nie są wymienne. Powrót do WAN utrzymuje działanie biura obsługi przy telefonach, ale wystawia nazwy wewnętrzne lokalnemu resolverowi. Tunel zapasowy zachowuje politykę, ale może wylądować na adresie wyjściowym, którego druga strona nie akceptuje. Blokada jest właściwa dla sieci VLAN z listą płac i niewłaściwa dla sieci gości, która nigdy nie korzystała z tunelu.

Dopasuj detektor do awarii, której naprawdę się boisz

Stan uzgadniania, stan interfejsu i działające przekazywanie to trzy różne sygnały, a dla użytkownika liczy się tylko ostatni. Peer WireGuard może pokazywać świeże uzgodnienie, podczas gdy sieć dostawcy wyrzuca pakiety. Klient OpenVPN może tkwić w stanie „połączony”, gdy trasa, którą wypchnął, przestała się rozwiązywać.

W pfSense praktycznym rozwiązaniem jest grupa bram zasilana przez dpinger, który sonduje adres monitorujący i oznacza bramę jako niedostępną, gdy utrata pakietów lub opóźnienie przekroczy progi. Skieruj ten monitor na coś poza tunelem, na przykład hosta w zdalnej sieci LAN albo publiczny adres osiągany przez tunel. Celowanie we własny adres peera tunelu mierzy tę część, o której już wiesz, że żyje.

Zbuduj grupę tak, aby zapas pozostał ostatecznością

Używaj poziomów, a nie jednej płaskiej listy członków. Główny na poziomie 1, tunel zapasowy na poziomie 2, WAN na poziomie 3 tylko dla sieci VLAN, których polityka na to pozwala. W pfSense znajduje się to w System > Routing > Gateway Groups: dodaj obie bramy, nadaj im różne poziomy, ustaw Trigger Level na niedostępność członka plus utratę pakietów, zapisz, a następnie zastosuj grupę jako domyślną interfejsu lub w polu Gateway reguł zapory, które jej potrzebują.

Dla instancji klienta OpenVPN w pfSense 2.5 i nowszych ustawienie Default Gateway instancji decyduje o tym, czy tunel w ogóle zastąpi systemową trasę domyślną. Routing według reguł zachowuje się tak, jak oczekujesz, tylko wtedy, gdy zakładana trasa jest rzeczywiście zainstalowana. Po zmianie sprawdź Status > Gateways, zamiast ufać ikonie stanu tunelu.

Dwa ustawienia powodują większość migotania. Jedno to interwał sondowania krótszy niż własna rekonwergencja dostawcy. Drugie to grupa, w której główny i zapasowy dzielą poziom, więc oba pozostają zawsze kwalifikowalne. Dodaj histerezę przez progi utraty i opóźnienia, zanim użytkownicy sami odczują przejścia.

Zamknij ścieżki, których tunel nigdy nie kontrolował

Najpierw wycieki DNS. Resolver nadal odpowiada w WAN i wysyła ruch na zewnątrz, więc nazwy nadal rozwiązują się przez ISP, podczas gdy ruch jest przypięty do tunelu. Ogranicz interfejsy wychodzące resolvera, wypchnij wewnętrzny resolver do klientów i zablokuj port 53 dla wszystkiego innego w sieciach VLAN tylko z VPN.

IPv6 wymaga własnej decyzji. Sieć LAN z podwójnym stosem może stracić tunel i zachować działającą globalną trasę domyślną IPv6, więc przeglądarki wolą IPv6 i wychodzą przez WAN, podczas gdy IPv4 wygląda na idealnie zamknięty. Albo kieruj IPv6 do tunelu, albo przestań rozgłaszać globalny prefiks, gdy tunel jest niedostępny. Połowa polityki jest gorsza niż brak polityki, bo wygląda, jakby działała.

Potem ścieżka powrotna. Jeśli wyjście zapasowe używa innego adresu źródłowego, druga strona musi wiedzieć, jak wysłać ruch z powrotem do niego, a każdy stan powiązany ze starym adresem już nie żyje. Sesje otwarte w chwili awarii głównego nie migrują; zawieszają się, aż wygasną i aplikacja zdecyduje, co z nimi zrobić.

Przetestuj awarię, migotanie i drogę powrotną

Odłącz główny przy nieszkodliwym ruchu, a potem odczytaj cztery rzeczy: Status > Gateways dla stanów członków grupy, pfctl -ss dla stanów wciąż przypiętych do starej bramy, traceroute z klienta dla ścieżki wyjściowej oraz zapytanie do resolvera, aby zobaczyć, który serwer odpowiedział.

Teraz wywołaj migotanie. Podnieś główny na trzydzieści sekund, opuść na trzydzieści, dwa razy. Jeśli ruch goni każdą zmianę, progi są zbyt ciasne albo poziomy są złe. Napraw to w swoim harmonogramie, bo inaczej dostawca zrobi to w swoim.

Na koniec potwierdź, że nadal możesz administrować routerem. Utrzymuj ścieżkę poza pasmem, taką jak kabel konsoli, sieć VLAN zarządzania lub modem komórkowy. Test przełączania awaryjnego, który cię odcina, jest testem, którego nie da się dokończyć, a nieosiągalny router nie wróci sam.

Zanim uznasz politykę za gotową, powinieneś odpowiedzieć na cztery pytania bez otwierania terminala: które sieci VLAN mogą używać WAN, gdy tunel jest niedostępny, co obserwuje detektor i jak długo czeka, które serwery nazw i trasy IPv6 przenoszą się wraz ze ścieżką oraz jak wrócisz, jeśli zapas też zawiedzie. Jeśli którakolwiek odpowiedź brzmi „cokolwiek było domyślne”, polityka nadal należy do routera, a nie do ciebie.