Trasy statyczne czy protokół routingu przez VPN między lokalizacjami?

Oba warianty przenoszą pakiety między lokalizacjami, więc decyzja nie dotyczy tego, który protokół jest nowszy, a rozmiar tunelu też jej nie rozstrzyga. Rozstrzygają ją trzy warunki: ile prefiksów się zmienia i jak często, czy projekt potrzebuje automatycznego przełączania między ścieżkami, i ile mechanizmów warstwy sterowania zespół zdoła obsłużyć o trzeciej nad ranem. Odpowiedzcie na to szczerze, a wybór zwykle dokona się sam. Reszta tego tekstu to koszt każdej odpowiedzi.

Trzy warunki rozstrzygają

Pierwszym warunkiem jest zmienność. Kilka stabilnych podsieci z jasną własnością można latami utrzymywać ręcznie, a każda trasa pozostaje wierszem, który ktoś może przeczytać i sprawdzić. Dziesiątki prefiksów, które przemieszczają się wraz z przychodzeniem i odchodzeniem projektów, to inny problem, bo każde przeniesienie musi dotrzeć do każdego urządzenia, które wciąż pamięta starą ścieżkę.

Drugim jest zachowanie przy awarii. Kiedy ścieżka zapasowa musi stać się aktywna bez zauważenia przez człowieka, coś musi wykryć awarię i wycofać trasę. Routing statyczny potrafi to tylko przez śledzenie lub warunkową instalację, i tylko dla awarii, które wcześniej przewidziano.

Trzecim jest apetyt na drugą warstwę sterowania. Protokół routingu dodaje sesje, uwierzytelnianie, filtry i politykę wyboru, a każde z tego wymaga monitorowania i procesu zmian. To stały koszt operacyjny, a nie jednorazowe zadanie konfiguracyjne.

Tabela pod trzecim akapitem to wersja skrócona, a trzy sekcje po niej wyjaśniają, dlaczego każdy wiersz jest tam, gdzie jest. Przeczytajcie wiersze wobec własnej liczby lokalizacji przed wyborem, bo decyzja ignorująca koszt operacyjny to tylko połowa decyzji.

Ile naprawdę kosztuje routing statyczny

Trasa statyczna musi być poprawna po obu stronach tunelu. Dodanie podsieci oznacza edycję bramy zdalnej, bramy lokalnej i zwykle ścieżki powrotnej, a zapomnienie którejkolwiek z nich daje jednokierunkową awarię, która wygląda jak błąd aplikacji. Zespół aplikacji widzi przekroczenia czasu, a zespół sieci widzi trasę, która istnieje i wygląda na zdrową. Żaden z zespołów się nie myli, i dlatego ta awaria tak długo zajmuje miejsce.

Wpis statyczny pozostaje też zainstalowany po zniknięciu ścieżki pod nim. Jeśli platforma nie zapewnia śledzenia, trasa nadal wskazuje następny skok, który już nie przekazuje, a ruch znika zamiast się przełączyć. Ta cisza jest wydatkiem, który przyjmujecie, wybierając prostą opcję.

Zapiszcie metodę śledzenia obok każdej trasy, zanotujcie, które awarie obejmuje, i trzymajcie listę razem z konfiguracją tunelu. Inaczej następną przerwę odkryje użytkownik, a nie sieć, co zawsze jest droższym odkryciem.

Ile naprawdę kosztuje routing dynamiczny

Protokół ogłasza nowe prefiksy, wycofuje nieosiągalne i wyraża preferencję między ścieżkami. To naprawdę przydatne, gdy kilka lokalizacji lub nadmiarowych tuneli wymagałoby inaczej skoordynowanych zmian przy każdej zmianie. To także powód, dla którego protokół może zaskoczyć was w najgorszym momencie. Każde z tych działań to zmiana stanu, której nie dokonaliście osobiście.

Tworzy dwa stany, które mogą się nie zgadzać. Tunel może być podniesiony, gdy sesja routingu jest opuszczona, a sesja może być podniesiona, gdy jej ogłoszenia pomijają podsieć potrzebną aplikacji. Oba wyglądają jak sieć działająca w połowie, i żadnego nie widać ze strony stanu tunelu.

Filtry i polityka stają się więc częścią projektu, a nie późniejszą myślą. Protokół, który ogłasza wszystko, w końcu ogłosi coś błędnego, a błędny prefiks podróżuje szybciej niż osoba, która może go poprawić. Napiszcie filtry przed włączeniem pierwszej sesji, żeby pierwsze ogłoszenie było już świadome.

Kontrolujcie, co sesja routingu może mówić

Ustalcie dozwoloną listę prefiksów na peera i egzekwujcie ją na wejściu, bo filtr wychodzący nie może powstrzymać peera przed wysłaniem wam trasy domyślnej. Trasy domyślne i agregaty to tutaj drogie błędy: mogą po cichu zastąpić niepowiązane ścieżki jednym nauczonym wpisem, który wygląda legalnie. Odrzucajcie je wyraźnie, chyba że projekt naprawdę ich chce.

Zapiszcie lokalizację właściciela obok każdej sieci, zanim pierwsza sesja wstanie, bo to mapowanie jest źródłem listy filtrów, a nie ozdobą dokumentacji. Bez niego osoba edytująca filtr musi zgadywać, która lokalizacja powinna ogłaszać prefiks.

Redystrybucja między dwoma protokołami to miejsce, gdzie zaczynają się pętle i gdzie ten sam prefiks przychodzi dwa razy z atrybutami, których nie da się czysto porównać. Trzymajcie redystrybucję poza projektem, dopóki konkretny wymóg jej nie wymusi, a jeśli musi istnieć, oznaczcie i filtrujcie trasy na granicy.

Interfejsy tunelowe oparte na trasach ułatwiają przedstawienie routingu dynamicznego, bo tunel staje się interfejsem z trasami zamiast polityki dopasowującej selektory. To nie usuwa pytania o zakres peera: selektory IPsec nadal muszą pozwalać na ruch, który zamierzacie routować.

Testujcie ścieżkę awarii, nie ścieżkę szczęśliwą

Cokolwiek wybierzecie, wyłączcie jedno łącze górne i potwierdźcie, że ruch się przemieszcza albo że zawodzi tak, jak to opisaliście. Projekt testowany tylko z obiema zdrowymi ścieżkami to projekt, którego w ogóle nie testowano. Zmierzcie czas wykrycia, póki tam jesteście, bo zmierzona liczba to liczba, której doświadczą użytkownicy.

Następnie potwierdźcie niezależnie ścieżkę powrotną, bo asymetryczny routing przez VPN jest powszechny i niewidoczny, dopóki urządzenie stanowe nie odrzuci odpowiedzi. Przepływ działający w jednym kierunku dowodzi tylko połowy ścieżki.

Kolejność pracy: policzcie prefiksy, zdecydujcie, jak wykrywać awarie, sprawdźcie, kto może obsługiwać protokół, kontrolujcie, co jest ogłaszane, a potem przetestujcie jedną przerwę od początku do końca. Każdy krok daje fakt, którego potrzebuje następny.