Co bypass-dhcp naprawdę dodaje do planu tras OpenVPN

Ta flaga instaluje jedną trasę do hosta serwera DHCP poza tunelem. To nie przekazywanie internetu, polityka DNS, pokrycie IPv6 ani poprawka dla sieci komórkowej.

Profil z redirect-gateway def1 bypass-dhcp łączy zastąpienie domyślnej trasy IPv4 z jednym wąskim wyjątkiem. Ludzie czytają ostatnie słowo i oczekują ogólnego rozwiązania dla połączeń mobilnych, a potem spędzają popołudnie na teorii DHCP, której ta flaga nigdy nie wspierała. Każda część robi jedną rzecz, a wyjątek jest znacznie mniejszy niż jego reputacja.

Rozłóż flagi na części, zanim przypiszesz awarię występującą tylko w sieci komórkowej przydziałowi adresów. Dwie połowy tego ciągu nie mają ze sobą nic wspólnego.

Dwie flagi, dwa niezwiązane zadania

Z def1 klient dodaje dwie IPv4 półdomyślne trasy zamiast zastępować istniejącą już trasę domyślną. 0.0.0.0/1 obejmuje dolną połowę przestrzeni adresowej, a 128.0.0.0/1 górną, więc razem docierają do każdego celu, a każda pozostaje bardziej szczegółowa niż 0.0.0.0/0. Pierwotna trasa domyślna pozostaje więc w tabeli, nie wygrywając tych wyszukiwań, co utrzymuje starą bramę osiągalną dla wszystkiego, co klient trasuje jawnie. Zostawia też w tabeli dwie nakładające się trasy domyślne, dlatego zrzut tras może wyglądać dziwniej, niż sugeruje profil.

bypass-dhcp jest osobne i w ogóle nie dotyka trasy domyślnej. Podręcznik OpenVPN 2.6 opisuje je jako dodanie trasy bezpośredniej do serwera DHCP, który nie znajduje się w lokalnej podsieci, dzięki czemu ruch dzierżawy wychodzi poza tunel, i zauważa, że zachowanie to jest zaimplementowane na klientach Windows i może być niedostępne gdzie indziej.

Powód jego istnienia jest mechaniczny. Gdy półdomyślne trasy przejmą ruch wychodzący, odnowienie DHCP skierowane do serwera w sieci fizycznej zostałoby trasowane do tunelu, chyba że coś przypnie ten adres do rzeczywistego interfejsu. Flaga go przypina.

Czego wyjątek naprawdę dotyczy

Ilustracyjna tabela po udanym połączeniu pokazuje kształt: dwie półdomyślne trasy przez tunel i jedna trasa do hosta serwera DHCP przez fizyczną bramę. Czytaj ją jako kształt, a nie jako własne adresy.

0.0.0.0/1        via 10.8.0.1      dev tun0
128.0.0.0/1      via 10.8.0.1      dev tun0
192.168.1.1/32   via 192.168.1.254 dev wlan0

Ta trzecia linia wskazuje jeden cel. To nie ustawienie resolvera, nie ogólne pozwolenie dla sieci lokalnej i nie reguła wyjścia na serwerze. Telefon w sieci komórkowej może nie mieć serwera DHCP, który klient rozpozna w ten sposób, dlatego flaga niczego tam nie zmienia.

Sprawdź, co klient naprawdę zainstalował

Odróżnij opcję zapisaną w profilu, opcję zaproponowaną przez serwer i trasę, którą właściciel połączenia faktycznie zastosował. Klient, który odrzuci nieobsługiwaną flagę, może zachować resztę konfiguracji, więc tunel wstanie, a wyjątek po prostu nie wystąpi. Czytaj własny log klienta i wynikową tabelę tras, zamiast zakładać, że wiersz w pliku zaczął obowiązywać. Trzy z tych rzeczy mogą być prawdziwe jednocześnie, a tylko ostatnia zmienia, gdzie pakiety faktycznie trafiają.

Utrzymuj jednocześnie użyteczną trasę do punktu końcowego VPN. Ten wyjątek punktu końcowego jest innym wymaganiem niż wyjątek DHCP, a bez niego tunel może przechwycić transport, który go utrzymuje.

Dla celu aplikacji zbadaj efektywne wyszukiwanie w kontekście, w którym zawodzi. Bardziej szczegółowe trasy lokalne, trasowanie polityk i wykluczenia dla aplikacji zmieniają odpowiedź, więc obecność dwóch półdomyślnych tras nie jest spisem każdego przepływu.

Reszta ścieżki nie tkwi w tej fladze

Serwer nadal potrzebuje zgody na przekazywanie ruchu internetowego klienta oraz wyjścia, które potrafi go zwrócić. Żadna trasa po stronie klienta nie tworzy brakującego przekazywania ani tłumaczenia źródła na serwerze, a żadna flaga nie zastępuje działającej drogi powrotnej.

Rozwiązywanie nazw i IPv6 potrzebują każdy własnej polityki. Zastąpienie IPv4 ani nie kieruje resolvera do serwera po stronie tunelu, ani nie ustanawia pokrycia IPv6, a klient przekierowujący tylko v4 pozostawia ścieżkę v6 nietkniętą.

Porównaj jedno zatwierdzone nieszkodliwe żądanie na działającej i zawodnej ścieżce dostępu, trzymając profil i cel bez zmian. Zapisz, czy różnica tkwi w rozwiązywaniu nazw, w zestawieniu tunelu, w wyborze trasy czy w przekazywanym ruchu, i zachowaj odpowiedź razem z profilem. To właśnie ten zapis powstrzymuje następną osobę przed obwinianiem DHCP o problem, do którego ono nie dociera.

Powiązane artykuły