Dlaczego jedna podsieć nadal omija domyślną trasę VPN

Przełączasz VPN na pełny tunel, większość ruchu jest posłuszna, a potem jeden adres odpowiada bezpośrednio — drukarka, NAS, host skoku w 10.x. Oczywiste odczytanie jest takie, że tunel przecieka, więc obniżasz metrykę trasy domyślnej i nic się nie zmienia. Ta nieudana próba jest wskazówką: trasa domyślna to rezerwa, nie wyrok. Wyszukiwanie trasy bierze najdłuższy pasujący prefiks, zanim w ogóle porówna metryki, więc /24 nadal wygrywa z /0, niezależnie od tego, jaką liczbę przypiszesz do którejkolwiek. Gdy ten porządek jest jasny, wyciek to zwykle trasa, którą ktoś zainstalował celowo, albo prefiks, którego klient nigdy nie zamierzał objąć.

Co naprawdę obiecuje trasa domyślna

0.0.0.0/0 pasuje do każdego celu IPv4 z zerem bitów szczegółowości. Istnieje po to, by host mógł dotrzeć do wszystkiego, czego jego tabela nie opisuje lepiej. Trasa do 192.168.1.0/24 niesie 24 pasujące bity, więc dla 192.168.1.40 wygrywa, zanim ktokolwiek porówna metryki, odległość administracyjną czy cokolwiek klient nazywa polem priorytetu. Ta sama reguła obowiązuje w FIB Linuksa, tabeli routingu Windows i stosie BSD za macOS.

W normalnej sieci LAN to zachowanie jest zaletą. Lokalna podsieć jest podłączona bezpośrednio, drukarka działa dalej, gdy tunel niesie Twoje przeglądanie, i nic nie jest źle skonfigurowane. Pytanie, które warto zadać, nie brzmi, dlaczego ten jeden adres idzie bezpośrednio, ale który prefiks w której tabeli do niego pasuje i kto go tam umieścił.

Połówkowe trasy domyślne, czyli dlaczego wpis domyślny może wyglądać na nietknięty

Najczystszy przykład to redirect-gateway def1 w OpenVPN. Zamiast usuwać Twoją trasę domyślną i ją zastępować, dodaje 0.0.0.0/1 i 128.0.0.0/1. Razem para obejmuje cały IPv4, każdy prefiks jest dłuższy niż /0, i oba biją trasę domyślną routera, zostawiając ją na miejscu. Uruchom potem listę tras, a pierwotna trasa domyślna nadal tam jest, nadal wskazuje Twoją bramę; po prostu nigdy nie jest wybierana dla celów internetowych.

wg-quick WireGuard osiąga ten sam wynik przez routing oparty na polityce. Gdy AllowedIPs obejmuje 0.0.0.0/0, tworzy własną tabelę, wysyła tam oznaczone pakiety i dodaje regułę, która ignoruje prefiks o zerowej długości tabeli głównej. Tabela główna zachowuje wpis domyślny, a reguły decydują, że tabela tunelu jest pytana pierwsza dla ruchu należącego do interfejsu.

Oba projekty potrzebują dokładnie jednej trasy poza tunelem: trasy hosta do własnego adresu serwera VPN przez pierwotną bramę. Bez niej klient próbowałby nieść przez tunel pakiety, które budują tunel, i połączenie nigdy by się nie zakończyło. Trasa niebędąca trasą tunelu w Twojej tabeli jest więc normalna nawet w surowym profilu pełnego tunelu. Trasy warte zakwestionowania to te, które obejmują cele, na których naprawdę Ci zależy.

Metryki rozstrzygają remisy, prefiksy rozstrzygają zwycięzców

Metryki porównuje się tylko między kandydatami, którzy równie dobrze pasują do celu. W Linuksie ip route get 10.20.5.9 wypisuje zwycięzcę wraz z jego tabelą, a ip route show table all wymienia kandydatów, w tym ewentualne połówkowe trasy domyślne i każdą tabelę, na którą wskazuje reguła. W Windows Find-NetRoute -RemoteIPAddress 10.20.5.9 zwraca wybraną trasę i adres źródłowy, a Get-NetRoute pokazuje surową tabelę — ale efektywny koszt to metryka trasy plus metryka interfejsu, więc wolny adapter może przegrać remis, który zdaje się wygrywać.

Trzy przypadki obejmują większość tego, co zobaczysz:

