Gdy trasy podzielonego tunelu się nakładają: który prefiks wygrywa

Dwa profile podzielonego tunelu, dwa prywatne prefiksy i jeden host, do którego oba roszczą sobie prawo. Objaw rzadko jest czystą awarią: usługa działa w poniedziałek, kończy się przekroczeniem czasu po ponownym połączeniu drugiego klienta i znów działa po restarcie. Kolejność, w jakiej połączyłeś klientów, nie decyduje o wyniku, podobnie jak kolejność wierszy w interfejsie klienta. Wykonaj te kontrole po kolei i zatrzymaj się na pierwszej, która nie zachodzi, bo późniejsze mają sens tylko wtedy, gdy wcześniejsze są prawdziwe.

1. Zapisz cel i źródło

Zacznij od dokładnego adresu, do którego trafia nieudane żądanie, a nie od nazwy hosta i nie od nazwy aplikacji. Rozwiąż nazwę raz, zanotuj każdą odpowiedź i wybierz tę, której nieudany przepływ rzeczywiście używa. Następnie zanotuj lokalny adres tego samego przepływu, bo adres źródłowy może zmienić, która reguła polityki pasuje, a więc która tabela jest sprawdzana.

Żądanie do jednego z kilku rekordów A może się nie udać, podczas gdy sąsiedni adres działa, co wygląda na niestabilny tunel, a w rzeczywistości jest dwiema różnymi ścieżkami. Jeśli celem jest nazwa z kilkoma odpowiedziami, przetestuj każdą odpowiedź osobno, zanim cokolwiek zmienisz.

2. Zapytaj jądro, którą trasę wybrało

Nie czytaj tabeli tras i nie wyciągaj z niej wniosku. Zadaj to samo pytanie, które zadaje stos, z tym samym adresem źródłowym: ip route get 10.20.4.10 from 10.8.0.2 w Linux lub Find-NetRoute -RemoteIPAddress 10.20.4.10 w PowerShell. Wynik wskazuje trasę, która byłaby naprawdę użyta, a to często nie ta, której oczekiwałeś, czytając tabelę.

Spośród pasujących tras zwykle wygrywa bardziej szczegółowy prefiks: /24 bije /16 dla adresu leżącego w obu. Między dopasowaniami o równej długości wygrywa niższa metryka, a trasa zainstalowana na wyłączonym łączu jest pomijana. Dwa tunele ogłaszające ten sam /24 z tą samą metryką to inny przypadek: jądro zachowuje obie trasy i wybiera między nimi, więc wynik może się zmieniać zamiast podążać za kolejnością połączeń klientów. To właśnie ta sytuacja tworzy wzorzec w poniedziałek działa, we wtorek nie, i ponowne połączenie w innej kolejności tego nie zmienia.

3. Sprawdź, czy reguła polityki przekierowała wyszukiwanie

Zanim tabela tras zostanie sprawdzona, jądro przechodzi przez swoje reguły polityki. Reguła może wysłać ruch z danego źródła, użytkownika lub znacznika zapory do zupełnie innej tabeli, więc zwycięski prefiks w tabeli głównej może nigdy nie zostać sprawdzony dla tego przepływu. ip rule show wymienia je w kolejności oceny, a ip route show table 100 pokazuje, co wybrana tabela naprawdę zawiera.

Tutaj czyhają dwie pułapki. Reguła wskazująca na pustą tabelę tworzy wyszukiwanie, które przechodzi do następnej reguły, więc reguła wydaje się nic nie robić. Druga to sam numer priorytetu: reguły czyta się rosnąco, a wartości wbudowane to 0 local, 32766 main i 32767 default. Reguła z numerem poniżej 32767 jest sprawdzana przed regułą domyślną, która łapie wszystko. Reguła z numerem powyżej 32767 stoi za nią i jest osiągana tylko wtedy, gdy żadna wcześniejsza tabela nie odpowie, czemu zapobiega zwykła trasa domyślna w main, więc w praktyce nigdy nie jest osiągana i po cichu nic nie robi, wyglądając na zainstalowaną. Jeśli klient zapisał regułę i trasę, sprawdź oba i sprawdź je ponownie po ponownym połączeniu, bo przepisany profil może dodać drugą regułę z innym priorytetem.

4. Oddziel remis w routingu od zduplikowanego planu adresów

Czasem prefiks w ogóle nie jest problemem. Dwie lokalizacje, które obie używają 192.168.1.0/24, oznaczają, że ten sam adres identyfikuje dwa różne hosty i żadna trasa nie potrafi ich rozróżnić. Trasa do hosta na jedną z dwóch odpowiedzi działa tylko do chwili, gdy druga lokalizacja odpowie na tę samą nazwę, a wtedy wyjątek po cichu staje się usterką.

Sygnałem jest to, że adres docelowy jest identyczny na obu ścieżkach i różni się tylko zamierzony właściciel. To decyzja o planie adresów, a nie korekta routingu: przenumeruj jedną stronę, umieść jedną stronę za bramą, która tłumaczy, albo dotrzyj do drugiej lokalizacji przez proxy, które samo rozwiązuje swoje nazwy. Obniżanie trasy domyślnej albo piętrzenie wyjątków dla hostów tylko przenosi kolizję.

5. Potwierdź, że resolver zgadza się z trasą

Nazwa rozwiązująca się na zły adres prywatny daje wszystkie objawy konfliktu routingu i żadnej z jego przyczyn. Porównaj odpowiedź, którą otrzymuje host, z adresem, którego cel naprawdę używa, i sprawdź, który resolver odpowiedział. Jeśli tunel wymusza resolver, klient powinien go zainstalować dla przepływów korzystających z tunelu; jeśli nie, host nadal pyta lokalny resolver, który może odpowiedzieć z domeny wyszukiwania lub z zapisu w pamięci podręcznej.

Zapytaj resolver bezpośrednio i zanotuj serwer, który odpowiedział. Odpowiedź z pamięci podręcznej z krótkim TTL może też wyjaśnić, dlaczego pierwsze żądanie po ponownym połączeniu zachowuje się inaczej niż piąte.

6. Połącz się ponownie, sprawdź zastosowany stan, a potem przetestuj oba przepływy

Po poprawce połącz się ponownie i sprawdź, co klient naprawdę zainstalował, zamiast ufać edytorowi profilu. Przeczytaj ponownie reguły, tabele i wynikową odpowiedź ip route get. Drugi klient może przy połączeniu ponownie zainstalować własną trasę i odtworzyć konflikt, dlatego kontrola stanu musi nastąpić po połączeniu ostatniego klienta, a nie przed nim.

Przetestuj dwa przepływy, nie jeden: żądanie, które wcześniej zawodziło, oraz zasób, który powinien korzystać z drugiego tunelu. Przeniesienie całego ruchu prywatnego na jedno połączenie sprawi, że pierwszy test przejdzie, ale drugi się zepsuje, i tylko test parami to wychwyci. Zapisz każdy zachowany wyjątek wraz z celem i powodem, aby następna osoba mogła odróżnić zamierzoną trasę do hosta od pozostałej.