Tabela routingu a rzeczywiste wyszukiwanie: dokąd trafia ruch VPN

Zrzut tabeli routingu to najmniej użyteczna diagnostyka w rozwiązywaniu problemów z VPN i najczęściej wklejana. Czterdzieści wierszy prefiksów mówi, co maszyna mogłaby zrobić, a nie co zrobiła dla nieudanego żądania. Mechanizmem, którego naprawdę chcesz, jest wyszukiwanie: przy danym źródle i celu, która reguła pasowała, która tabela została sprawdzona i jaki interfejs oraz następny skok wyszły. Zacznij od jednego celu i jednego źródła, a potem czytaj tabelę z tym pytaniem w ręku, i te same dane wyjściowe stają się dowodem zamiast szumu.

Tabela to zbiór kandydatów, nie decyzja

Każdy wpis opisuje prefiks i co zrobić z ruchem, który do niego pasuje: wysłać go do interfejsu, przekazać następnemu skokowi albo odrzucić. Nic w tej liście nie jest uporządkowane według intencji, a wpis, który człowiekowi wydaje się najbardziej konkretny, nie zawsze jest tym, który wybiera jądro, ponieważ wybór kieruje się najdłuższym dopasowaniem prefiksu, a przy równych prefiksach metryką.

Więc pierwszym krokiem jest zapytanie jądra zamiast czytania listy. Polecenie wyszukiwania odpowiada dla celu, a z argumentem źródła odpowiada dla dokładnej pary, której użyłoby połączenie przekazywane lub powiązane:

ip route get 198.51.100.10
ip route get 198.51.100.10 from 10.80.0.25
ip -6 route get 2001:db8:10::40

Każdy adres powyżej to przykład dokumentacyjny. Chodzi o kształt odpowiedzi: interfejs, wybrane źródło, brama i tabela, z której pochodzi wpis. Jeśli te dane wyjściowe nie zgadzają się z oczekiwanym interfejsem, zlokalizowałeś problem jednym poleceniem, a żadna ilość czytania pełnej tabeli nie powiedziałaby ci, który kandydat wygrał.

Wyszukiwanie przechodzi najpierw reguły, potem tabele

W Linuxie decyzja jest dwuetapowa. Reguły polityki są oceniane w kolejności priorytetów, a pierwsza pasująca reguła wskazuje tabelę do sprawdzenia; ta tabela wykonuje potem dopasowanie najdłuższego prefiksu. Reguła może pasować do źródła, celu, znacznika zapory, interfejsu lub kombinacji, dlatego zrzut tabeli głównej może być całkowicie dokładny i całkowicie nieistotny dla badanego pakietu.

ip rule show
ip route show table all | head -40
ip route show table 100

Jeśli reguła wysyła ruch z twojej puli VPN do tabeli 100, to tabela 100 jest tą, która się liczy, i tabela główna jest wabikiem. To także mechanizm routingu opartego na źródle na routerze: ten sam cel może mieć dwie różne odpowiedzi w zależności od tego, skąd przyszedł pakiet, i tylko wyszukiwanie z argumentem źródła ujawnia, która obowiązuje.

IPv6 ma własne reguły i tabele. Projekt obsługujący obie rodziny potrzebuje obu wyszukiwań, a działająca odpowiedź IPv4 nic nie mówi o ścieżce v6, którą klient dual-stack może preferować.

Co instaluje klient VPN

Klienci zwykle nie zastępują trasy domyślnej, ponieważ złamałoby to własną zewnętrzną ścieżkę tunelu. Instalują coś bardziej konkretnego, co wygrywa długością prefiksu: para półdomyślnych tras obejmujących 0.0.0.0/1 i 128.0.0.0/1 to klasyczny trik, ponieważ obie są dłuższymi prefiksami niż 0.0.0.0/0 i razem obejmują całą przestrzeń. Inni instalują konkretne prefiksy prywatne plus regułę polityki, a niektórzy dodają znacznik, aby przechwytywany był tylko wybrany ruch.

Dlatego "VPN nie zmienił mojej trasy domyślnej" nie jest dowodem awarii. Sprawdź, co faktycznie dodał, i czy dany cel mieści się w tych prefiksach:

ip route show | grep -E 'tun|wg|ppp|ipsec'
ip route get 10.20.30.40 from 10.80.0.25

Dwie półtrasy łatwo przeoczyć w zrzucie, ponieważ nie wyglądają jak trasa domyślna. Konfiguracja split-tunnel, która zapomniała uwzględnić prefiks, daje dokładnie ten objaw, którego szukasz: aplikacja, która powinna używać tunelu, zamiast tego rozwiązuje i łączy się lokalnie. Porównaj zainstalowane prefiksy z celami, których użytkownik naprawdę potrzebuje, a nie z adresami, które przypadkiem przetestowałeś. Lista split-tunnel obejmująca serwer plików, ale nie jego resolver, daje połączenie, które rozwiązuje się na publiczny adres, a potem nie przechodzi uwierzytelnienia, co wygląda jak problem z hasłem, a jest problemem z trasą.

Zewnętrzna trasa też musi przetrwać

Tunel sam jest ruchem. Pakiety niosące enkapsulowany ładunek idą do adresu peera przez interfejs fizyczny, a ta ścieżka nie może być routowana z powrotem do tunelu. Kiedy tak się dzieje, pojawia się charakterystyczna awaria, w której tunel się nawiązuje, a potem przestaje przepuszczać ruch, ponieważ transport tunelu jest teraz wewnątrz tunelu.

Sprawdź adres peera tak, jak sprawdziłeś cel wewnętrzny, i potwierdź, że rozwiązuje się na interfejs fizyczny, a nie na tunel:

ip route get 203.0.113.10
traceroute -n -m 5 203.0.113.10

Trasa rekurencyjna, reguła polityki łapiąca peera albo trasa domyślna zastąpiona przez klienta pełnego tunelu to trzy zwykłe przyczyny. Wszystkie trzy są widoczne w zewnętrznym wyszukiwaniu, a żadna nie jest widoczna w zrzucie tabeli głównej wykonanym po fakcie.

Czego nie powie ci wynik routingu

Poprawne wyszukiwanie oznacza, że jądro wysłałoby pakiet w rozsądne miejsce. Nie oznacza, że zapora go przepuszcza, polityka IPsec go obejmuje, reguła NAT go tłumaczy albo druga strona ma trasę powrotną. Każdy z tych elementów to późniejszy etap, a notatki strongSwan o przekazywaniu opisują łańcuch, przez który pakiet musi przejść na obu końcach.

Nie uwzględnia też wiązania na poziomie aplikacji. Proces może powiązać się z interfejsem, ustawić znacznik albo użyć własnego resolvera i połączyć się z nazwą, która rozwiązuje się inaczej niż testowana. Gdy wyszukiwanie jest poprawne, a połączenie nadal zawodzi, następne pytanie brzmi, który proces je tworzy i czy ten proces widzi tę samą tabelę co ty.

Więc utrzymuj diagnozę w porządku: nazwij cel i źródło, uruchom wyszukiwanie, czytaj tylko tabelę i regułę wskazane przez wyszukiwanie, a potem przetestuj następny etap. Ta kolejność utrzymuje śledztwo routingu w granicach minut i zostawia zapis, który ktoś inny może powtórzyć, czego wklejona tabela nigdy nie robi.