Ang split tunneling para sa mga hotspot client ay hindi pagbubukod kada app
Ang pagbubukod ng app sa VPN ay nagbabago lamang ng telepono. Ang nakakonektang laptop ay nangangailangan ng sariling tuntunin sa pagpapasa, itinutugma sa pinagmulan, destinasyon at NAT.
Dalawang pangangailangan na magkatulad ang tunog ay hindi magkatulad: «ibukod ang app na ito sa VPN» at «ipadala ang isang destinasyong ito sa labas ng VPN para sa laptop sa aking hotspot». Binabago ng una kung paano pumipili ng network ang isang socket sa telepono. Kailangang baguhin ng pangalawa ang desisyon sa pagpapasa para sa isang packet na dumating mula sa ibang device matapos itong tanggapin ng telepono. Ang paghahalo ng dalawa ang dahilan kung bakit ang isang hotspot client ay nauuwi sa isang pagbubukod na palaging para lamang sa sariling browser ng telepono.
Dalawang subsystem ang may-ari ng dalawang tanong
Pinaghihiwalay ng Android ang networking ng app at ang tethering. Ang mga socket ng app ay itinatalaga sa isang network ng connectivity stack, at ang isang VPN app ay nagpapasya kung alin sa sarili nitong mga socket ang papasok sa tunnel. Ang mga naipasang packet mula sa nakakonektang client ay pinangangasiwaan ng tethering subsystem, na humihiling sa netd ng mga ruta, patakaran sa patakaran at pagsasalin sa downstream interface.
Ang pagbubukod kada app ay sinusuri kapag nagbukas ng socket ang isang app. Ang naipasang packet ay hindi kailanman umabot sa pagsusuring iyon, dahil hindi ito nagmula sa isang app socket sa device na ito. Iyon ang buong dahilan kung bakit hindi magpalitan ang dalawang setting, at hindi ito bug sa alinman sa kanila.
Ano ang talagang binabago ng pagbubukod kada app
Ang builder ng VpnService ay maaaring pangalanan ang mga pakete na nananatili sa labas ng tunnel gamit ang addDisallowedApplication, o pangalanan ang tanging mga pakete na pinapayagan sa loob gamit ang addAllowedApplication. Pagkatapos ay nagbubukas ang mga app na iyon ng socket sa pinagbabatayang network habang ang VPN ay patuloy na nagmamay-ari ng default na ruta para sa lahat ng iba pa.
Eksakto ang saklaw: ang sariling mga socket ng pakete, sa device na ito, hangga’t nakataas ang tunnel. Wala itong sinasabi tungkol sa naipasang trapiko, wala tungkol sa pangalawang device at wala tungkol sa mga packet na ipinapadala ng system sa ngalan ng tethering.
Hindi rin ito kontrol sa destinasyon. Ang pagbubukod sa isang browser ay nagbubukod sa bawat address na naaabot ng browser na iyon, kabilang ang isa na gusto mong panatilihin sa loob ng tunnel. Kapag ang pangangailangan ay nagpangalan ng destinasyon sa halip na app, ang pumipili ng app ay ang maling kasangkapan ayon sa pagkakabuo.
Paano lumilitaw ang isang naka-tether na packet sa telepono
Dumarating ang packet ng client sa hotspot interface na may pribadong source address na itinalaga ng telepono, sabihin nating 192.168.43.20, at pampublikong destinasyon. Upang maipasa ito, kailangan ng telepono ng ruta patungo sa upstream link at tuntunin sa pagsasalin upang mahanap ng mga sagot ang daan pabalik, dahil walang kahulugan ang pribadong address ng client sa cellular network.
Ipinapahayag ng Android iyon sa mga patakaran sa patakaran na pumipili ng routing table, at muling binubuo ng netd ang mga kaugnay na talahanayan at tuntunin kapag nagbago ang mga network at VPN. Ang numero ng talahanayan, priyoridad ng tuntunin o pangalan ng interface na kinopya mula sa post sa forum, o mula sa parehong modelo sa mas lumang release, ay hindi nagtatatag ng pangmatagalang pagmamay-ari. Ang muling pagbuo ring iyon ang dahilan kung bakit ang isang tuntuning isinulat sa kamay ay maaaring gumana nang isang oras at huminto pagkatapos ng susunod na muling pagkonekta.
Anong patakaran ang talagang kailangan ng pagbubukod sa hotspot
Isulat ang desisyon bilang pinagmulan, destinasyon at nilalayong landas bago hawakan ang isang tuntunin. Ang pinakamaliit na anyo para sa isang aprubadong destinasyon ay ganito:
| Source | Destination | Intended path |
|---|---|---|
| One authorized hotspot client | One approved public service address | Ordinary cellular uplink |
| The same client | All other covered destinations | Shared VPN |
| The phone's own apps | Their existing destinations | Unchanged phone policy |
Dapat kumpleto ang dalawang direksyon. Ang direktang sangay ay nangangailangan ng magagamit na ruta sa pamamagitan ng cellular upstream link na kasalukuyang aktibo; ang VPN branch ay nangangailangan ng ruta ng tunnel kasama ang pahintulot na makapagpasa. Anumang pagsasalin ng pinagmulan ay dapat tumugma sa exit na pinili mo, dahil ang NAT na inilapat sa isang tunnel interface ay nagpapakita ng address ng tunnel at hindi ang cellular, at ang daan pabalik ay hindi naaayon sa daan palabas.
Dapat maabot ng mga sagot ang parehong downstream client sa pamamagitan ng sinusubaybayang estado o tahasang ruta, at ang counter ng mga papalabas na packet ay walang pinatutunayan sa mga iyon. Panatilihin ding nasa labas ng saklaw ng pagbubukod ang sariling panlabas na transportasyon ng VPN, kung hindi ay namamana ng mga carrier packet ng tunnel ang patakarang isinulat para sa web request ng client.
Ang isang nahuli na address ay hindi destinasyon
Ang isang address na IPv4 na nabasa mula sa browser ay isang snapshot. Ang malalaking serbisyo ay sumasagot mula sa anycast o mula sa umiikot na set ng edge address, marami ang dual-stack, at ang daloy ng pag-login ay maaaring tumama sa mga host ng authentication at telemetry na hindi kailanman ipinapakita ng pahina. Ang pagbubukod na itinayo sa paligid ng address na nagkataong nakita mo ay masisira sa susunod na muling balansehin ng serbisyo.
Gamitin ang mga dokumentadong address ng may-ari ng serbisyo, o isang saklaw na inilathala nito, at isaalang-alang ang dalawang pamilya ng address. Kung hindi maipahayag ang pangangailangan bilang isang matatag na set, malamang na tanong ito sa patakaran para sa serbisyo at hindi isang pakulo sa pagruruta sa telepono.
I-verify mula sa downstream na bahagi
Tatlong pagsusuri, sa ganitong pagkakasunod-sunod: ang piniling serbisyo mula sa laptop, isang ordinaryong destinasyon na dapat manatili sa loob ng VPN, at isang app sa telepono na dapat manatiling hindi apektado. Pagkatapos ay ulitin pagkatapos ng muling pagkonekta at pagkatapos ng pagbabago ng upstream link, dahil doon muling binubuo ang mga talahanayan ng patakaran.
Kung hindi kayang panatilihin ng implementasyon ng pagbabahagi ng telepono ang kontratang iyon sa buong muling pagkonekta, ilipat ang piling patakaran sa isang sinusuportahang downstream router sa halip na mag-ipon ng root na tuntunin sa aparato. Ang isang router ay makapagpapahayag ng pagtutugma ng pinagmulan at destinasyon na may matatag na may-ari, at ang dokumentasyon ng tethering module ang tamang sanggunian para sa aktwal na ginagawa ng telepono.