ولې Android VpnService د ټرافیک یوه برخه نیسي او نه ټول

په VpnService کې هېڅ شی په خپله ټرافیک نه نیسي۔ دا له سیستم څخه tun انټرفیس غواړي، هغه انټرفیس ته د پتو او لارو ټولګه ورکوي، او له هغې لحظې راهیسې کرنل هره هغه پاکټ چې له دغو لارو سره سمون لري په یوې دوتنې ډیسکریپټر کې کاپي کوي چې اپلیکیشن یې لوستلی شي۔ د اپلیکیشن کوډ هغه پاکټونه چې لارو نه دي ټاکلي هېڅکله نه ویني، نو د تونل حد د پروګرام کولو له پوښتنې مخکې د لارښوونې جدول پوښتنه ده۔ له همدې کبله یو شان د خدمت پلي کول کولای شي په یو تلیفون کې هره جریان وڅښي او په بل کې یوازې یوه برخه، او له همدې کبله د لارې زیاتول ځینې وختونه هغه تونل جوړوي چې مات ښکارېده۔ هغه څه چې ترلاسه کوئ هماغه دي چې اعلان کړي مو وو، پرته له هر هغه څه چې جوړوونکي په خاموشۍ رد کړل۔

لارې ټاکي چې کوم پاکټونه راځي

Builder.addRoute(prefix, prefixLength) د VPN شبکې د لارښوونې جدول کې یو مخکښ ځای پرځای کوي۔ سیستم هغه شبکه د حد دننه اپلیکیشنونو لپاره اصلي ګڼي، نو د هغې ننوتنې د فزیکي شبکې له اصلي لارې مخکې کتل کېږي او سمون لرونکی مخکښ د جریان د اړولو لپاره بس دی۔ نو د 0.0.0.0/0 لپاره لاره IPv4 په بشپړه توګه اخلي، چاپګر، د cast هدف او د راؤټر اداري پاڼه هم پکې شامل دي۔

هغه مراجعین چې دا پوښښ پرته له فزیکي اصلي ننوتنې له منځه وړلو غواړي، پرځای یې د 0.0.0.0/1 او 128.0.0.0/1 جوړه کاروي۔ دوه ډېر ځانګړي لارې اصلي لاره ماتوي، یوځای د پتې ټول فضا پوښي، او د تلیفون خپله اصلي ننوتنه په جدول کې پاتې کېږي د هغو ساکټونو لپاره چې لا هم فزیکي شبکې ته تړلي دي۔

پتې او د DNS ننوتنې له هماغه جوړوونکي راځي او بېلې پوښتنې ته ځواب وایي۔ addAddress انټرفیس ته د مخکښ اوږدوالي سره پته ورکوي، او addDnsServer هغه حل کوونکی ځای پرځای کوي چې د حد اپلیکیشنونه به یې د انټرفیس له لارې پوښتنه کوي۔ دواړه کورنۍ کولای شي په یوه انټرفیس کې وي، نو یوازې IPv4 لارو ټولګه د IPv6 پتې ترڅنګ هغه ترتیبات دي چې سم لوستل کېږي او بیا هم تویېږي۔ که تاسو هغه کورنۍ لاره ورکړئ چې انټرفیس پکې پته نه لري، کرنل د هغو پاکټونو لپاره سرچینه پته نه لري او هغوی هېڅکله ډیسکریپټر ته نه ښکاري۔

establish() څه بېرته راولي

establish() ParcelFileDescriptor بېرته راولي، یا null کله چې اپلیکیشن اجازه نه لري۔ null د شبکې تېروتنه نه، بلکې د رضایت حالت دی: VpnService.prepare() باید مخکې null راوړی وي، یا کاروونکي باید د غوښتنې مخکې د سیستم خبرې اترې منلې وي۔ رضایت د خدمت د چلېدو پر مهال بېرته اخیستل کېدای شي، او انټرفیس پرته له کوم بېرته غږ ستاسو د لوستنې حلقې ته ستاسو د پښو لاندې بندېږي۔

ډیسکریپټر بندوونکی نه دی پرته له دې چې تاسو بل څه ووایاست، نو لوستنه پرته له ډاټا سمدلاسه بېرته راځي پرته له دې چې تار ودرول شي۔ د بندوونکي ساکټ لپاره لیکل شوې حلقه یوه هسته سوزوي، او هغه حلقه چې تشه لوستنه مرګونکې ګڼي په بې کاره ثانیه کې تونل څیرې کوي۔ Builder.setBlocking(true) هغه چلند بدلوي، او بیه یې هغه تار دی چې د لوستنې دننه انتظار کوي۔

د لارې او پتې دلیلونه د LinkAddress ارزښتونو په توګه تاییدېږي، او د multicast هدفونه لکه 224.0.0.0/4 سمدلاسه ردېږي۔ نقطې-تر-نقطې tun انټرفیس هم د خپرېدو ډومین نه لري، نو له هغې لارې د multicast موندنې لپاره بله لاره نه، بل ډول ډیزاین ته اړتیا ده۔ د کتنې لړلیک VpnService.Builder دی، د دې له مخې چې یوه غوښتنه ناڅاپه پرېښودل شوې ده، دمخه۔

د هر اپلیکیشن حد ټولګه تنګوي، نه تونل

