Jak odróżnić pętlę routingu od trzepotania trasy w witrynach VPN

Dwie witryny, jeden tunel i odległy prefiks, który przez jakiś czas odpowiada, a potem milknie. Odruch każe nazwać to pętlą routingu, i czasem dokładnie tym jest. Ale pętla i trzepocząca trasa dają tę samą skargę i wymagają przeciwnych napraw: jedna jest decyzją przekazywania, która nigdy się nie kończy, druga jest prefiksem, który wciąż opuszcza tabelę. Trzy obserwacje je rozdzielają, a wszystkie trzy można zebrać z wiersza poleceń bramy, zanim dotkniesz filtra lub uruchomisz tunel ponownie.

Pętla rozstrzyga się skok po skoku. Witryna A wybiera B jako następny skok do celu, B wybiera A dla tego samego celu, a pakiet wygasa na TTL po dwóch rundach. Trzepotanie rozstrzyga natomiast protokół routingu: prefiks jest wycofywany, instalowany ponownie lub zastępowany alternatywnym następnym skokiem, więc część pakietów nie ma żadnej trasy, a inne idą całkowicie dobrą.

Trzy kontrole, które rozstrzygają pytanie

Do pierwszej decyzji nie potrzebujesz przechwytywania pakietów. Potrzebujesz stanu prefiksu na obu końcach, następnego skoku wybieranego przez każdą stronę oraz liczby skoków, która się powtarza albo nie. Jeśli prefiks pozostaje zainstalowany z tym samym następnym skokiem, gdy ruch zawodzi, pętla żyje w ścieżce przekazywania. Jeśli prefiks znika i wraca, usterka jest powyżej przekazywania, a naprawa należy do protokołu routingu, nie do trasy statycznej.

Jedno ostrzeżenie przed startem. Jeśli czytasz to przez tunel, który zapętla, twoja sesja umrze w chwili, gdy zmienisz trasę. Otwórz konsolę lub ścieżkę zarządzania, która nie zależy od prefiksu, który zamierzasz naprawić.

Kontrola pierwsza: czy prefiks jest stabilny, czy się burzy

Zapytaj jądro, co zainstalowało, a nie co obiecuje plik konfiguracyjny. Na bramie Linuksa ip route get 10.20.30.40 wykonuje to samo wyszukiwanie co ścieżka przekazywania, łącznie z tabelami polityk, natomiast ip route show 10.20.30.0/24 pokazuje sam wpis. ip monitor route przesyła każdą zmianę w chwili jej wystąpienia, co jest najszybszym sposobem obserwowania, jak prefiks przychodzi i odchodzi.

Na routerze z FRR lub BIRD interesująca nie jest tabela przekazywania. show ip bgp 10.20.30.0/24 zwraca wybraną ścieżkę i jej czas działania; czas działania resetowany co kilka minut to trzepotanie, które można nazwać, a nie pętla. show ip bgp summary pokazuje stan sąsiadów i liczbę prefiksów, więc sąsiad, który ciągle pada, zdejmuje winę ze ścieżki przekazywania.

Zapisz odpowiedź, zanim cokolwiek zmienisz. Stabilność przez dziesięć minut, gdy pingi zawodziły, i zniknięcie cztery razy w dziesięć minut prowadzą do różnych kolejnych kroków. Drugi przypadek czyni każdą teorię trasy statycznej nieistotną.

Kontrola druga: czy następny skok wskazuje z powrotem w tunel przychodzący

Pętla wymaga zgody dwóch bram. W witrynie, która odbiera pakiet, spójrz na trasę, której pakiet użyje do wyjścia: ip route get 10.20.30.40 from 10.10.5.20 z prawdziwym adresem źródłowym, ponieważ reguła polityki może odpowiedzieć inaczej niż tabela główna. Następnie powtórz wyszukiwanie w witrynie, która go wysłała. Jeśli każda strona wybiera drugą jako następny skok dla tego samego prefiksu, pętla jest dowiedziona i żadne przechwycenie niczego nie doda.

Przyczyną jest prawie zawsze ogłoszenie, które nie powinno było przejść przez tunel. Trasa domyślna redystrybuowana do tunelu, agregat obejmujący własną podsieć odległej witryny albo trasa statyczna wskazująca partnera na wszelki wypadek tworzą ten sam wzajemny następny skok. Tunel może być w pełni zestawiony i nadal prowadzić ruch w kółko; uwagi o przekazywaniu strongSwana opisują stronę routingu tego wymagania.

WireGuard zasługuje na własną uwagę, bo nie ma ogłoszenia, które można obwinić. wg show wymienia AllowedIPs każdego partnera, a jądro akceptuje cel dla partnera tylko wtedy, gdy mieści się w tym zakresie. Pętla jest tam nakładającym się zakresem AllowedIPs albo trasą statyczną wskazującą z powrotem przez interfejs, więc naprawa żyje w tych dwóch miejscach i nigdzie indziej.

Kontrola trzecia: czytaj liczbę skoków, a nie gwiazdki

traceroute -n -I 10.20.30.40 i mtr -n -r -c 20 10.20.30.40 oba pokazują ścieżkę, a tryb ICMP często przeżywa filtrowanie, które zjada sondy UDP. Pętla wygląda jak krótka powtarzająca się sekwencja tych samych dwóch adresów bramy z rosnącym za każdym razem TTL. Spadek wygląda jak gwiazdki po ostatniej bramie, która odpowiedziała, a jeden cichy skok nie jest dowodem na nic.

Gdy ścieżka jest niejednoznaczna, czytaj TTL na przewodzie. tcpdump -ni any -vv icmp na obu bramach pokazuje TTL każdego pakietu i adres źródłowy każdej odpowiedzi o przekroczeniu czasu. Jeśli pakiet dociera do odległej witryny z TTL niższym niż liczba skoków, które ścieżka może zawierać, coś dodaje skoki, których traceroute ci nie pokazuje, a dzieje się to, gdy zapora jednej witryny odpowiada na sondy w imieniu drugiej.

Napraw właściciela prefiksu, a potem sprawdź oba kierunki

Zdecyduj, która witryna tworzy cel i które ścieżki tranzytowe są dozwolone, a następnie zmień ogłoszenie lub trasę statyczną u tego właściciela. Poprawianie witryny odbierającej jest kuszące i zwykle błędne: ukrywa pętlę dla jednego prefiksu i zostawia złe ogłoszenie na miejscu dla następnego. Znaczniki tras, listy dystrybucyjne i reguły split-horizon istnieją, aby zatrzymać to u źródła, i są tańsze niż filtr pasujący do jednego prefiksu.

Po zmianie sprawdź osobno drogę tam i z powrotem, bo pętla może zostać zastąpiona czarną dziurą bez żadnej widocznej poprawy objawu. Uruchom ip route get z obu końców, wyślij ruch z hosta, który nie jest bramą, i zostaw ip monitor route działające przez co najmniej jeden timer podtrzymania, żeby trzepotanie nie zostało wzięte za naprawę.

Zanim cokolwiek zmienisz, potwierdź te pięć punktów: prefiks jest stabilny albo się burzy, następny skok na obu końcach wskazuje tunel, liczba skoków się powtarza albo nie, jedna witryna posiada prefiks i masz ścieżkę zarządzania, która przetrwa zmianę. Jeśli którykolwiek z pięciu jest nieznany, pozostałe cztery to domysły.