• Ten sam cel, /24 kontra /0: /24 wygrywa długością prefiksu, cokolwiek mówią metryki.
• Ten sam cel, dwie /24 z różnymi metrykami: wygrywa niższa metryka efektywna.
• Ten sam cel, dwie tabele, jedna wybrana przez regułę polityki: reguła najpierw wybiera tabelę, a porównanie prefiksów odbywa się w niej.

Trzeci przypadek to miejsce, w którym kończy się większość takich zgłoszeń. ip rule Linuksa lub filtr ruchu VPN Windows może wysłać ruch do tabeli, która nigdy nie zawierała trasy domyślnej tunelu, a tabela główna przez cały czas wygląda bezbłędnie.

Kto zwykle jest właścicielem obejścia

Zacznij od profilu, nie od tabeli. Konfiguracje split-tunnel i ustawienia VPN dla poszczególnych aplikacji celowo zostawiają nazwane prefiksy poza tunelem; profil służbowy, który chroni jedną prywatną podsieć i pozwala ogólnemu przeglądaniu iść bezpośrednio, zachowuje się zgodnie z projektem, a jego nadpisanie łamie politykę, którą miał egzekwować. Wskazówki Microsoftu dotyczące routingu VPN wyznaczają tę samą granicę między ruchem wymuszonym do tunelu a jawnymi wyjątkami, co czyni je użyteczną kontrolą krzyżową przed edycją czegokolwiek.

Następnie poszukaj pozostałości. Trasa wskazująca interfejs, którego już nie ma, albo adres z poprzedniej sieci, pojawia się po odejściu i powrocie stacji dokujących, adapterów USB i mostów kontenerów. Jednorazowe usunięcie to nie koniec: profile połączeń NetworkManagera, pliki netplan i trwałe trasy Windows instalują ją ponownie przy następnym połączeniu lub starcie, więc znajdź plik lub profil, który ją posiada, zanim cokolwiek zmienisz.

Potem sprawdź IPv6 osobno. ip -6 route i Get-NetRoute -AddressFamily IPv6 trzymają odrębny stan, odrębne trasy domyślne i odrębne zachowanie klienta. Audyt tylko IPv4 nic nie mówi o hoście z podwójnym stosem, który po cichu preferuje natywną ścieżkę IPv6, i to samo może sprawić, że klient wygląda na split-tunnel.

Potwierdź własnym przepływem aplikacji

Zapisz cel, którego aplikacja naprawdę używa, a potem zapytaj system o ścieżkę, którą obrałby z adresu źródłowego, do którego ta aplikacja się wiąże. ip route get 10.20.5.9 from 192.168.1.40 odpowiada na to w Linuksie; Find-NetRoute -RemoteIPAddress 10.20.5.9 plus adres lokalny robi to w Windows. Porównaj wynik z tym, co twierdzi profil. Strona publicznego IP przeglądarki testuje jeden cel na jednym protokole i nie mówi nic o prywatnym adresie, od którego zaczęła się skarga.

Napraw najwęższy obiekt, który wyjaśnia różnicę. Jeśli wyjątek jest zatwierdzony, zapisz prefiks i zostaw go; jeśli nie, usuń trasę lub dodaj jawną węższą trasę przez tunel, zamiast obniżać metrykę trasy domyślnej. Obniżenie metryki nie może prześcignąć dłuższego prefiksu, a edycja trasy domyślnej, gdy dwie trasy /1 posiadają ścieżkę internetową, też niczego nie zmienia.

Następnie połącz tunel ponownie i powtórz to samo zapytanie. Klienci ponownie instalują trasy przy każdym połączeniu, więc zmiana, która przetrwa tylko do następnego uścisku dłoni, nie została przetestowana. Jeśli ścieżka nadal się różni, pozostałymi podejrzanymi są reguła polityki, druga tabela lub filtr po stronie klienta — nie trasa domyślna.

• Nazwij cel i adres źródłowy, których aplikacja naprawdę używa.
• Wypisz zwycięską trasę za pomocą ip route get lub Find-NetRoute.
• Sprawdź, czy ścieżką internetową rządzi para /1, czy tabela polityki.
• Wymień każdy prefiks dłuższy niż /0, który pasuje do celu.
• Powtórz sprawdzenie IPv6 osobno.
• Prześledź pozostałą trasę z powrotem do pliku, profilu lub filtra, który ją instaluje.
• Połącz ponownie i uruchom zapytanie jeszcze raz, zanim uznasz to za naprawione.

Jeśli wszystkie siedem zgadza się z profilem, tunel robi dokładnie to, do czego został skonfigurowany, a poprawka należy do profilu, nie do metryki.