Metryka trasy VPN zmieniła się po połączeniu: co to oznacza
Niższa metryka rozstrzyga tylko remis między równie konkretnymi trasami. Przeczytaj regułę polityki, prefiks i trasę hosta punktu końcowego, zanim zmienisz numer trasy VPN.
Łączysz się z VPN, uruchamiasz route print i domyślna trasa ma teraz znacznie niższą metrykę niż wcześniej. Naturalny wniosek jest taki, że VPN przejął trasę domyślną, bo jego numer jest mniejszy. Czasami dokładnie tak się stało. Często metryka wcale nie jest czynnikiem decydującym, a jej edycja niczego nie zmienia, bo wybór został dokonany wcześniej — przez długość prefiksu lub regułę polityki.
Objaw jest realny: ruch, który wcześniej wychodził przez adapter Wi-Fi, wychodzi teraz przez tunel, albo odwrotnie. Metryka to jedno wejście do wyszukiwania, które przebiega w ustalonej kolejności, i właśnie tę kolejność trzeba przeczytać, zanim dotknie się liczby.
Z czym liczba faktycznie konkuruje
Pierwsze porównanie to konkretność, a nie preferencja. Trasa do 10.20.0.0/16 wygrywa z 10.0.0.0/8, a obie wygrywają z 0.0.0.0/0, cokolwiek mówią ich metryki. VPN, który instaluje trasę domyślną z najniższą metryką na maszynie, nadal przegrywa z każdą bardziej konkretną trasą pasującą do celu, w tym z trasą hosta, którą klient instaluje dla własnego serwera.
Dlatego obniżenie metryki trasy domyślnej nie może wepchnąć bezpośrednio podłączonej podsieci do tunelu. Jeśli chcesz tę podsieć wewnątrz VPN, dodaj trasę dla prefiksu albo wybierz tabelę tunelu regułą polityki. Metryka to niewłaściwa dźwignia do tego zadania.
| Check in this order | Question | Where you read it |
|---|---|---|
| 1. Policy and table | Which routing table does this traffic use? | ip rule, client profile |
| 2. Prefix length | Which matching route is most specific? | route print, ip route |
| 3. Metric | Which of the equally specific routes is preferred? | route print, ip route |
| 4. Interface state | Is the chosen next hop reachable? | adapter status, link state |
Linux wybiera tabelę przed metryką
W Linuksie jądro najpierw konsultuje bazę polityk. ip rule wymienia reguły i tabele, które wybierają, a ip route get 203.0.113.10 raportuje tabelę, trasę i adres źródłowy, których jądro faktycznie użyłoby dla tego celu. Metryka wewnątrz tabeli 100 nigdy nie konkuruje z trasą w tabeli głównej, bo reguła wybrała tabelę, zanim porównano jakąkolwiek metrykę.
Dlatego trasa może wyglądać poprawnie w ip route show table all i nadal nie przenosić ruchu. Przeczytaj regułę, która pasowała, potem tabelę, którą wybrała, a potem porównaj trasy w niej. Jeśli wybrano niewłaściwą tabelę, żadna zmiana metryki w drugiej tabeli nie pomoże.
Windows łączy dwie metryki
Windows domyślnie nie ma bazy polityk, ale łączy metrykę trasy z metryką interfejsu, a automatyczna metryka interfejsu może się zmieniać wraz z prędkością łącza i stanem adaptera. Dlatego ta sama trasa może zachowywać się inaczej po pojawieniu się stacji dokującej lub adaptera wirtualnego. Find-NetRoute -RemoteIPAddress 203.0.113.10 raportuje wybrany adres źródłowy, następny skok i interfejs, co jest bliższe rzeczywistej decyzji niż surowa tabela.
Czytaj wartości trasy i interfejsu razem. Podniesienie metryki interfejsu może przenieść ruch bez zmiany jakiegokolwiek wpisu trasy, a klient VPN, który posiada swoje trasy, zainstaluje je ponownie przy ponownym połączeniu i odrzuci twoją zmianę.
Trzymaj punkt końcowy tunelu poza tunelem
Każdy tunel potrzebuje drogi do własnego serwera, która nie przebiega przez tunel. Klienci instalują trasę hosta do punktu końcowego przez bramę fizyczną, a ta trasa musi pozostać bardziej konkretna niż trasa domyślna dodawana przez klienta. Usuń ją albo pozwól tunelowi wygrać wyszukiwanie tego adresu, a enkapsulowane pakiety spróbują wejść do tunelu, który mają zbudować. Połączenie zawodzi albo wpada w pętlę.
Sprawdź tę trasę hosta przed każdą zmianą metryki i po niej: powinna wskazywać fizyczny następny skok i przetrwać ponowne połączenie. Jeśli klient jest jej właścicielem, zmień profil albo konfigurację zarządzaną, a nie wartość czasu wykonania, która zostanie nadpisana.
Sprawdź obie rodziny adresów i kontekst aplikacji
IPv4 i IPv6 to osobne decyzje z osobnymi tabelami. VPN może przenosić IPv4, podczas gdy IPv6 nadal korzysta z lokalnego routera, a zmiana metryki w jednej rodzinie nic nie mówi o drugiej. Sprawdź obie, a potem sprawdź kontekst aplikacji. Proces przypisany do interfejsu, przestrzeń nazw kontenera albo VPN dla poszczególnych aplikacji może widzieć inną tabelę niż twoja powłoka.
Weryfikuj narzędziem, które raportuje decyzję dla rzeczywistego celu, a nie pełną listą tabeli. Jeśli wybrana trasa jest tą, którą przewiduje projekt, zatrzymaj się. Metryka, która nie jest najmniejszą liczbą na ekranie, nie jest usterką, a zmuszanie jej do bycia najmniejszą może zepsuć ścieżkę punktu końcowego, od której zależy tunel.