Twoja stara trasa domyślna celowo przetrwa OpenVPN

Łączysz tunel, uruchamiasz ip route, a pierwotna brama domyślna wciąż tam jest. Następna myśl jest taka, że klient nie przejął trasy, więc usuwasz domyślną ręcznie i całkowicie tracisz łączność. Ten wpis ma pozostać. Z redirect-gateway def1 OpenVPN instaluje dwie bardziej szczegółowe trasy, które przewyższają zwykłą domyślną, zamiast ją zastępować. Stara brama zostaje i przestaje nieść ruch, który testowałeś.

Co def1 naprawdę robi

Flaga dodaje 0.0.0.0/1 i 128.0.0.0/1, obie wskazujące na tunel. 0.0.0.0/1 obejmuje każdy adres, którego pierwszy oktet wynosi od 0 do 127, a 128.0.0.0/1 obejmuje od 128 do 255, więc każde miejsce docelowe IPv4 ma dopasowanie bardziej szczegółowe niż stara trasa domyślna. O tym, która trasa wygra, decyduje długość prefiksu, a nie metryka.

Pozostawienie pierwotnej trasy domyślnej na miejscu jest zamierzone. Klient nie musi pamiętać, co zastąpił, i nie przepisuje trasy, która niesie jego własne połączenie z serwerem VPN. Przy rozłączeniu usuwa dwie połówkowe trasy i tablica wraca do stanu poprzedniego.

Dlaczego /1, a nie /0

Routing wybiera najdłuższy pasujący prefiks, a nie najniższą metrykę, więc /1 bije /0 niezależnie od tego, co mówi metryka trasy domyślnej. Obie połowy istnieją, bo jedno /1 pokrywa tylko połowę przestrzeni; gdy jest tylko 0.0.0.0/1, wszystko od 128.0.0.0 w górę nadal idzie starą trasą domyślną, co daje mylący objaw: jedne strony działają, a inne nie.

Podniesienie lub obniżenie metryki starej trasy domyślnej niczego nie zmienia, a trasa domyślna z niższą metryką na innym interfejsie też nie kradnie ruchu. Najpierw decyduje długość prefiksu, a do metryki uciekają się tylko równe prefiksy.

Przeczytaj prawdziwą tablicę routingu

Podłączony host może pokazać wszystkie trzy wpisy naraz, przy czym tunel niesie połowy, a pierwotna brama wciąż jest na liście. Adresy są przykładami, a nie konfiguracją do skopiowania, ponieważ nazwy interfejsów, topologia tunelu i dodatkowe trasy różnią się w zależności od platformy i klienta.

default via 192.168.50.1 dev wlan0
0.0.0.0/1 via 10.8.0.1 dev tun0
128.0.0.0/1 via 10.8.0.1 dev tun0

Ważna jest relacja: dwie konkretne połowy nad jedną ogólną trasą domyślną. Wiersz starej bramy zostaje, bo nic go nie zastąpiło.

Sprawdź, którą trasę pakiet naprawdę obiera

Bardziej szczegółowe trasy nadal mogą wygrać: trasa dla zakresu prywatnego, lokalnej podsieci lub własny adres serwera VPN jest dłuższy niż /1. Tunel potrzebuje zewnętrznej drogi do swojego serwera, a odesłanie tego połączenia z powrotem do tunelu natychmiast by je zepsuło. W Linuksie zapytaj jądro, zamiast czytać tablicę na oko: ip route get z interesującym cię celem wypisuje wybraną trasę, interfejs i źródło. Jeśli skonfigurowano routing oparty na politykach, przejrzyj też reguły, bo reguła może wybrać inną tablicę, zanim zostanie sprawdzona główna.

Jeśli źle zachowuje się tylko część IPv4, potwierdź, że zainstalowano obie połowy, a potem szukaj wyjątku pasującego do zawiedzionego celu. Usunięcie starej trasy domyślnej nie jest rozwiązaniem i zabiera trasę, której klient potrzebuje, by czysto rozłożyć tunel.

Czego def1 nie obejmuje

Dwa wpisy IPv4 nic nie mówią o IPv6: host z łącznością IPv6 nadal używa swojej trasy domyślnej, dopóki coś nie przekieruje tej rodziny osobno, dlatego w sieci dwustosowej część ruchu wygląda, jakby omijała tunel. Inni klienci i menedżerowie sieci implementują routing pełnego tunelu inaczej, a ich tablice się nie zgodzą. Opisane tutaj zachowanie def1 należy do udokumentowanej flagi OpenVPN, a nie do każdej VPN na maszynie.

Wyłącznik awaryjny odpowiada na inne pytanie: co robi maszyna, gdy tunel padnie. Priorytet tras decyduje, dokąd idzie ruch, dopóki tunel jest aktywny; nie decyduje, co potem robi zapora. Kolejność pracy: przeczytaj tablicę, potwierdź, że istnieją obie połowy, uruchom ip route get dla zawiedzionego celu, sprawdź reguły polityk, a potem osobno spójrz na IPv6. Zostaw starą trasę domyślną tam, gdzie jest.