Downstream subnet vs desktop VPN: ibukod ang transit, hindi ang mga app

Isang makina, dalawang trabaho, isang firewall: isang Wi-Fi uplink, isang maliit na Ethernet subnet sa likod nito, at isang desktop VPN client na nag-aakala na lahat ng lumalabas sa makina ay lokal. Ang mga app na inilunsad nang lokal ay lumalabas sa lokal na output path. Ang mga device sa likod ng workstation ay dumarating sa Ethernet port at kailangan ng desisyon sa forwarding. Ang isang pagbubukod na isinulat para sa unang path ay hindi kailanman nakikita ang pangalawa, at iyon ang dahilan kung bakit nilalampasan ng browser ang tunnel samantalang ang mga device ay hindi.

Dalawang packet path, isang patakaran

Ang unang hilera ang inilalarawan ng karamihan ng gabay sa split-tunneling. Ang pangalawa ay isang router configuration na nagkataong nasa parehong makina. Ang pagsasanib ng dalawa sa isang mental na modelo ang pagkakamali; nagbabahagi sila ng kernel, hindi ng patakaran. Iguhit ang dalawang path bago i-edit ang anumang panuntunan, at ang natitirang disenyo ay nagmumula sa kung aling path ang kulang.

Ipinaliwanag din ng talahanayan kung bakit ang isang makina ay makapasa sa isang pagsubok at mabigo sa isa pa. Ang browser sa workstation ay nagpapatunay ng lokal na path; ang laptop na nakasaksak sa Ethernet port ay nagpapatunay ng forwarding path. I-validate ang bawat pagbabago sa pareho, kung hindi ay mananatiling hindi nasubukan ang pangalawa gaano man kadalas i-refresh ang browser.

Ano ang talagang inuuri ng pagbubukod ng app

Ang pagbubukod kada app ay karaniwang gumagana sa pamamagitan ng pagmamarka ng mga packet mula sa isang proseso o isang user at pagkatapos ay iruruta ang markadong trapiko sa labas ng tunnel. Iyon ay isang konstruksiyon ng lokal na output. Ang packet mula sa isang downstream device ay walang lokal na proseso, kaya hindi ito kailanman tumutugma sa selector, anuman ang selector.

Anuman ang selector, ang dalawang listahan ay hindi ang parehong listahan, at iyon ang buong punto. Inilalarawan ng gabay ng Mullvad para sa Linux ang mga marka na ginagamit ng firewall at patakaran sa routing nito, at ang mga halimbawa nito ay naka-target sa lokal na output; hindi sila sinusuportahang paglalarawan ng isang downstream router. Ang kopyahin ang mga ito ay nagbubunga ng makinang naniniwala na mayroon itong pagbubukod habang ipinapasa ang lahat sa tunnel.

Isulat ang kontrata ng transit

Pangalanan nang magkasama ang downstream source prefix at ang ingress interface, pagkatapos ay limitahan ang prefix na iyon sa ingress. Kung walang limitasyon, anumang device na makakaabot sa port ay maaaring mag-angkin ng ibinukod na address at lumabas sa bypass. Tratuhin ito bilang dalawang tanong: maaari bang gamitin ng mga host na ito ang uplink na ito, at maaari ba silang makarating sa workstation o sa mga pribadong saklaw ng tunnel? Ito ay karagdagang pahintulot, hindi side effect ng pagpili ng uplink.

Payagan ang forwarding, pagkatapos ay i-filter ito. Ang Linux gateway ay nangangailangan ng naka-enable na forwarding, mga panuntunang nagpapahintulot sa nilalayong trapiko sa dalawang direksyon, at alinman sa paitaas na return route o sadyang limitadong source translation. Ang NAT lamang ay hindi pumipili ng uplink at hindi nagbibigay ng daan sa isang filter; ito ay nagsusulat muli ng address pagkatapos ng mga desisyong iyon.

Ang pag-uuri para sa transit ay dapat mangyari bago ang desisyon sa forwarding route, ibig sabihin sa yugto ng prerouting at hindi output. Ang panuntunang inilagay pagkatapos ng desisyon ay maaari pa ring baguhin ang packet, ngunit hindi nito mababago kung saan naipadala na ito.

Ang mga marka ay pag-aari ng app na nagmamay-ari sa kanila

Ang mga halaga ng marka, bilang ng talahanayan at priyoridad ng chain ay bahagi ng patakaran ng app ng VPN, hindi walang hanggang constant. Ang isang matibay na network na umaasa sa pagpasok ng panuntunan sa isang talahanayang muling ginagawa ng ibang programa ay masisira sa susunod na update, kadalasan habang muling kumokonekta at hindi sa maginhawang oras.

Ang pagdaragdag ng pangalawang base chain na may accept verdict ay hindi kinakailangang manaig sa drop ng isang huling chain. Ang mga base chain ay may hook at priyoridad, at ang unang verdict sa pagkakasunod-sunod ang nananalo; ang accept sa isang chain ay hindi nagkakansela ng drop na naabot muna ng ibang chain. Tingnan ang buong set ng panuntunan at ang pagkakasunod-sunod ng patakaran sa routing, hindi ang nag-iisang counter na tumaas. Ang counter ay nagpapatunay na tumakbo ang isang panuntunan, hindi kailanman na ang verdict nito ang inilapat.

Isama, o ilipat ang subnet

Ang dalawang disenyo ay nagkakaiba sa kung sino ang nagmamay-ari ng bypass. Ang isang pinagsamang disenyo ay nagpapanatili ng isang makina at isang patakaran, sa halaga ng pagdepende sa lifecycle ng talahanayan ng app ng VPN at sa isang set ng marka na maaaring baguhin ng dokumentasyon nito. Ang isang nakalaang router para sa downstream network ay ganap na nag-aalis ng dependency na iyon: ang subnet ay may sariling uplink, at ang workstation ay nananatiling client na walang tungkulin sa forwarding.

Piliin ang pangalawa kapag ang downstream network ay dapat patuloy na gumana sa mga update ng VPN, o kapag walang makapagsubok ng pinagsamang patakaran pagkatapos ng bawat release. Piliin ang una lamang kapag ang integrasyon ay dokumentado at may nagmamay-ari nito.

I-verify ang hangganan sa apat na estado: konektado, muling kumokonekta, sadyang hinaharangan at itinigil. Suriin ang name resolution at ang dalawang address family sa bawat isa, dahil ang bypass na tumutulo ng DNS ay hindi ang pagbubukod na dinisenyo mo. Dapat patunayan ng pagsubok ang tumpak na hangganan, hindi lamang na may isang pahinang na-load.