په Android VpnService کې د ټونل وېش: په رښتیا څه لارښوونه کولی شئ

په VpnService اپلیکیشن کې د ټونل وېش په څو ټاکلو ځایونو کې ماتېږي او د هر یوه ترمیم بېل دی. کلاینټ یوازې یو ناکام هدف ښیي، نو لومړی کار دا دی چې ومومئ کومه پوله وهي: هغه لارې چې builder ترلاسه کړې، هغه پروکسي چې تصدیق یې نه شئ کولی، هغه resolver چې یوازې اعلان کړی، یا هغه اپلیکیشن لیست چې پلیټ فارم هر کاروونکي ته پلي کوي. همدې لپاره زه څلور پړاویزه څېړنه ساتم. هغه لاندې ترتیب ته ځي او په لومړنۍ ناکامۍ بندېږي.

تایید کړئ builder پلیټ فارم ته څه ورکړل

VpnService.Builder د اعلانونو لیست دی. establish() د مجازي انټرفیس لپاره ParcelFileDescriptor بېرته راګرځوي، او پلیټ فارم هغه توضیح کوونکي ته یوازې هغه ټرافیک لېږي چې د addAddress او addRoute مخکښو سره سمون لري؛ addDnsServer کلاینټونو ته وایي کوم resolver وپوښتي. هغه هدف چې ستاسو له ټولو اضافه شوو مخکښو بهر وي، هېڅکله ستاسو اپلیکیشن ته نه رسېږي، هر څه چې انټرفیس ژمنه وکړي. همدا یوه حقیقت د کوډ د بدلون دمخه د مات شوي ټونل وېش ډېرې راپورونه تشریح کوي.

هغه لیستونه ولیکئ چې ستاسو builder د پتو، لارو او DNS جوړ کړي، بیا یې له ناکامو هدفونو سره پرتله کړئ. د مدیریت هوسټ لپاره ورک /32 له مات شوي ټونل څخه ډېر عام دی. که لیست سم وي، مخکې ولاړ شئ؛ که غلط وي، پاتې چک لیست بې ګټې هڅه ده.

excludeRoute یوازې له API 33 راهیسې دی

د هدف پر بنسټ ایستل هغه غوښتنه ده چې ډېری وخت د ملاتړ تار ګرځي. builder.excludeRoute(IpPrefix) په API 33 کې راغی؛ تر دې مخکې یوازینی ملاتړ شوی نږدېوالی دا دی چې د ایستل شوي مخکښ پرته هر څه ته لارې اضافه کړئ، یعنې بشپړوونکي مخکښې پخپله حساب کړئ. دواړه غږونه د هینې انځور نه دي: یو د انټرفیس له لارې ټولګې کموي، بل ټولګه له صفر جوړوي، او زوړ وسیله ناپېژندل شوی غږ غورځوي یا په خاموشۍ کې پرې تېرېږي. پر Build.VERSION.SDK_INT څانګه جوړه کړئ او دواړه لارې په ریښتیني هارډویر وازموئ.

کله چې بشپړوونکي حسابوئ، د مخکښو سمون ته پام وکړئ. په /16 لار کې دننه /24 ایستل هغه پوښوونکي مخکښې غواړي چې واقعاً پاتې برخه بیانوي، نه یوه خرابه /8. وروستی لیست ولیکئ او ډاډ ترلاسه کړئ چې ایستل شوی هوسټ لا هم د ټونل بهرنۍ لارې حل کېږي.

د پروکسي اعتبارنامې څرګندېدلی نه شي

setHttpProxy(ProxyInfo) انټرفیس HTTP یا SOCKS پروکسي ته اړوي، او PAC URL کولی شي هر هدف لپاره د دواړو ترمنځ غوره کړي. نه ProxyInfo او نه PAC بڼه کاروونکی نوم او پټنوم لري، نو د تصدیق غوښتونکې پروکسي د پلیټ فارم API څخه بهر پاتې کېږي. هغه اپلیکیشنونه چې ورته اړتیا لري معمولاً userspace سټک، tun2socks یا ورته انجن ځای پرځای کوي او پخپله د 407 ننګونې ځواب ورکوي.

