Split tunneling na nakabatay sa app o sa destinasyon: alin ang pipiliin

Ang split tunneling na nakabatay sa app at sa destinasyon ay hindi dalawang setting para sa isang gawain. Ang isa ay nagtatanong kung aling proseso ang nagpapadala ng packet; ang isa pa ay nagtatanong kung saan papunta ang packet na iyon. Ang tuntuning ginawa para sa unang tanong ay tahimik na nabigo kapag ang trapiko ay galing sa isang helper na proseso, at ang tuntuning ginawa para sa pangalawa ay nabigo kapag ang hostname ay naresolba sa isang address na hindi mo kailanman inilista. Piliin ang bagay na tumutugma sa pangangailangan, pagkatapos patunayan ito sa dalawang test packet: isa na dapat gumamit ng tunnel at isa na hindi dapat.

Nagkakapareho ang dalawang tuntunin sa magkaibang layer

Ang tuntunin ng app ay ipinapatupad sa itaas ng network layer, laban sa pagkakakilanlang ibinibigay ng operating system sa nagpadala. Sa Android iyon ang UID sa likod ng package, at ang serbisyo ng VPN ang nagpapasya bawat UID kung papasok sa tunnel ang trapiko. Walang tinatanong tungkol sa destinasyon, kaya maaabot ng piniling app ang kahit ano at walang ibang app na makakaabot sa panloob na network.

Ang tuntunin ng destinasyon ay ipinapatupad sa packet mismo. Ang interface ng tunnel ay may hawak na set ng prefix, ipinapadala ng routing table ang tugmang trapiko doon, at walang kaugnayan ang prosesong nagpapadala. Kaya ang tuntunin ng destinasyon ay sumasaklaw sa isang serbisyo, printer o batch job na walang naalala na ilista, at kaya hindi ito maisasalarawan bilang eksaktong programang ito sa isang plataporma na hindi kailanman tinitingnan ng client ang proseso.

Ang mga tuntunin ng app ay bagay sa mobile client at managed agent

Direktang inilalantad ng Android ang pagpipilian: ang VpnService.Builder.addAllowedApplication() at addDisallowedApplication() ay tumatanggap ng mga pangalan ng package at ipinapatupad ang desisyon bawat UID, gaya ng inilarawan sa gabay ng developer ng VPN ng Android. Ang iOS ay may katumbas sa pamamagitan ng mga tuntunin ng VPN bawat app na naka-base sa mga identifier ng bundle, kadalasang ipinapamahagi ng isang MDM profile kaysa tinatype sa kamay.

Ang mga desktop client ang mahinang bahagi. Karamihan sa mga VPN client ng Windows at macOS ay nagru-route ayon sa destinasyon at wala talagang inaalok na tagapili bawat proseso, dahil ang driver ng tunnel ay nakakakita ng packet, hindi proseso. Kung ang plano mo ay nakadepende sa pag-tunnel ng isang aplikasyon sa laptop, tingnan ang aktwal na kakayahan ng client bago magdisenyo sa paligid nito; baka pumipili ka sa pagitan ng listahan ng destinasyon at pangalawang makina.

Isang bunga na hindi napapansin ng mga tao: sa mga platapormang iyon hindi mo maaaring tularan ang tuntunin ng app gamit ang mga ruta. Ang pagdaragdag ng host route para sa server ng app ay nagtu-tunnel sa trapiko ng lahat papunta sa server na iyon, kasama ang browser at ang updater.

Ang mga tuntunin ng destinasyon ay bagay sa listahan ng subnet at pag-abot sa mga site

Ginagawang tahasan ng WireGuard ang modelo. Ang AllowedIPs ay cryptokey routing: ang panloob na packet na ang destinasyon ay nasa loob ng listahan ng isang peer ay ine-encrypt patungo sa peer na iyon, at lahat ng iba ay lumalabas na hindi naka-encrypt sa normal na landas. Walang prosesong papangalanan at walang kalabuan kung ano ang kasama.

Nakarating ang OpenVPN sa parehong lugar sa pamamagitan ng itinulak na routing table. Pinipigilan ng route-nopull ang server na magdikta ng ruta, pagkatapos ay sinasaklaw ng route 10.20.0.0 255.255.0.0 vpn_gateway sa panig ng client ang eksaktong prefix ng opisina. Ang IPv6 ay hiwalay na pahayag sa bawat isa sa mga client na ito, at ang paglimot dito ang pinakakaraniwang paraan ng pagtagas sa paligid ng split IPv4 na mukhang tama.

