Jak odróżnić trasy wciskane przez VPN od statycznych w Linuksie

Prefiks pojawia się na laptopie, gdy tunel się podnosi, więc wydaje się, że zainstalował go VPN. Może tak być, ale ten sam efekt może pochodzić ze skryptu klienta uruchamianego przy połączeniu, z profilu połączenia, który wymienia podsieć, albo z trasy statycznej, która była tam od początku i zaczęła działać dopiero wtedy, gdy interfejs istniał. Wybór niewłaściwego właściciela oznacza, że trasa wraca po każdym czyszczeniu, a następna osoba powtarza tę samą poprawkę. Poniższa sekwencja rozdziela te trzy, zanim cokolwiek zostanie zmienione.

Krok 1: nazwij mechanizm, który instaluje prefiksy

Różne protokoły zapewniają osiągalność na różne sposoby, a nazywanie tego wszystkiego ogłoszeniem ukrywa różnicę. Serwer OpenVPN wypycha dyrektywę trasy kanałem kontrolnym, a klient instaluje ją, o ile nie zablokuje jej filtr pull. Konfiguracja WireGuard wymienia dozwolone prefiksy lokalnie, a klient używa ich zarówno do routingu kluczy kryptograficznych, jak i do tras, które dodaje. Tunel IPsec uzgadnia z peerem selektory ruchu, a jądro instaluje trasy z tych selektorów.

Zanim przeczytasz jakąkolwiek tabelę, ustal, którego z nich używa twój tunel. Trasa wypchnięta przy połączeniu nie jest ogłoszeniem protokołu routingu i nie obiecuje, że prefiks jest osiągalny za dalekim końcem. Zapisz mechanizm obok prefiksu, bo to on decyduje, gdzie należy poprawka.

Krok 2: porównaj tabelę w trakcie połączenia

Zapisz główną tabelę przy opuszczonym tunelu, podnieś go, zapisz ponownie i porównaj oba zrzuty. Wszystko, co się pojawiło, należy do cyklu życia połączenia, a wszystko, co zostało, należy do konfiguracji lokalnej.

Zarejestruj ją za pomocą ip route show table main > /tmp/route-down.txt, połącz się i zarejestruj ponownie. Zrób to samo dla ip -6 route, jeśli witryna używa IPv6, bo brakujący prefiks tworzy tam awarie, które wyglądają na niezwiązane z routingiem.

Krok 3: czytaj metrykę, nie tylko obecność

Dwa wpisy dla tego samego prefiksu mogą współistnieć, a jądro wybiera niższą metrykę. Trasa statyczna z metryką 50 będzie nadal wygrywać z wypchniętą trasą o metryce 100, mimo że obie są widoczne, dlatego „trasa tam jest” i „ruch z niej korzysta” to różne stwierdzenia.

Zapytaj jądro bezpośrednio poleceniem ip route get 10.20.5.7 i odczytaj interfejs, który zgłasza. Jeśli ruch wychodzi przez kartę fizyczną, podczas gdy trasa tunelu siedzi w tabeli, wyjaśnia to metryka lub długość prefiksu, a nie klient VPN. Powtórz wyszukiwanie dla hosta, o którym wiesz, że jest za tunelem, i dla takiego, o którym wiesz, że nie jest, a różnica pokaże, czy podział działa zgodnie z zamiarem.

Krok 4: znajdź wpisy, które przeżywają tunel

Trasy statyczne przeżywają rozłączenie z założenia i stąd biorą się nieaktualne wpisy. Trwała trasa wskazująca interfejs, który już nie istnieje, może po cichu połknąć podsieć, a ta wskazująca ponownie używaną nazwę interfejsu może po restarcie wysłać prywatny ruch złymi drzwiami.

Sprawdź stronę trwałą w miejscu, którego używa twoja dystrybucja, czy to jednostka systemd-networkd, profil NetworkManager czy skrypt w katalogu up klienta. Naprawa żywej tabeli poleceniem ip route del trzyma się tylko do następnego połączenia. Traktuj to usunięcie jako test hipotezy, a nie jako naprawę.

Gdy daleki koniec daje złe pokrycie, zgłoś to operatorowi, zamiast filtrować wszystko. Odrzucenie wszystkich wypchniętych ustawień odrzuca też DNS i politykę tunelu dzielonego, od których zależy profil.

Krok 5: potwierdź drogę powrotną, zanim obwinisz klienta

Dla połączenia lokacja-lokacja lub podsieci za tunelem daleka strona potrzebuje trasy powrotnej do adresu twojego klienta i włączonego przekazywania na bramie. Droga jednokierunkowa wygląda dokładnie jak błąd routingu klienta, tyle że uścisk dłoni i pakiet wychodzący kończą się powodzeniem.

Filtrowanie drogi powrotnej dodaje drugą pułapkę na bramach Linuksa. Odpowiedź przychodząca innym interfejsem, niż przewiduje trasa, jest odrzucana w trybie ścisłym, a asymetryczne drogi przez dwóch dostawców wywołują to niezawodnie. Liczniki odrzuceń na bramie, a nie na kliencie, mówią, czy przyczyną jest filtrowanie.

Krok 6: testuj zasób, a nie ping

Gdy wybrana trasa jest poprawna, otwórz rzeczywisty zasób i potwierdź ruch powrotny. Odpowiedź ping dowodzi drogi w jednym kierunku i niczego o usłudze, a usługa odpowiadająca na połączeniu z pamięci podręcznej dowodzi jeszcze mniej.

Następnie powtórz całą kontrolę po ponownym połączeniu. Wartość tej sekwencji polega na tym, że przewiduje, co zrobi następne połączenie, dlatego zarówno porównanie, jak i metryka należą do zgłoszenia.