Metryka trasy OpenVPN: dlaczego wybrana trasa wciąż przegrywa

Dodałeś metrykę do trasy w profilu, połączyłeś się ponownie, a ruch nadal wychodzi przez niewłaściwy interfejs. Liczba rzadko jest problemem. Metryka porządkuje tylko kandydatów, których system operacyjny już porównuje, a bardziej szczegółowy prefiks lub wcześniejsza tabela polityk rozstrzyga, zanim jakakolwiek metryka zostanie odczytana.

Przejrzyj najpierw profil, potem zainstalowaną tabelę, a następnie reguły wyboru. Ta kolejność odpowiada sposobowi, w jaki klient buduje trasę, i powstrzymuje cię przed dostrajaniem wartości, która nigdy nie trafia do porównania.

Czytaj wiersz trasy w kolejności pól

Klient Community OpenVPN 2.6 przyjmuje cztery pola w wierszu IPv4 route: sieć, maskę sieci, bramę i opcjonalną metrykę. Na pozycji bramy znajduje się specjalne słowo kluczowe vpn_gateway. Oznacza ono następny przeskok po stronie VPN dla tego połączenia, a nie numer tabeli routingu i nie twój fizyczny router. Jeśli to przeoczysz, reszta wiersza jest czytana z błędnym wyobrażeniem o tym, co robi. Dokumentacja network-options opisuje wszystkie cztery pola.

Dla prywatnego celu wiersz może wyglądać tak:

route-metric 50
route 172.20.0.0 255.255.0.0 vpn_gateway 30

Jawna 30 dotyczy tej trasy, a 50 pozostaje domyślną dla każdej innej trasy w profilu, która pomija liczbę. Czytanie wiersza od lewej do prawej wystarcza, by powiedzieć, która wartość gdzie obowiązuje.

route-metric to domyślna wartość, nie ranga

route-metric ustawia wartość zapasową dla tras, które nie mają własnej liczby. Nie wynosi trasy ponad cokolwiek innego i nie zmienia kolejności tras zainstalowanych z jawnymi metrykami.

Ta różnica ma znaczenie, gdy profil miesza obie formy. Pojedynczy wiersz route-metric u góry wygląda autorytatywnie i łatwo go obwinić, podczas gdy trasa, która faktycznie przenosi ruch, może mieć własną metrykę trzy wiersze niżej.

Jeśli chcesz, aby jedna trasa preferowała określoną drogę, umieść liczbę na tej trasie. Jeśli chcesz spójnej wartości domyślnej w całym wygenerowanym profilu, użyj route-metric i zostaw poszczególne wiersze w spokoju. Mieszanie obu bez powodu to sposób, w jaki profil kończy z trasą, której nikt nie potrafi wyjaśnić.

Sprawdź, co zainstalował klient

Po zakończeniu ponownego połączenia pytaj jądra, a nie profilu.

ip route show wymienia trasy dodane przez klienta, a ip route get 172.20.5.10 odpowiada na bardziej użyteczne pytanie: której trasy ten cel faktycznie by użył i z jakim adresem źródłowym. Jeśli celu nie ma w tabeli, klient go nie zainstalował.

Lokalna dyrektywa, push z serwera lub inny menedżer sieci może dodać lub usunąć ten sam prefiks, a wygrywa ten, kto pisze ostatni. Miej trasę punktu końcowego na oku podczas pracy, ponieważ połączenie potrzebuje drogi do zdalnego serwera, która nie przechodzi przez budowany tunel.

Dlaczego mniejsza metryka wciąż przegrywa

Metryki porównują trasy do tego samego celu. Nie czynią szerokiego prefiksu bardziej szczegółowym. Gdy w grze jest redirect-gateway def1, klient instaluje 0.0.0.0/1 i 128.0.0.0/1, a te dwa prefiksy pokrywają całą przestrzeń IPv4 bardziej szczegółowo niż 0.0.0.0/0. Metryka 1 na trasie domyślnej ich nie przebija.

Ta sama logika dotyczy każdej nakładającej się pary. /24 bije /16 dla adresu w jej wnętrzu, niezależnie od dołączonych liczb, ponieważ wyszukiwanie najpierw wybiera najbardziej szczegółowe dopasowanie, a dopiero potem porównuje metryki między równymi.

To jest ta część, która wygląda jak błąd metryki, a nią nie jest. Sprawdź długość prefiksu u obu kandydatów, zanim zmienisz jakąkolwiek liczbę.

Reguły polityki działają przed tabelą

W systemie Linux ip rule decyduje, która tabela routingu jest sprawdzana. Reguły są oceniane w kolejności priorytetów, więc wcześniejsza tabela może zwrócić trasę, zanim główna tabela zostanie w ogóle odczytana. Metryka w main nie może przebić dopasowania w tabeli, która została sprawdzona jako pierwsza.

Użyj ip rule show, a następnie odpytaj konkretną tabelę, na przykład ip route show table 100, aby zobaczyć, co ta reguła by zwróciła. Jeśli klient VPN lub środowisko kontenerowe dodało regułę, odpowiedź może być tam, a nie w tabeli, którą czytałeś. Adres źródłowy też ma znaczenie, ponieważ reguła może dopasować źródło i rozwiązać ten sam cel inaczej dla ruchu tunelowego i ruchu LAN.

Sprawdź cel, a nie ranking

Testem, który kończy spór, jest jedno zapytanie do hosta w zamierzonej podsieci oraz sprawdzenie adresu źródłowego wybranego przez jądro. Jeśli ta para pasuje do projektu, metryka robi swoje, nawet gdy lista nie wygląda jak czysty ranking.

Zostaw IPv6 i DNS poza tym sprawdzeniem. Konfigurują je inne dyrektywy i rozwiązują inne mechanizmy, a działająca trasa IPv4 nie mówi o nich nic. Zmieniaj jedną warstwę naraz i uruchamiaj zapytanie ponownie.