Tunel stoi, trasa zniknęła: rozdzielenie dwóch awarii VPN

Jeden host staje się nieosiągalny, choć interfejs tunelu nadal zgłasza się jako ustanowiony, a te dwa spostrzeżenia nie są sprzeczne. Coś usunęło ścieżkę, której używał ruch: sąsiad wycofał swój prefiks, śledzona trasa statyczna została usunięta albo inna trasa stała się preferowana. Asocjacja bezpieczeństwa może pozostać całkowicie zdrowa we wszystkich trzech przypadkach. Rozdzielenie zdarzeń oznacza pytanie, która warstwa zmieniła się pierwsza, a nie czy VPN zawiódł.

Trzy etapy, które wyglądają jak jedno zdarzenie

Decyzja o routingu ma trzy etapy. Prefiks jest odbierany, wybierany jako najlepszy i instalowany w tablicy przekazywania. Każdy etap może zawieść samodzielnie, a awaria wygląda identycznie od strony aplikacji. Nauczony, ale przegrany w wyborze prefiks jest nieodróżnialny od tego, który nigdy nie dotarł, gdy jedynym dowodem, na który patrzysz, jest tablica przekazywania.

Dlatego pierwsze pytanie dotyczy tego, który etap się zepsuł, a nie który protokół jest winny. Odpowiedź decyduje, do kogo należy incydent i jakiego narzędzia użyje następne sprawdzenie.

Najpierw przeczytaj zainstalowaną trasę

Zapytaj jądro, dokąd naprawdę idzie ruch do niedziałającego celu. ip route get wypisuje następny skok, interfejs i adres źródłowy, którego użyłoby jądro, i odpowiada dla jednego celu, a nie dla całej tablicy. Jeśli odpowiedź wskazuje tunel, tablica przekazywania nadal wierzy, że ścieżka istnieje, a problem leży wyżej.

ip route get 10.20.5.10
ip route show 10.20.0.0/16

Odpowiedź «unreachable» oznacza, że nie ma żadnej zainstalowanej trasy, co wskazuje na wycofanie lub brakującą instalację. Odpowiedź wskazująca interfejs fizyczny oznacza, że ruch opuścił tunel, choć nikt tego nie zdecydował, a następnym sprawdzeniem jest preferencja, która wygrała. Natomiast odpowiedź wskazująca tunel, gdy pakiety nadal znikają, wskazuje dalej na ścieżce, na filtrowanie lub na drugą stronę.

Potem spójrz na własny widok protokołu

Demon routingu utrzymuje więcej niż jedną tablicę, a ciekawe porównanie jest między nimi. Dla BGP stan sesji sąsiada, otrzymane ogłoszenie i zainstalowana trasa to trzy odrębne dowody. Prefiks może siedzieć w odebranej tablicy i nigdy nie dotrzeć do jądra, bo wygrywa trasa o krótszym dystansie administracyjnym. Sprawdź wszystkie trzy, zanim uznasz, że druga strona przestała ogłaszać.

vtysh -c "show bgp summary"
vtysh -c "show bgp ipv4 unicast 10.20.0.0/16"

Podsumowanie mówi, czy sesja jest ustanowiona, widok według prefiksu mówi, czy prefiks został zaakceptowany, a wyszukiwanie w jądrze mówi, czy został zainstalowany. Czytanie ich w tej kolejności nie pozwala pomylić drgania sesji z wycofaniem, a wycofania z odrzuceniem przez politykę.

Gdy zegary się nie zgadzają

Umieść dziennik tunelu, dziennik routingu i pierwszą awarię aplikacji na jednej osi czasu, używając ich rzeczywistych stref czasowych. Jeśli utrata sąsiada przychodzi pierwsza, tunel ściągnął trasę razem ze sobą. Jeśli pierwsze jest wycofanie, routing się zmienił, a tunel zareagował później. To różne incydenty z różnymi właścicielami, a kolejność jest całym ustaleniem.

Jedna minuta odchylenia zegara wystarczy, by odwrócić ten wniosek, więc potwierdź strefę czasową i przesunięcie, zanim zaufasz kolejności. Urządzenia, które logują w czasie lokalnym bez przesunięcia, są zwykłym źródłem pewnej siebie, ale błędnej osi czasu.

Odzyskiwanie bez pętli

Po wycofaniu dwie ścieżki mogą być odpowiednie: ta, którą wybiera protokół, i ta, którą przypinasz ręcznie. Tylko pierwsza jest decyzją, którą sieć nadal podejmuje za ciebie, dlatego ręczna trasa jest doraźnym rozwiązaniem, a nie planem odzyskiwania. Ogłoszenie zapasowe nie zachowuje też stanu zapory ani NAT dla sesji, która już jest ustanowiona, więc nowe przepływy mogą działać, gdy pierwotny pozostaje zepsuty. Potwierdź, która kopia zapasowa powinna stać się aktywna i czy zdalna lokalizacja zaakceptuje drogę powrotną przez nią.

Nie instaluj trwałego statycznego nadpisania, zanim zrozumiesz, dlaczego doszło do wycofania. Ten skrót może przypiąć ruch do nieudanej ścieżki albo po cichu ominąć celową politykę routingu, i grzebie pierwotną przyczynę pod nową konfiguracją. Po przywróceniu trasy ponownie przetestuj aplikację i potwierdź, że wybrany prefiks ma działającą ścieżkę danych, a nie tylko wpis w tablicy.