Ano ang talagang idinadagdag ng bypass-dhcp sa isang plano ng ruta ng OpenVPN

Ang isang profile na may redirect-gateway def1 bypass-dhcp ay pinagsasama ang pagpapalit ng default na ruta ng IPv4 sa isang makitid na pagbubukod. Binabasa ng mga tao ang huling salita at umaasa ng pangkalahatang solusyon para sa mga mobile na koneksyon, pagkatapos ay gumugugol ng isang hapon sa isang teorya ng DHCP na hindi kailanman sinuportahan ng flag na ito. Bawat bahagi ay gumagawa ng isang bagay, at ang pagbubukod ay mas maliit kaysa sa reputasyon nito.

Hiwalayin ang mga flag bago iugnay ang isang pagkabigo na nangyayari lamang sa mobile sa pagtatalaga ng address. Ang dalawang kalahati ng string na iyon ay walang kinalaman sa isa't isa.

Dalawang flag, dalawang walang kaugnayang gawain

Sa def1, nagdaragdag ang client ng dalawang kalahating default na ruta ng IPv4 sa halip na palitan ang default na ruta na mayroon na. Sinasaklaw ng 0.0.0.0/1 ang ibabang kalahati ng espasyo ng address at ng 128.0.0.0/1 ang itaas na kalahati, kaya magkasama nilang naaabot ang bawat destinasyon habang ang bawat isa ay nananatiling mas tiyak kaysa sa 0.0.0.0/0. Kaya nananatili ang orihinal na default na ruta sa talahanayan nang hindi pinapanalunan ang mga paghahanap na iyon, na nagpapanatili sa lumang gateway na maabot para sa anumang itinuturo ng client nang tahasan. Nag-iiwan din ito ng dalawang magkapatong na default sa talahanayan, at kaya ang isang dump ng ruta ay maaaring magmukhang kakaiba kaysa sa ipinahihiwatig ng profile.

bypass-dhcp ay hiwalay, at hindi nito ginagalaw ang default na ruta. Ang manual ng OpenVPN 2.6 ay inilalarawan ito bilang pagdaragdag ng direktang ruta patungo sa isang DHCP server na wala sa lokal na subnet, kaya lumalabas ang trapiko ng lease sa labas ng tunnel, at binabanggit na ang gawi ay ipinatupad sa mga client ng Windows at maaaring hindi available sa ibang lugar.

Ang dahilan ng pag-iral nito ay mekanikal. Kapag nahuli na ng mga kalahating default na ruta ang palabas na trapiko, ang isang pag-renew ng DHCP na nakadirekta sa isang server sa pisikal na network ay iruruta sa loob ng tunnel maliban kung may magpirmi sa address na iyon sa tunay na interface. Pinipirmi ito ng flag.

Ano ang tunay na saklaw ng pagbubukod

Ang isang halimbawang talahanayan pagkatapos ng matagumpay na koneksyon ay nagpapakita ng hugis: dalawang kalahating default na ruta sa tunnel, at isang host route para sa DHCP server sa pisikal na gateway. Basahin ito bilang hugis, hindi bilang iyong sariling mga address.

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

Ang ikatlong linyang iyon ay nagpangalan ng isang destinasyon. Hindi ito setting ng resolver, hindi ito pangkalahatang pahintulot para sa lokal na network at hindi ito panuntunan ng labasan sa server. Ang isang telepono sa isang cellular carrier ay maaaring walang DHCP server na matukoy ng client sa ganitong paraan, at kaya walang binabago ang flag doon.

Tingnan kung ano talaga ang ini-install ng client

Ibahin ang isang opsyon na nakasulat sa profile, isang opsyong inaalok ng server at isang rutang talagang inilapat ng may-ari ng koneksyon. Ang isang client na tumatanggi sa isang flag na hindi sinusuportahan ay maaaring panatilihin ang natitirang configuration, kaya umaangat ang tunnel at literal na wala ang pagbubukod. Basahin ang log ng client mismo at ang resultang routing table sa halip na ipagpalagay na ang linya sa file ay nagkabisa. Tatlo sa mga ito ay maaaring totoo nang sabay, at ang huli lamang ang nagbabago kung saan talaga pumupunta ang mga packet.

Panatilihing magagamit din ang ruta patungo sa endpoint ng VPN sa parehong oras. Ang pagbubukod sa endpoint na iyon ay ibang pangangailangan kaysa sa pagbubukod ng DHCP, at kung wala ito ay maaaring mahuli ng tunnel ang transportasyong nagpapanatili nito.

Para sa isang destinasyon ng application, suriin ang epektibong paghahanap sa kontekstong nabibigo ito. Ang mas tiyak na lokal na ruta, pagruruta ayon sa patakaran at mga pagbubukod bawat application ay binabago ang sagot, kaya ang pagkakaroon ng dalawang kalahating default na ruta ay hindi isang imbentaryo ng bawat daloy.

Ang natitirang bahagi ng daan ay wala sa flag na ito

Kailangan pa rin ng server ng pahintulot na ipasa ang trapiko ng internet ng client at isang kaayusan ng labasan na makapagbabalik nito. Walang ruta sa panig ng client ang lumilikha ng kulang na pagpapasa o pagsasalin ng pinagmulan sa server, at walang flag ang pumapalit sa gumaganang daan ng pagbabalik.

Ang paglutas ng pangalan at IPv6 ay bawat isa ay nangangailangan ng sarili nitong patakaran. Ang pagpapalit ng IPv4 ay hindi nagtuturo sa resolver patungo sa isang server sa panig ng tunnel at hindi nagtatatag ng saklaw ng IPv6, at ang client na nagre-redirect lamang ng v4 ay iniiwan ang landas ng v6 na hindi ginalaw.

Ihambing ang isang inaprubahang walang pinsalang kahilingan sa isang gumaganang at isang nabibigong daan ng access, habang ang profile at destinasyon ay nakapirme. Itala kung ang pagkakaiba ay nasa paglutas ng pangalan, pagtatatag ng tunnel, pagpili ng ruta o ipinasa na trapiko, at itago ang sagot kasama ng profile. Ang talaang iyon ang pumipigil sa susunod na tao na sisihin ang DHCP sa isang problemang hindi nito maaabot.