له API 21 راهیسې جوړوونکی addAllowedApplication او addDisallowedApplication مني، او دواړه لړلیکونه په یو جوړوونکي کې یو بل ردوي۔ د اجازې لړلیک د هغو پاکټونو لپاره تونل موجود ساتي پداسې حال کې چې نور ټول فزیکي شبکه ساتي؛ د منع لړلیک پرته له نومول شوو پاکټونو ټول نیسي، چې مراجعین یې د ویشل شوي تونلینګ په توګه وړاندې کوي۔ له API 21 مخکې د پلیټفارم هېڅ میکانیزم نشته، او د هر اپلیکیشن چلند له دریمې ډلې مراجعینو راغلی و چې په خپل لېږدوونکي کې د UID له مخې فلټر کاوه۔ دا توپیر د غلطیو د سمولو پر مهال مهم دی، ځکه چې د یو پاکټ د اجازې لړلیک سره د اپلیکیشن تونل نږدې هېڅ ټرافیک نه تولیدوي او دا سم چلند دی، نه مات شوې لاره۔

هر څومره چې حد وي، هغه ساکټ چې ستاسو اپلیکیشن د VPN سرور ته پرانیزي باید د هغه تونل له لارې تیر نشي چې دا یې جوړوي۔ VpnService.protect(socket) هغه ساکټ لاندې شبکې ته تړي ترڅو د هغې پاکټونه tun وسیله پرېږدي۔ که غوښتنه پرېږدئ، لاس ورکول هغه انټرفیس څښي چې باید پورته کړی یې وای۔

VpnService.setUnderlyingNetworks دې ته د سیستم د ویلو له لارې حلقه بندوي چې کومه فزیکي شبکه تونل وړي۔ هغه ارزښت ټاکي چې VPN نورو اپلیکیشنونو ته اړیکه څنګه راپور کوي، او null یا زوړ ارزښت د هغه نښلول شوي تونل عادي لامل دی چې د تلیفون پاتې برخه یې آفلاین ګڼي۔ هغه تازه کړئ کله چې لاندې شبکه بدله شي، نه یوازې په پیل کې۔

د کنټرول جمعې او MTU: چېرې چې سمه لاره بیا هم ناکامېږي

کله چې پاکټونه ورسیږي، د پاکټ په کچه دوه تفصیلات ټاکي چې یو څه له سره تر سره کار کوي که نه۔ لومړی سرچینه پته ده: د انټرفیس څو پتو سره کېدای شي کرنل هغه پاکټونه ولېږي چې لومړی یې وړي، نو لېږدوونکی چې سرلیکونه بیا لیکي باید پته او هغه کنټرول مجموعه چې د هغې پوښښ کوي سمه کړي۔

دویم د کنټرول جمعې حد دی۔ کله چې اپلیکیشن خپله TCP یا UDP پاکټونه جوړوي، کنټرول مجموعه یو ډول-سرلیک پوښي چې سرچینه پته، هدف پته، پروتوکول شمېره او د لېږد اوږدوالی لري، او د هغوی له جملې هر یو پرېښودل هغه پاکټونه ورکوي چې رسیږي او غورځول کېږي۔ هغه ناکامي د هغه ځواب وروسته د وخت د پای ته رسېدو په څېر ښکاري چې هېڅکله نه راځي، او دا ډېرو خلکو ته لاره ورښیي چې بېرته لارو ته وګرځي۔ setMtu د انټرفیس MTU ټاکي، او هره لوستنه یو بشپړ IP پاکټ بېرته راولي، نو د بایټ جریان لپاره لیکل شوی بفر به ستاسو تحلیل ټوټه ټوټه کړي، نه پاکټ۔

د طبقو جداولو یوه کتنه

د دې لپاره چې وپوهېږئ حد چېرې غلط شو، طبقې په ترتیب سره وازموئ۔ له وسیلې وپوښتئ چې VPN شبکه واقعاً کومې لارې لري، بیا وګورئ چې یوې پېژندل شوې پتې ته جریان د ډیسکریپټر پر لوستنې ښکاري که نه، بیا وګورئ چې ستاسو لېږدوونکی چې پاکټ لېږي ښه جوړ شوی که نه۔ د لارې ستونزه ډیسکریپټر ته هېڅ نه ښیي، پداسې حال کې چې د کنټرول جمعې ستونزه هغه پاکټ ښیي چې رسیږي او ورکېږي۔

که ډیسکریپټر ته هېڅ نه رسیږي، شکمن د لوستونکي نه بلکې د لارو ټولګه ده: مخکښونه تایید کړئ، ډاډ ترلاسه کړئ چې په هماغه کورنۍ کې پته شته، او ډاډ ترلاسه کړئ چې اپلیکیشن ستاسو ټاکلي حد دننه دی۔ که پاکټونه ډیسکریپټر ته رسیږي خو هېڅ بېرته نه راځي، بیا د لارې له لمس کولو دمخه protect() او لاندې شبکې ارزښت وګورئ۔ که لرې اړخ د خراب شوو پاکټونو راپور ورکوي، کنټرول مجموعه او MTU هغه ځایونه دي چې باید ورته وکتل شي۔ په هر طبقه کې یوه کتنه نیمه ورځه اټکل خوندي کوي۔