Co bypass-dhcp do plánu tras OpenVPN skutečně přidává

Profil s redirect-gateway def1 bypass-dhcp kombinuje nahrazení výchozí IPv4 trasy s jednou úzkou výjimkou. Lidé přečtou poslední slovo a čekají obecné řešení mobilních připojení, a pak stráví odpoledne u teorie DHCP, kterou ten přepínač nikdy nepodporoval. Každá část dělá jednu věc a výjimka je mnohem menší než její pověst.

Rozeberte přepínače dřív, než selhání jen v mobilní síti přičtete přidělování adres. Obě poloviny toho řetězce spolu nemají nic společného.

Dva přepínače, dva nesouvisející úkoly

S def1 klient přidá dvě poloviny výchozí IPv4 trasy, místo aby vyměnil výchozí trasu, která už existuje. 0.0.0.0/1 pokrývá spodní polovinu adresního prostoru a 128.0.0.0/1 horní, takže společně dosáhnou každého cíle, zatímco každá zůstává konkrétnější než 0.0.0.0/0. Původní výchozí trasa proto zůstává v tabulce, aniž by tyto výhledy vyhrávala, což starou bránu udržuje dosažitelnou pro vše, co klient výslovně směruje. Zároveň v tabulce zůstávají dvě překrývající se výchozí trasy, a proto může výpis tras vypadat podivněji, než profil naznačuje.

bypass-dhcp je samostatný a výchozí trasy se vůbec nedotýká. Manuál OpenVPN 2.6 ho popisuje jako přidání přímé trasy k DHCP serveru, který není v místní podsíti, takže provoz pronájmu vychází mimo tunel, a poznamenává, že toto chování je implementováno u klientů Windows a jinde nemusí být dostupné.

Důvod jeho existence je mechanický. Jakmile poloviny výchozí trasy zachytí odchozí provoz, obnovení pronájmu DHCP směrované na server ve fyzické síti by bylo směrováno do tunelu, pokud něco tu adresu nepřipne ke skutečnému rozhraní. Přepínač ji připne.

Na co se výjimka skutečně vztahuje

Ilustrativní tabulka po úspěšném připojení ukazuje tvar: dvě poloviny výchozí trasy tunelem a jedna trasa k hostiteli DHCP serveru přes fyzickou bránu. Čtěte ji jako tvar, ne jako své vlastní 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

Ten třetí řádek pojmenovává jeden cíl. Není to nastavení resolveru, není to obecné povolení pro místní síť a není to pravidlo odchozího provozu na serveru. Telefon na mobilním přenosu nemusí mít DHCP server, který by klient takto identifikoval, a proto tam přepínač nic nemění.

Zkontrolujte, co klient skutečně nainstaloval

Rozlišujte volbu zapsanou v profilu, volbu nabídnutou serverem a trasu, kterou vlastník připojení skutečně použil. Klient, který nepodporovaný přepínač odmítne, může zbytek konfigurace ponechat, takže tunel naskočí a výjimka prostě chybí. Čtěte vlastní log klienta a výslednou směrovací tabulku, místo abyste předpokládali, že řádek v souboru začal platit. Tři z toho mohou platit současně a jen to poslední mění, kam pakety skutečně jdou.

Udržujte trasu ke koncovému bodu VPN zároveň použitelnou. Tahle výjimka pro koncový bod je jiný požadavek než výjimka DHCP, a bez ní může tunel zachytit transport, který ho udržuje.

U cíle aplikace prozkoumejte efektivní vyhledání v kontextu, kde selhává. Konkrétnější místní trasy, směrování podle zásad a vyloučení po aplikacích mění odpověď, takže přítomnost dvou polovin výchozí trasy není soupisem každého toku.

Zbytek cesty v tomto přepínači není

Server stále potřebuje oprávnění předávat internetový provoz klienta a odchozí uspořádání, které ho dokáže vrátit. Žádná trasa na straně klienta nevytvoří chybějící předávání ani překlad zdroje na serveru a žádný přepínač nenahradí funkční zpáteční cestu.

Překlad jmen i IPv6 potřebují každý vlastní zásadu. Nahrazení IPv4 ani nesměruje resolver na server na straně tunelu, ani nevytváří pokrytí IPv6, a klient, který přesměrovává jen v4, nechává cestu v6 nedotčenou.

Porovnejte jeden schválený neškodný požadavek po funkční a po selhávající přístupové cestě, se profilem a cílem pevně danými. Zaznamenejte, zda rozdíl spočívá v překladu jmen, navázání tunelu, volbě trasy nebo předávaném provozu, a odpověď uložte k profilu. Právě tento záznam brání dalšímu člověku svádět na DHCP problém, na který nedosáhne.