Rutowanie rekurencyjne: gdy tunel przechwytuje własne pakiety

Tunel się podnosi, dziennik pokazuje ukończony uścisk dłoni, a sekundę później ta sama sesja ginie i łączy się ponownie w pętli. Ten wzorzec ma konkretną przyczynę: trasa do serwera wskazuje teraz do wnętrza tunelu, więc pakiety niosące tunel są wysyłane przez tunel. W uwierzytelnianiu nic się nie zmieniło, dlatego ponowne wpisanie danych logowania niczego nie zmienia. Porównaj ścieżkę zewnętrzną przed zmianą trasy i po niej, a rekurencja stanie się widoczna.

Najpierw sprawdź ścieżkę zewnętrzną

W grze są dwa pakiety, a nie jeden. Pakiet wewnętrzny należy do aplikacji i powinien być szyfrowany, natomiast pakiet zewnętrzny jest adresowany do serwera i musi do niego dotrzeć ścieżką, która nie zależy od tunelu.

ip route get 198.51.100.7
ip rule show
ip route show table all | grep -F 198.51.100.7
wg show wg0 endpoints

Zapytaj jądro o trasę do adresu serwera po podniesieniu tunelu, a potem jeszcze raz po zmianie trasy domyślnej. Następny skok, który ląduje na urządzeniu tunelu, to właśnie rekurencja, i widać ją bez żadnego przechwytywania pakietów. Powiązanie z interfejsem, znaczniki lub przestrzeń nazw sieci mogą sprawić, że zwykłe wyszukiwanie będzie niepełne, więc używaj kontekstu, którego używa sam klient. Gdy odpowiedź wygląda poprawnie, ale sesja nadal się zapętla, czytaj reguły polityki routingu, a nie tylko główną tabelę.

Dlaczego sesja przetrwa chwilę

Uścisk dłoni kończy się przed zainstalowaniem nowej trasy, więc pierwsze sekundy wyglądają zdrowo. Gdy tylko klient doda trasę domyślną, następny pakiet zewnętrzny podąża za nią do interfejsu, przez który ten pakiet musi przejść. Serwer nic nie widzi, klient wysyła ponownie, a próba albo kończy się przekroczeniem czasu, albo zabija sesję i zaczyna od nowa.

Ta kolejność wyjaśnia, dlaczego tunel może działać na laptopie, a zawodzić na routerze, i dlaczego awaria często zaczyna się przy starcie ruchu, a nie przy połączeniu. Wyjaśnia też pętlę: każdy restart odtwarza sesję, zanim trasa uczyni to niemożliwym.

Ustal, do kogo należy wyjątek dla punktu końcowego

Obsługiwane klienty same przygotowują swój wyjątek: trasę do hosta serwera przez pierwotną bramę albo znacznik, który trzyma zewnętrzne gniazdo poza tunelem. Pytanie brzmi, czy coś innego go nie usunęło lub nie nadpisało.

W IPsec opartym na trasach sprawdź selektory polityki, które decydują, które pakiety wchodzą do tunelu, i potwierdź, że adres peera jest z nich wykluczony. W WireGuard znacznik zapory interfejsu i jego reguły polityki trzymają pakiety transportowe poza tunelem, więc ręcznie dodana trasa domyślna może zepsuć ten układ. Drugi profil VPN lub skrypt zarządzania, który przepisuje trasę domyślną, jest częstym winowajcą. Szerokie reguły obejścia dodawane jedna po drugiej to zwykły wynik, i zamieniają błąd routingu w tabelę, której nikt nie potrafi utrzymać.

Sprawdź ponownie po zmianie sieci

Trasa do hosta przez bramę Wi-Fi jest poprawna, dopóki maszyna nie przejdzie do innej sieci. Wtedy ten sam objaw wraca bez żadnej zmiany konfiguracji.

Zapisz adres punktu końcowego, trasę przed i po połączeniu oraz interfejs, którego użył każdy z nich. Te trzy fakty zwykle oddzielają błąd klienta od nadpisania, i przeżywają osobę, która je zebrała.

Połącz się ponownie w nowej sieci i powtórz odczyt. Jeśli wyjątku znów brakuje, poprawka należy do profilu, który go posiada, a nie do jednorazowego polecenia wpisanego podczas awarii.