Ang hostname ay hindi ruta. Kung ang profile ay may field ng domain, ituring ito bilang pangalang nire-resolba ng client nang isang beses, hindi bilang permanenteng saklaw ng address; ang mga content delivery network at load balancer ay magbibigay ng ibang address bukas.

Saan nababasag ang dalawang modelo: helper, shared service, resolver

Sinisira ng helper na proseso ang mga tuntunin ng app sa paraang mukhang sira ng server. Ang updater ng browser, crash reporter, serbisyo ng sync na tumatakbo bilang SYSTEM at WebView na naka-embed sa ibang package ay magkakaibang pagkakakilanlan, kaya ang pag-tunnel sa browser ay maaaring mag-iwan ng aktwal na kahilingan sa labas ng tunnel. Kabaligtaran din ang kalituhan: ang isang ibinukod na app na tumatawag ng shared library sa loob ng naka-tunnel na proseso ay dumadaan pa rin sa tunnel ang trapiko.

Nababasag ang mga tuntunin ng destinasyon sa mga shared service at sa mga pangalan. Ang mga file share, printer, panloob na DNS at licensing server ay nakatira sa mga address, kaya ang tunnel ng isang app ay nagbibigay ng access sa browser habang ang naka-map na drive ay nananatiling patay. Ang pagkakaibang iyon sa saklaw ay hindi bug sa alinmang modelo, pero iyon ang dahilan kung bakit ang tunnel ng isang app ay madalas magbunga ng VPN ay buhay at nawala ang share.

Tinatawid ng resolver ang dalawa. Kung ang client ay nagtatakda ng panloob na DNS server pero ang operating system ay gumagamit ng DNS over HTTPS patungo sa pampublikong resolver, galing sa labas ng tunnel ang sagot at maaaring hindi kailanman tumugma ang tuntunin ng destinasyon. Tingnan kung aling resolver ang talagang sumagot bago magpasya na mali ang tuntunin, at tiyakin sa panig ng client kung na-install ba nito ang resolver ng tunnel. Ang split na nag-iiwan ng DNS sa labas ng tunnel ay mukhang perpekto sa routing table at nabibigo pa rin sa bawat panloob na pangalan.

Pamamaraan: pumili, ilapat, i-verify

Magsimula sa pangangailangan, hindi sa menu. Kung ang layunin ay ito lamang ang app na makakagamit ng tunnel, kailangan mo ng mga tuntunin ng app at platapormang sumusuporta sa mga ito. Kung ang layunin ay maabot ang mga network na ito sa pamamagitan ng tunnel, kailangan mo ng mga prefix. Kung ang sagot ay pareho, ipatupad ang mga ito bilang dalawang hiwalay na kontrol at isulat kung alin ang may-ari ng aling kabiguan.

Ilapat ang pinakamakitid na anyo na maipapahayag mo, pagkatapos i-verify sa pamamagitan ng pagtatanong sa routing table kaysa sa status icon ng client:

ip route get 10.20.30.40
ip -6 route get 2001:db8:10::40
wg show wg0 allowed-ips
Get-NetRoute -DestinationPrefix 10.20.0.0/16
Find-NetRoute -RemoteIPAddress 10.20.30.40

Pinangalanan ng unang dalawang linya ang interface na gagamitin ng tunay na destinasyon; ipiniprint ng wg show ang naka-configure na listahan ng prefix; sa Windows, sinasagot ng Find-NetRoute ang parehong tanong na sasagutin ng stack kapag ipinadala ang packet. Kung ang interface ay ang tunnel, tumugma ang tuntunin.

Pagkatapos subukan ang pangalawang packet na dapat ibukod, mula sa ibang aplikasyon, patungo sa parehong destinasyon. Itala sa ticket ang bersyon ng client, uri ng tuntunin, listahan ng prefix o package at ang dalawang naobserbahang resulta. Ang pares ng resultang iyon ang nagsasabi sa susunod na inhinyero kung mali ang pagkaka-configure ng patakaran o hindi kailanman naging sakop nito ang trapiko.