OpenVPN redirect-gateway: co każda flaga robi z trasami

Połącz się z redirect-gateway w profilu, a trasa domyślna twojej maszyny może zniknąć, rozdzielić się na dwie albo zostać dokładnie tam, gdzie była, w zależności od flag, których nikt nie czyta dwa razy. Opcja zmienia tylko stan routingu i nic więcej, więc jedynym wiarygodnym dowodem na to, co zrobiła, jest tabela, którą klient zainstalował potem. Dalej jest tabela po połączeniu, trasa, która utrzymuje przy życiu sam tunel, oraz ruch IPv6, którego dyrektywa nigdy nie twierdzi, że obejmuje. Każdy krok to polecenie, które możesz wykonać na kliencie, gdy tunel jest aktywny.

Co każda flaga robi z trasą domyślną

Bez żadnej flagi opcja usuwa zwykłą trasę domyślną i wstawia na jej miejsce tunel, więc stara brama znika z tabeli, dopóki połączenie jest aktywne. Dodaj def1, a ta trasa domyślna pozostaje na liście, a pracę wykonują dwie węższe trasy. Dodaj bypass-dhcp, a trasa DHCP również przetrwa, co ma znaczenie w sieci, w której klient nadal musi dotrzeć do lokalnego serwera DHCP. Lista flag na stronie podręcznika OpenVPN 2.6 jest dość krótka, by przeczytać ją raz, a każdy wpis zmienia, które trasy trafią do tabeli.

Wypchnięta opcja zachowuje się tak samo po przybyciu, więc profil klienta może nie zawierać nic, podczas gdy tabela wygląda na w pełni przekierowaną. To normalne: serwer wysłał flagi, klient je zastosował, a lokalny plik nigdy nie wspomniał o dyrektywie. Gdy wypchnięcie wygląda na to, że nic nie robi, sprawdź filtr po stronie klienta, który przyjmuje lub odrzuca pobrane opcje, bo odrzucona opcja nie powoduje błędu po żadnej stronie.

def1 wygrywa dzięki szczegółowości, nie dotykając trasy domyślnej

Dwie półdomyślne trasy razem pokrywają przestrzeń IPv4, 0.0.0.0/1 i 128.0.0.0/1. Każda jest bardziej szczegółowa niż 0.0.0.0/0, więc wyszukiwanie preferuje je, a prawdziwa trasa domyślna pozostaje w tabeli dla wszystkiego, co prosi o najmniej szczegółowe dopasowanie.

Czytaj tabelę, nie profil, bo tylko tabela pokazuje, w którym z tych przypadków jesteś. Dwie linie wystarczą, by je rozróżnić:

ip route show default
ip route show | grep -E '^(0\.0\.0\.0/1|128\.0\.0\.0/1)'

Zwróć uwagę na interfejs i metrykę w każdym wierszu, nie tylko na cel. Trasa domyślna wskazująca tunel i para półdomyślnych wskazujących tunel opisują ten sam zamiar i zawodzą inaczej, gdy tunel padnie, bo w jednym przypadku trasa zapasowa nadal istnieje. Zapisz oba pola w notatce o zmianie. Ocalała trasa zapasowa czasem utrzymuje zdalną sesję wystarczająco długo, by naprawić tunel, i ona też przepuszcza ruch, gdy zamiarem był pełny tunel.

Utrzymuj osiągalny punkt końcowy tunelu

Klient potrzebuje trasy do dalekiego końca tunelu, która sama nie przechodzi przez tunel. OpenVPN instaluje tę trasę hosta, zanim cokolwiek innego zmieni, a ręczna edycja tras lub drugi klient VPN mogą ją usunąć. Objawem potem jest połączenie, które zgłasza połączenie, a następnie nic nie przepuszcza.

Zapytaj jądro, którego interfejsu użyłoby dla adresu punktu końcowego, gdy tunel jest aktywny. Odpowiedź musi wskazywać fizyczny interfejs i jego bramę, nigdy tun0:

ip route get 198.51.100.20

Jeśli to wyszukiwanie zwróci urządzenie tunelu, tunel niesie własny transport i zawali się, gdy tylko pakiet będzie musiał wyjść. Lokalne prefiksy, drugi adapter i routing oparty na polityce nadal mają tu znaczenie, dlatego przekierowanie, które działa na czystym laptopie, może zawieść na hoście z interfejsem zarządzania i dwiema trasami domyślnymi. Zwykle obwinia się profil za to, co zrobił plan adresów.

Ruch IPv6 nadal używa własnej tabeli

Przekierowanie IPv4 zostawia IPv6 w spokoju, a obie rodziny zmieniają różne flagi. Na hoście z podwójnym stosem i działającą trasą domyślną v6 ruch v4 może siedzieć całkowicie w tunelu, podczas gdy każdy cel obsługujący v6 wychodzi przez łącze fizyczne. Host, który wygląda poprawnie w jednej tabeli, przecieka w drugiej.

Sprawdź tabelę v6 po połączeniu, zamiast zakładać, że tunel ją objął. Dyrektywa niesie flagi rodziny adresów właśnie z tego powodu, a profil, który je pomija, dziedziczy to, co platforma robi domyślnie:

ip -6 route show default
ip -6 route get 2001:db8::10

Udowodnij, którego interfejsu używa aplikacja

Stan połączenia to nie blokada, a zmiana trasy to nie wyłącznik awaryjny. Jeśli ruch bezpośredni ma się zatrzymać, gdy tunel zawiedzie, ta polityka żyje w zaporze i wymaga własnego testu.

Testuj ścieżkę, którą aplikacja naprawdę podąża, a nie ścieżkę, którą opisuje profil. Najpierw zapytaj o trasę, potem po kolei przypisz żądanie do każdego interfejsu i porównaj, co zgłasza druga strona:

ip route get 203.0.113.10
curl -s --interface tun0 https://ifconfig.me
curl -s --interface eth0 https://ifconfig.me

Jeśli oba żądania zwrócą ten sam adres, aplikacja nie używa tunelu, choć tabela routingu mówi, że powinna. Jeśli powiedzie się tylko żądanie przypisane do tunelu, ścieżka fizyczna jest filtrowana dla tego celu i tunel robi to, o co prosiłeś. Zapisz flagi, zainstalowane trasy, wyszukiwanie punktu końcowego i oba wyniki wyjścia w rejestrze zmian, aby następna osoba odziedziczyła fakty, a nie zrzut ekranu.