Przekierowania ICMP a trasy VPN: co naprawdę się zmienia

Przepływ, który powinien przejść przez tunel, wybiera inny następny skok, a ktoś znajduje przekierowanie ICMP w przechwyconym ruchu. To hipoteza, nie diagnoza. Przekierowanie to sugestia routera dotycząca lepszego następnego skoku, a to, czy host na nią zareaguje, zależy od ustawień, które różnią się w zależności od platformy, interfejsu i rodziny adresów.

Przekierowanie to sugestia od routera

Przekierowania ICMP IPv4 mają własny typ komunikatu i wąski zestaw warunków: router wysyła pakiet przez ten interfejs, którym przyszedł, i zna na tym samym łączu następny skok bliższy celowi. Następnie mówi nadawcy, aby użył tego skoku bezpośrednio. Komunikat podaje nową bramę i zawiera część oryginalnego pakietu, aby nadawca mógł go dopasować do przepływu. To uprzejmy komunikat o lokalnej topologii i zakłada, że nadawca dzieli łącze z sugerowaną bramą.

Nadawca może go zignorować. Protokół nie wymaga, aby host zmieniał swoją tablicę, a przechwycone przekierowanie dowodzi tylko, że router je wysłał.

Właśnie na tym rozróżnieniu myli się większość dochodzeń dotyczących przekierowań.

IPv4 i IPv6 dostarczają je inaczej

IPv6 ma analogiczny mechanizm w wykrywaniu sąsiadów, a nie w ICMPv4, z innymi formatami komunikatów i innymi regułami walidacji. Pojęcia się rymują, pakiety nie. Filtr przechwytywania napisany dla typu ICMP 5 nic nie pokaże w sieci IPv6, co czasem bywa czytane jako dowód, że żadne przekierowanie nie wystąpiło.

Parametry polityki też są osobne, więc host może akceptować przekierowania IPv4 i ignorować IPv6, albo odwrotnie.

Sprawdź obie rodziny, jeśli dany przepływ może używać którejkolwiek.

Akceptacja to polityka hosta, nie fakt sieci

W Linuksie akceptacja przekierowań jest kontrolowana na interfejs i globalnie, a wartości domyślne różnią się między rolą hosta i routera. Interfejs tunelu, który akceptuje przekierowania, to dziwny projekt, bo w tunelu punkt-do-punkt nie ma sensownego alternatywnego następnego skoku na tym samym łączu. Dlatego to ustawienie warto przeczytać, a nie zakładać.

Ustawienia bezpiecznych przekierowań dodatkowo ograniczają, którym bramom można wierzyć.

Jeśli zaostrzasz hosta, to właśnie te parametry trzeba przejrzeć, i one są też powodem, dla którego dwie maszyny w tej samej sieci mogą zachowywać się różnie. Zmieniaj je jako politykę, a nie jako skrót do debugowania.

Czego przekierowanie nie wyjaśni

Konkretne trasy, reguły routingu politycznego i lokalne interfejsy wyjaśniają większość nieoczekiwanych ścieżek bez żadnego przekierowania. Bardziej konkretny prefiks, reguła pasująca do adresu źródłowego albo druga trasa domyślna w innej tablicy każdy z nich nadpisze trasę, której oczekiwałeś. Sprawdź je najpierw, bo są deterministyczne i widoczne.

Nieaktualne przechwycenie to druga pułapka, bo klient, który zmienił sieć, ma inną lokalną bramę.

Stare przekierowanie z poprzedniego połączenia nic nie wyjaśnia o obecnej ścieżce, więc zapisz, który interfejs odbiera teraz ruch kontrolny.

Sprawdź trasę, zanim obwinisz tunel

Zapytaj jądro, której trasy użyłoby dla celu, a potem porównaj ją z tablicą, którą miałeś na myśli. Jeśli odpowiedź zgadza się z tablicą, żadne przekierowanie niczego nie zmieniło i dochodzenie należy gdzie indziej. Jeśli się nie zgadza, zanim uznasz, że winny jest tunel, poszukaj buforowanego przekierowania, reguły polityki albo drugiej tablicy. Wyszukanie trasy jest prawdą, a wszystko inne to opowieść o tym, jak do tego doszło.

Przekierowanie nigdy nie powinno być powodem, dla którego chroniona ścieżka po cichu staje się niechroniona, dlatego polityka akceptacji należy do przeglądu projektu. Definicja w RFC 792 pozostaje odniesieniem do tego, co może powiedzieć komunikat IPv4.

Zapisz razem wynik wyszukania trasy i znacznik czasu przechwycenia, a następna osoba odtworzy twój wniosek.