Čo bypass-dhcp naozaj pridáva do plánu trás OpenVPN

Profil s redirect-gateway def1 bypass-dhcp kombinuje nahradenie predvolenej trasy IPv4 s jedinou úzkou výnimkou. Ľudia prečítajú posledné slovo a očakávajú všeobecné riešenie mobilných pripojení, potom strávia popoludnie teóriou DHCP, ktorú tento prepínač nikdy nepodporoval. Každá časť robí jednu vec a výnimka je oveľa menšia než jej povesť.

Rozdeľte prepínače skôr, než zlyhanie vyskytujúce sa len v mobilnej sieti pripíšete prideľovaniu adries. Obe polovice toho reťazca nemajú jedna s druhou nič spoločné.

Dva prepínače, dve nesúvisiace úlohy

S def1 klient pridá dve polovice predvolenej trasy IPv4 namiesto nahradenia predvolenej trasy, ktorá už existuje. 0.0.0.0/1 pokrýva spodnú polovicu adresného priestoru a 128.0.0.0/1 hornú, takže spolu dosiahnu každý cieľ, pričom každá zostáva konkrétnejšia než 0.0.0.0/0. Pôvodná predvolená trasa preto zostáva v tabuľke bez toho, aby tie vyhľadávania vyhrala, čo udržiava starú bránu dostupnú pre všetko, čo klient výslovne smeruje. Zanecháva v tabuľke aj dve prekrývajúce sa predvolené trasy, a preto môže výpis trás vyzerať čudnejšie, než profil naznačuje.

bypass-dhcp je samostatný a predvolenej trasy sa vôbec nedotýka. Manuál OpenVPN 2.6 ho opisuje ako pridanie priamej trasy k DHCP serveru, ktorý nie je v miestnej podsieti, takže prevádzka nájmu vychádza mimo tunela, a poznamenáva, že toto správanie je implementované na klientoch Windows a inde nemusí byť dostupné.

Dôvod jeho existencie je mechanický. Keď polovice predvolenej trasy zachytia odchádzajúcu prevádzku, obnovenie nájmu DHCP smerované na server vo fyzickej sieti by bolo smerované do tunela, ak niečo tú adresu nepripne k skutočnému rozhraniu. Prepínač ju pripne.

Na čo sa výnimka skutočne vzťahuje

Ilustračná tabuľka po úspešnom pripojení ukazuje tvar: dve polovice predvolenej trasy tunelom a jedna trasa k hostiteľovi DHCP servera cez fyzickú bránu. Čítajte ju ako tvar, nie ako svoje 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 tretí riadok pomenúva jeden cieľ. Nie je to nastavenie resolvera, nie je to všeobecné povolenie pre miestnu sieť a nie je to pravidlo odchodu na serveri. Telefón v mobilnej sieti nemusí mať DHCP server, ktorý by klient takto identifikoval, a preto tam prepínač nič nemení.

Skontrolujte, čo klient skutočne nainštaloval

Rozlišujte voľbu zapísanú v profile, voľbu ponúknutú serverom a trasu, ktorú vlastník pripojenia skutočne použil. Klient, ktorý odmietne nepodporovaný prepínač, môže zvyšok konfigurácie ponechať, takže tunel naskočí a výnimka jednoducho chýba. Čítajte vlastný log klienta a výslednú smerovaciu tabuľku namiesto predpokladu, že riadok v súbore začal platiť. Tri z toho môžu platiť súčasne a iba to posledné mení, kam pakety skutočne idú.

Udržujte trasu ku koncovému bodu VPN zároveň použiteľnú. Tá výnimka pre koncový bod je iná požiadavka než výnimka DHCP, a bez nej môže tunel zachytiť transport, ktorý ho udržiava.

Pre cieľ aplikácie preskúmajte efektívne vyhľadávanie v kontexte, kde zlyháva. Konkrétnejšie miestne trasy, smerovanie podľa pravidiel a vylúčenia pre aplikácie menia odpoveď, takže prítomnosť dvoch polovíc predvolenej trasy nie je súpisom každého toku.

Zvyšok cesty nie je v tomto prepínači

Server stále potrebuje povolenie preposielať internetovú prevádzku klienta a odchádzajúce usporiadanie, ktoré ju dokáže vrátiť. Žiadna trasa na strane klienta nevytvára chýbajúce preposielanie ani preklad zdroja na serveri a žiadny prepínač nenahrádza funkčnú spiatočnú cestu.

Preklad názvov a IPv6 potrebujú každý vlastnú politiku. Nahradenie IPv4 ani nesmeruje resolver na server na strane tunela, ani nevytvára pokrytie IPv6, a klient, ktorý presmerúva len v4, necháva cestu v6 nedotknutú.

Porovnajte jednu schválenú neškodnú požiadavku na funkčnej a na zlyhávajúcej prístupovej ceste, pričom profil a cieľ zostanú pevné. Zaznamenajte, či rozdiel spočíva v preklade názvov, v nadviazaní tunela, vo voľbe trasy alebo v preposielanej prevádzke, a odpoveď uložte k profilu. Práve tento záznam bráni ďalšiemu človeku zvaľovať vinu na DHCP za problém, na ktorý nedosiahne.