دې غوراوي پایلې لري. userspace سټک یوازې هغه ټرافیک وینې چې تاسو ورته لارښوونه کوئ، نو باید په همدې توضیح کوونکي پوله کې ژوند وکړي، او خپل uplink ساکټ لپاره هماغه protect() غوښتنه په میراث وړي. protect() پرېږدئ نو ټونل خپله ټرانسپورټ نیسي، چې د لومړي بستې وروسته د بندېدونکي لاس اچوونې په څېر ښکاري. له هغه پروکسي سره وازموئ چې اعتبارنامې غواړي، ځکه پرانیستی پروکسي د پلیټ فارم په لار تېرېږي او هېڅ نه ثابتوي.

د هر اپلیکیشن لیستونه او DNS هم اعلانونه دي

Builder دواړه addAllowedApplication او addDisallowedApplication لري، او دواړه یو بل ردوي: دواړه غوږ کول استثنا غورځوي. په هر حال لیست د انټرفیس په ترتیب کې هر کاروونکي ته پلي کېږي، نو د کاري پروفایل اپلیکیشن ستاسو د ټونل پرځای د کاري پروفایل ټونل لخوا اداره کېږي. هغه څه چې هېڅ API نه درکوي، د بل اپلیکیشن پر پرېکړې کنټرول دی: نه شئ کولی له بهر څخه بسته خپل ټونل ته ورټېله کړئ، او نه شئ کولی لا فعال VPN وتړئ یا بیا تنظیم کړئ.

DNS هماغه بڼه تعقیبوي. addDnsServer د resolver پته اعلانوي؛ دا ستاسو اپلیکیشن ته اجازه نه ورکوي چې پوښتنو ته ځواب ووایي. که غواړئ نومونه پخپله حل کړئ، resolver وچلوئ او پته یې ټونل ته لارښوونه کړئ. هغه اپلیکیشنونه چې ثابت هوسټ نوم ته DoT یا DoH کاروي کولی شي ستاسو اعلان شوې پته واوړي، نو د نومونو حل د غوره هڅې په توګه وګڼئ پرته له دې چې د پوښتنې لاره هم بندوئ.

Manifest، always-on او څلور پړاویزه ازموینه

وړتیا په manifest کې اعلانیږي: BIND_VPN_SERVICE، android.net.VpnService intent فلټر، او foreground خدمت که ټونل باید په شالید کې پاتې شي. Always-on VPN سربېره پر دې پاک onRevoke غواړي، ځکه سیستم هغه وخت غږ کوي چې کاروونکی تنظیمات بدلوي یا بل اپلیکیشن کنټرول اخلي.

څېړنې په ترتیب ترسره کړئ او په لومړنۍ ناکامۍ ودروئ. لومړی، هغه د پتو، لارو او DNS لیستونه چې builder ته ورکړل شوي بهر وایستئ. دویم، تایید کړئ چې establish() توضیح کوونکی بېرته راګرځولی او د لېږد ساکټ ساتل شوی دی. درېیم، په شمول شوې مخکښه کې یو هدف او په ایستل شوې مخکښه کې بل وغواړئ. څلورم، دا وګورئ چې کوم resolver واقعاً ځواب ورکړ، د هغه هوسټ نوم په پوښتنه کولو چې یوازې ستاسو resolver یې حل کولی شي.

بشپړه شوې لاس اچوونه د وروستیو پړاوونو هېڅ یو نه ثابتوي. هره څېړنه یوه طبقه جلا کوي، نو په دویم پړاو کې بریا د څلورم په اړه هېڅ نه وایي.

د VpnService.Builder مرجع د builder ټوله سطحه لیستوي. هر څه چې له دې بهر ورته اړتیا لرئ بل API، بل اپلیکیشن یا ستاسو خپل userspace سټک دی، او هغه د ټونل وېش خطا نه، بلکې د ډیزاین پرېکړه ده.