Jak wysłać jeden cel IPv4 poza tunel OpenVPN

Większość konfiguracji pełnego tunelu wysyła każdy pakiet przez VPN, a dyrektywa redirect-gateway to umożliwia. Jeden cel nadal można wyłączyć. Dodanie trasy hosta dla tego adresu z symbolem zastępczym net_gateway mówi klientowi, aby dotarł do niego przez oryginalną bramę maszyny, podczas gdy wszystko inne nadal korzysta z tunelu.

Linia wygląda nieszkodliwie i często taka jest, ale rozstrzyga tylko jedno pytanie: dokąd trafiają pakiety do dokładnie tego adresu IPv4. Nie zmienia DNS, IPv6, polityki zapory ani tego, który proces otworzył połączenie, a każde z nich może po cichu zniweczyć wyjątek.

Co naprawdę nazywa net_gateway

Wpis w profilu dla tego wyjątku to jedna linia: route 198.51.100.77 255.255.255.255 net_gateway. Pierwszy adres to dokumentacyjny symbol zastępczy celu, maska czyni go trasą do jednego hosta, a ostatni token nazywa symbol zastępczy bramy. OpenVPN rozwiązuje symbole zastępcze bram, gdy instaluje trasy. vpn_gateway oznacza własną bramę tunelu, czyli dalszą stronę łącza VPN. net_gateway oznacza bramę domyślną, którą host miał przed zmianą czegokolwiek przez VPN, czyli zwykle lokalny router w sieci fizycznej.

Trzeci symbol zastępczy, remote_host, odnosi się do adresu serwera VPN i istnieje po to, aby tunel mógł dotrzeć do serwera drogą fizyczną. Mylenie tych trzech to najczęstsza przyczyna tego, że wyjątek trafia w złe miejsce albo w ogóle się nie instaluje.

Wartość jest czytana w momencie połączenia, a nie zapisywana w pliku. Jeśli maszyna przeniesie się do innej sieci, brama sprzed VPN się zmienia, a trasa podąża za nową. Zwykle tego właśnie chcesz, ale oznacza to też, że zachowanie wyjątku zależy od sieci, z której klient wystartował.

Dlaczego trasa hosta wygrywa z domyślną trasą tunelu

O routingu decyduje najbardziej szczegółowy pasujący prefiks. redirect-gateway def1 zwykle nie zastępuje trasy domyślnej; dodaje dwie połowy, trasę dla dolnej połowy przestrzeni adresowej i jedną dla górnej, dzięki czemu oryginalna trasa domyślna zostaje zachowana do innych celów. Te połowy są szersze niż jeden adres.

Trasa do jednego adresu z maską 255.255.255.255 to /32, czyli największa szczegółowość, jaką daje IPv4. Gdy oceniany jest pakiet do tego adresu, /32 pasuje i wygrywa niezależnie od tego, która trasa została zainstalowana pierwsza. To jest mechanizm stojący za wyjątkiem i działa on tak samo na Linuksie, macOS i Windows, o ile trasa rzeczywiście istnieje.

Windows dodaje drugi wymiar. Gdy dwie trasy są równie szczegółowe, wygrywa ta z niższą metryką, a karta VPN może nieść metrykę interfejsu, która zmienia wynik. /32 nadal jest bardziej szczegółowa niż połowy, więc wyjątek zwykle się utrzymuje, ale nieaktualna trasa z wcześniejszej sesji może dać mylący wynik, jeśli jest równie szczegółowa.

Czego wyjątek nie obejmuje

DNS to pierwsza luka. Klient może wepchnąć wewnętrzne ustawienia resolvera, a system operacyjny będzie ich nadal używać do zapytań. Aplikacja, która rozwiązuje nazwę przed połączeniem, może otrzymać wewnętrzny adres usługi, która powinna iść bezpośrednio, albo adres zewnętrzny, który rozwiązuje się poprawnie, ale potem potyka się o następną lukę.

IPv6 to druga. Dyrektywa trasy obsługuje tylko IPv4. Cel z podwójnym stosem może preferować IPv6, który w zależności od polityki podąża za tunelem lub domyślną trasą IPv6 hosta, więc wyjątek IPv4 nigdy nie wchodzi w grę. Potrzebujesz pasującej trasy IPv6 albo świadomej decyzji o wyłączeniu IPv6 dla tego klienta.

Zasięg aplikacji to trzeci. Reguła opiera się na celu, więc każdy proces łączący się z tym adresem korzysta ze ścieżki bezpośredniej, niezależnie od tego, czy to ten, o którym myślałeś. Odwrotnie, strona może odpowiadać z kilku adresów, więc wyłączenie jednego /32 nie wyłącza strony. Jeśli prawdziwym wymaganiem jest routing per aplikacja, tabela tras klienta Community to niewłaściwe narzędzie.

Sprawdzić wyjątek, nie oszukując samego siebie

Zacznij od zainstalowanej trasy, a nie od przeglądarki. W Linuksie zapytaj jądro, której trasy i następnego skoku użyje dla konkretnego adresu; w Windows odczytaj tabelę tras dla tego /32. Potwierdź, że brama jest fizyczna, a nie tunelem. Jeśli wpisu brakuje, profil nie został zastosowany albo klient nie miał uprawnień do zmiany tras.

Następnie przetestuj dwa cele. Żądanie do wyłączonego adresu powinno wyjść przez interfejs fizyczny, a żądanie do wewnętrznego adresu kontrolnego powinno nadal korzystać z tunelu. Testowanie tylko wyłączonego adresu niczego nie dowodzi o reszcie tunelu, a testowanie publicznej strony testuje adres, na który ta strona się rozwiązała, który może nie być tym z reguły.

Na koniec sprawdź mechanizmy, które mogą nadpisać trasę. Kill switch po stronie klienta lub ustawienie Windows block-outside-dns może zabronić ruchu bezpośredniego, co objawia się połączeniem, które zawodzi mimo poprawnej trasy. Nie wyłączaj tych mechanizmów, aby wyjątek wyglądał na działający; jeśli polityka zabrania ścieżki bezpośredniej, wyjątek jest problemem projektowym dla właściciela usługi VPN.

Sprawdź ponownie po ponownym połączeniu lub zmianie sieci, ponieważ brama sprzed VPN i dostępna ścieżka są właściwościami chwili, a nie profilu.