Aplikaĵbaza kontraŭ celbaza split tunneling: kiun elekti

Aplikaĵbaza kaj celbaza split tunneling ne estas du agordoj por la sama tasko. Unu demandas, kiu procezo sendas paketon; la alia demandas, kien tiu paketo iras. Regulo konstruita por la unua demando silente fiaskas, kiam la trafiko venas de helppa procezo, kaj regulo por la dua fiaskas, kiam gastnomo solviĝas al adreso, kiun vi neniam listigis. Elektu la objekton, kiu kongruas kun la postulo, kaj pruvu ĝin per du testaj paketoj: unu devas uzi la tunelon kaj unu ne.

La du reguloj agas sur malsamaj tavoloj

Aplikaĵa regulo estas trudata super la reta tavolo, kontraŭ la identeco, kiun la operaciumo atribuas al la sendanto. En Android tio estas la UID malantaŭ pako, kaj la VPN-servo decidas laŭ UID, ĉu trafiko eniras la tunelon. Nenio pri la celo estas demandata, do la elektita aplikaĵo povas atingi ion ajn, kaj neniu alia aplikaĵo povas atingi la internan reton.

Celo-regulo estas trudata sur la paketo mem. La tunela interfaco posedas aron da prefiksoj, la enkursiga tabelo sendas kongruan trafikon en ĝin, kaj la sendanta procezo estas sensignifa. Tial celo-regulo kovras servon, printilon aŭ aro-taskon, kiun neniu memoris listigi, kaj tial ĝi ne povas esti esprimita kiel ĝuste ĉi tiu programo sur platformo, kies kliento neniam rigardas la procezon.

Aplikaĵaj reguloj taŭgas por poŝaj klientoj kaj administrataj agentoj

Android malkaŝas la elekton rekte: VpnService.Builder.addAllowedApplication() kaj addDisallowedApplication() prenas pakajn nomojn kaj trudas la decidon laŭ UID, kiel priskribite en la VPN-programista gvidilo de Android. iOS havas ekvivalenton per VPN-reguloj por unuopa aplikaĵo ligitaj al pakaĵ-identigiloj, kutime liveritaj de MDM-profilo anstataŭ tajpitaj permane.

Labortablaj klientoj estas la malforta punkto. Plej multaj Windows- kaj macOS-VPN-klientoj enkursigas laŭ celo kaj tute ne ofertas elektilon laŭ procezo, ĉar la tunela pelilo vidas paketojn, ne procezojn. Se via plano dependas de tuneligo de unu aplikaĵo sur tekkomputilo, kontrolu la faktajn kapablojn de la kliento antaŭ ol desegni ĉirkaŭ ĝi; eble vi elektas inter cellisto kaj dua maŝino.

Korolario, kiun homoj maltrafas: vi ne povas imiti aplikaĵan regulon per enkursigoj sur tiuj platformoj. Aldoni gastan enkursigon por la servilo de la aplikaĵo tuneligas la trafikon de ĉiuj al tiu servilo, inkluzive de la retumilo kaj la ĝisdatigilo.

Celo-reguloj taŭgas por subretaj listoj kaj atingeblo de lokoj

WireGuard faras la modelon eksplicita. AllowedIPs estas kriptoŝlosila enkursigo: interna paketo, kies celo falas ene de la listo de samtavolano, estas ĉifrata al tiu samtavolano, kaj ĉio alia eliras neĉifrite laŭ la normala vojo. Ne estas procezo por nomi kaj ne estas malklareco pri tio, kio estas inkluzivita.

OpenVPN atingas la saman lokon per la puŝita enkursiga tabelo. route-nopull malhelpas la servilon dikti enkursigojn, post kio klientflanka route 10.20.0.0 255.255.0.0 vpn_gateway kovras ĝuste la oficejan prefikson. IPv6 estas aparta deklaro en ĉiu el ĉi tiuj klientoj, kaj forgesi ĝin estas la plej ofta maniero liki ĉirkaŭ ĝuste aspektanta IPv4-divido.

Gastnomo ne estas enkursigo. Se la profilo ofertas domajnan kampon, traktu ĝin kiel nomon, kiun la kliento solvas unufoje, ne kiel konstantan adresaron; enhav-liveraj retoj kaj ŝarĝ-balanciloj donos morgaŭ malsamajn adresojn.

Kie ambaŭ modeloj rompiĝas: helpiloj, komunaj servoj, solviloj

Helpaj procezoj rompas aplikaĵajn regulojn tiel, ke ĝi aspektas kiel servila fuŝo. Retumila ĝisdatigilo, kraŝ-raportilo, sinkroniga servo kuranta kiel SYSTEM kaj WebView enigita en alian pakon estas ĉiuj apartaj identecoj, do tuneligo de la retumilo povas lasi la faktan peton ekster la tunelo. La malo estas same konfuza: ekskludita aplikaĵo, kiu vokas komunan bibliotekon ene de tuneligita procezo, ankoraŭ havas sian trafikon en la tunelo.

Celo-reguloj rompiĝas ĉe komunaj servoj kaj ĉe nomoj. Dosierkomunigoj, printiloj, interna DNS kaj la licencservilo ĉiuj vivas ĉe adresoj, do tunelo por unu aplikaĵo donas al la retumilo aliron dum la mapita disko restas morta. Tiu kovrado-diferenco ne estas cimo en iu ajn modelo, sed ĝi estas la kialo, ke tunelo por unu aplikaĵo tiel ofte produktas la VPN funkcias kaj la komunigo malaperis.

Solviloj tranĉas ambaŭ. Se la kliento agordas internajn DNS-servilojn sed la operaciumo uzas DNS per HTTPS al publika solvilo, la respondo venas de ekster la tunelo kaj la celo-regulo eble neniam kongruos. Kontrolu, kiu solvilo efektive respondis, antaŭ ol konkludi, ke la regulo malĝustas, kaj konfirmu ĉe la klienta flanko, ĉu ĝi entute instalas la tunelan solvilon. Divido, kiu lasas DNS ekster la tunelo, aspektas perfekta en la enkursiga tabelo kaj tamen fiaskas ĉe ĉiu interna nomo.

Agadplano: elekti, apliki, kontroli

Komencu de la postulo, ne de la menuo. Se la celo estas nur ĉi tiu aplikaĵo rajtas uzi la tunelon, vi bezonas aplikaĵajn regulojn kaj platformon, kiu subtenas ilin. Se la celo estas ĉi tiuj retoj estas atingeblaj tra la tunelo, vi bezonas prefiksojn. Se la respondo estas ambaŭ, efektivigu ilin kiel du apartajn regilojn kaj notu, kiu respondecas pri kiu fiasko.

Apliku la plej mallarĝan formon, kiun vi povas esprimi, poste kontrolu demandante la enkursigan tabelon anstataŭ la statusan ikonon de la kliento:

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

La unuaj du linioj nomas la interfacon, kiun vera celo uzus; wg show presas la agorditan prefiksliston; en Windows Find-NetRoute respondas la saman demandon, kiun la stako respondos kiam la paketo estos sendita. Se la interfaco estas la tunelo, la regulo kongruis.

Poste testu duan paketon, kiu devus esti ekskludita, de alia aplikaĵo, al la sama celo. Notu en la bileton la klientversion, la regulan tipon, la prefiksan aŭ pakan liston kaj la du observitajn rezultojn. Ĝuste tiu paro da rezultoj diras al la sekva inĝeniero, ĉu la politiko estas misagordita aŭ ĉu la trafiko neniam apartenis al ĝi.