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

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

افسانه 1: تونل تر هغه پورې ولاړ وي چې تاسو یې ودروئ

Android په یو وخت کې یو VPN انټرفېس ساتي۔ دوهم جوړ کړئ او پلیټفارم هغه په قطار کې نه ږدي: ستاسو غیر فعالوي او ستاسو په خدمت کې onRevoke() ته زنګ وهي۔ که ستاسو کوډ یوازې د تڼۍ په فشارولو څه ړنګوي، نیول شاته یو ډسکریپټر او یو لوستونکی تار پرېږدي، او بله پیل دواړه په میراث اخلي۔

د VpnService مرجع په صراحت سره وایي چې prepare() null بیرته راولي کله چې اپلیکیشن لا دمخه رضایت ولري، او Intent کله چې کارونکي باید لا تصویب کړي۔ هغه رضایت یوازې هغه وخت رسیږي چې تاسو نیت د startActivityForResult() له لارې وسپارئ۔ دا سپارل پرېږدئ او establish() null بیرته راولي، چې د اجازې ستونزې نه بلکې د غلي ناکامۍ په توګه لوستل کیږي۔

Always-on VPN یو مالک ورزیاتوي چې تاسو یې نه کنټرولئ۔ سیستم کولی شي تونل د بوټ وروسته یا د کریش وروسته بیرته راوړي، او هغه د کارونکي لخوا په لاس پیل شوي VPN اپلیکیشن مخکې کیږي۔ onRevoke() داسې جوړ کړئ چې ستاسو د عادي بندولو په څېر هماغه سرچینې بندې کړي، او هغه ته د کونج قضیې نه بلکې د اصلي بندولو لارې په توګه وګورئ۔ کارونکي VPN اپلیکیشنونه بدلوي؛ ستاسو کوډ باید هغه زغمي۔

افسانه 2: addRoute په سمه توګه هغه څه نیسي چې تاسو لیست کړي

لارې فیصله کوي چې کوم پاکټونه ستاسو ډسکریپټر ته رسیږي، او د ساحې تېروتنه هغه زړه بوګنونکې حالت جوړوي چې پکې ځینې ترافیک د تونل له لارې ځي او ځینې نه۔ addRoute("0.0.0.0", 0) ټول IPv4 اخلي، يعنې اوس هر پاکټ ستاسو ته رسیږي او باید مخې ته ولېږل شي یا پرېښودل شي۔ د یو هوسټ لپاره /32 نږدې هیڅ نه اخلي، او نور هر څه داسې چلند کوي لکه ستاسو VPN چې کله هم نه وي نصب شوی۔

کورنۍ جلا شمېرل کیږي۔ یوازې IPv4 لاره IPv6 په بنسټیزه شبکه کې پرېږدي، نو دوه ګونی سټیک هوسټ لا هم کولی شي د تونل بهر نوم حل کړي او ونښلي، په داسې حال کې چې دننه یې بشپړ نښلول شوی ښکاري۔

DNS هماغه منطق تعقیبوي۔ هغه سرورونه چې د addDnsServer() سره ورزیات شوي هغو اپلیکیشنونو ته ځي چې د تونل حلونکی کاروي، په داسې حال کې چې د خپل کوډ شوي DNS پای ټکي یا په هوسټ نوم باندې ټاکل شوي Private DNS لرونکی اپلیکیشن هغه په بشپړه توګه له پامه غورځوي۔ کله چې نومونه د یو اپلیکیشن لپاره ناکام شي او د بل لپاره کار وکړي، د یوې لارې له لمس کولو مخکې د حلونکي لاره وګورئ۔

افسانه 3: د هر اپلیکیشن قواعد یو سویچ دی چې هر لوري ته یې ګرځولای شئ

addDisallowedApplication() او addAllowedApplication() دوه فلټرونه نه، دوه حالتونه دي۔ جوړونکی د هر تونل لپاره یو ماډل مني، نو هغه اپلیکیشن چې د درې پاکیجونو پرته هر څه غواړي هغه منع شوی لیست کاروي او اجازه شوی لیست خالي پرېږدي۔ دواړه یو بل منع کوي، او خلک دا د رنټایم پر مهال هغه وخت پوهیږي چې د تنظیماتو سکرین لا دمخه دواړه ټوګلونه وړاندې کړي وي۔

د پاکیج لید هم چیچي۔ په Android 11 او وروسته تاسو یوازې هغه پاکیجونه نومولای شئ چې تاسو یې وینئ، نو هغه استثنا لیست چې له هغې پوښتنې جوړ شوی چې ستاسو اپلیکیشن ته د چلولو اجازه نه لري به په غلي توګه ننوتنې له لاسه ورکړي۔ مخکې لدې چې پرې باور وکړئ لیست د هغه څه سره پرتله کړئ چې د پاکیج مدیر واقعاً بیرته راولي۔

کاري پروفایلونه بیا اورېدونکي ووېشي۔ هغه تونل چې د پروفایل دننه پیل شي هغه پروفایل او د هغه اپلیکیشنونه پوښي، په داسې حال کې چې شخصي اړخ خپل نښلون ساتي۔ دا یو ځل اخيستل شوې د ساحې پرېکړه ده، او ځای یې په انټرفېس کې دی نه په ملاتړ ټکټ کې۔

افسانه 4: stopSelf تونل پای ته رسوي

نه۔ انټرفېس په هغه ډسکریپټر کې ژوند کوي چې establish() بیرته راولي، او د خدمت شی کولی شي مړ شي په داسې حال کې چې هغه ډسکریپټر خلاص پاتې کیږي۔ لومړی ParcelFileDescriptor بند کړئ، مرجع پرېږدئ، لوستونکي او لیکونکي تارونه یوځای یا پرې کړئ، بیا stopForeground(true) او stopSelf() په همدې ترتیب زنګ ووهئ۔

هېر شوی ډسکریپټر هغه عادي لامل دی چې یو خدمت خپل د بندولو غوښتنې ته د ژوندي پاتې کېدو په څېر ښکاري، او هغه زوړه لاره تشریح کوي چې د هغه اپلیکیشن څخه چې هغه یې ورزیاته کړې اوږده ژوند کوي۔

متضاد تېروتنه هم هماغسې عامه ده: ډسکریپټر بندول په داسې حال کې چې لوستونکی تار د لوستلو په منځ کې دی، بیا هغه تار ته پرېښودل چې د هغه استثنا سره مخ شي چې هیڅوک یې لپاره کوډ نه دی لیکلی۔ د بندولو ترتیب په یو ځای کې وساتئ او هم د کارونکي کړنه او هم onRevoke() دې هلته زنګ ووهي۔

کله چې تونل مړ ښکاري څه وګورئ

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

د establish() پایله، لارې، ایستل شوي پاکیجونه او د بندولو لامل ثبت کړئ۔ هغه څلور کرښې پرته له پاکټ نیولو د رضایت ستونزه د ساحې ستونزې او د ژوند دورې ستونزې څخه بېلوي۔