Karamihan ng full-tunnel setup ay nagpapadala ng bawat packet sa VPN, at ang redirect-gateway ang direktiba na nagpapangyari nito. Ang isang destinasyon ay maaari pa ring ihiwalay. Ang pagdaragdag ng host route para sa address na iyon gamit ang net_gateway placeholder ay nagsasabi sa kliyente na maabot ito sa pamamagitan ng orihinal na gateway ng makina, habang ang lahat ng iba ay patuloy na gumagamit ng tunnel.

Mukhang walang panganib ang linya at madalas ay ganoon nga, ngunit isang tanong lang ang sinasagot nito: saan pupunta ang mga packet para sa eksaktong IPv4 address na iyon. Hindi nito binabago ang DNS, IPv6, patakaran ng firewall o kung aling proseso ang nagbukas ng koneksyon, at alinman sa mga ito ay maaaring tahimik na pumawi sa pagbubukod.

Ano ba talaga ang tinutukoy ng net_gateway

Ang profile entry para sa pagbubukod na iyon ay isang linya: route 198.51.100.77 255.255.255.255 net_gateway. Ang unang address ay placeholder ng dokumentasyon para sa destinasyon, ginagawa itong host route ng mask, at pinapangalanan ng huling token ang placeholder ng gateway. Niresolba ng OpenVPN ang mga gateway placeholder kapag nag-i-install ito ng mga ruta. Ang vpn_gateway ay nangangahulugang gateway ng tunnel mismo, ang malayong bahagi ng VPN link. Ang net_gateway ay nangangahulugang default gateway na mayroon ang host bago binago ng VPN ang anuman, na karaniwang ang lokal na router sa pisikal na network.

Ang ikatlong placeholder, remote_host, ay tumutukoy sa address ng VPN server, at mayroon ito upang maabot ng tunnel ang server sa pisikal na landas. Ang paghahalo ng tatlong ito ang pinakakaraniwang dahilan kung bakit ang isang pagbubukod ay napupunta sa maling lugar o hindi na-i-install.

Binabasa ang halaga sa oras ng pagkonekta, hindi isinusulat sa file. Kung lumipat ang makina sa ibang network, nagbabago ang gateway bago ang VPN at sinusundan ng ruta ang bago. Iyon ang karaniwang gusto mo, ngunit nangangahulugan din itong nakadepende ang pag-uugali ng pagbubukod sa network kung saan nagsimula ang kliyente.

Bakit nananalo ang host route sa default ng tunnel

Ang routing ay pinagpapasyahan ng pinakaspesipikong tugmang prefix. Ang redirect-gateway def1 ay karaniwang hindi pinapalitan ang default route; nagdaragdag ito ng dalawang kalahati, isang ruta para sa ibabang kalahati ng address space at isa para sa itaas, kaya nananatili ang orihinal na default route para sa ibang gamit. Mas malawak ang mga kalahating iyon kaysa sa isang address.

Ang ruta para sa isang address na may mask 255.255.255.255 ay isang /32, na siyang pinakamatinding spesipiko na kayang ibigay ng IPv4. Kapag sinusuri ang packet para sa address na iyon, tumutugma ang /32 at nananalo kahit alin ang unang na-install. Ito ang mekanismo sa likod ng pagbubukod, at gumagana ito nang pareho sa Linux, macOS at Windows hangga't tunay na umiiral ang ruta.

Nagdaragdag ang Windows ng ikalawang dimensyon. Kapag pantay ang pagkaspesipiko ng dalawang ruta, nananalo ang may mas mababang metric, at ang VPN adapter ay maaaring magdala ng interface metric na nagbabago ng resulta. Mas spesipiko pa rin ang /32 kaysa sa mga kalahati, kaya karaniwang nananatili ang pagbubukod, ngunit ang lumang ruta mula sa nakaraang session ay maaaring magbigay ng nakalilitong resulta kung pantay ang pagkaspesipiko nito.

Ano ang hindi sinasaklaw ng pagbubukod

Ang DNS ang unang puwang. Maaaring itulak ng kliyente ang panloob na mga setting ng resolver, at patuloy na gagamitin ito ng operating system para sa mga paghahanap. Ang aplikasyong niresolba ang pangalan bago kumonekta ay maaaring makatanggap ng panloob na address para sa serbisyong dapat dumiretso, o panlabas na address na tama ang resolba ngunit pagkatapos ay natitisod sa susunod na puwang.

Ang IPv6 ang pangalawa. Ang direktiba ng ruta ay humahawak lamang ng IPv4. Ang dual-stack na destinasyon ay maaaring mas gusto ang IPv6, na sumusunod sa tunnel o sa default na ruta ng IPv6 ng host depende sa patakaran, kaya hindi kailanman nagkakabisa ang pagbubukod ng IPv4. Kailangan mo ng tugmang ruta ng IPv6, o sadyang desisyong patayin ang IPv6 para sa kliyenteng iyon.

Ang saklaw ng aplikasyon ang pangatlo. Nakabatay sa destinasyon ang panuntunan, kaya bawat prosesong kumokonekta sa address na iyon ay gumagamit ng direktang landas, maging ito ang nasa isip mo o hindi. Sa kabaligtaran, ang isang website ay maaaring sumagot mula sa maraming address, kaya ang pagbubukod ng isang /32 ay hindi nagbubukod sa site. Kung ang tunay na pangangailangan ay routing kada aplikasyon, ang route table ng Community client ang maling kasangkapan.

Suriin ang pagbubukod nang hindi dinadaya ang sarili

Magsimula sa naka-install na ruta, hindi sa browser. Sa Linux, tanungin ang kernel kung aling ruta at susunod na hop ang gagamitin para sa partikular na address; sa Windows, basahin ang route table para sa /32 na iyon. Kumpirmahin na ang gateway ay ang pisikal at hindi ang tunnel. Kung wala ang entry, hindi naipatupad ang profile o walang pribilehiyo ang kliyente na baguhin ang mga ruta.

Pagkatapos ay subukan ang dalawang destinasyon. Ang kahilingan sa ibinukod na address ay dapat lumabas sa pisikal na interface, at ang kahilingan sa panloob na control address ay dapat pa ring gumamit ng tunnel. Ang pagsubok lamang sa ibinukod na address ay walang pinatutunayan tungkol sa natitirang bahagi ng tunnel, at ang pagsubok sa pampublikong website ay sumusubok sa address kung saan niresolba ang site na iyon, na maaaring hindi ang nasa panuntunan.

Sa huli, suriin ang mga kontrol na maaaring mangibabaw sa ruta. Ang kill switch sa panig ng kliyente o setting na block-outside-dns ng Windows ay maaaring magbawal ng direktang trapiko, na lumilitaw bilang koneksyong nabibigo kahit tama ang ruta. Huwag patayin ang mga kontrol na iyon para magmukhang gumagana ang pagbubukod; kung ipinagbabawal ng patakaran ang direktang landas, ang pagbubukod ay problema sa disenyo para sa may-ari ng serbisyong VPN.

Suriin muli pagkatapos kumonekta muli o magpalit ng network, dahil ang gateway bago ang VPN at ang magagamit na landas ay katangian ng sandali, hindi ng profile.

Kaugnay na mga artikulo