د Android VpnService اجازه لړلیک: ولې اجازه شوي پاڼې لا هم ځنډېږي

تاسو یو ډومین اجازه لړلیک ته ورزیات کړ، پوښتنه ستاسو اپ ته رسیږي، سمونکی اجازه شوي بیرته ورکوي، او پاڼه بیا هم هېڅکله نه بارېږي. په دې ټکي کې ډېر خلک سمونکی بیا لیکل پیلوي او د وحشي نښو پرتله ورزیاتوي. زما په تجربه کې سمونکی معمولاً سم وي، او خرابي یوه طبقه لاندې ده: په هغه DNS ځواب کې چې تاسو جوړ کړی، په هغه لار کې چې تاسو نصب کړې، یا په هغه ساکټ کې چې د پوښتنې لېږلو لپاره مو وکاراوه. لړلیک اسانه برخه ده؛ د پاکټ لار هغه ځای دی چیرې چې اجازه لړلیکونه ماتېږي.

سمونکی په نادره توګه مجرم وي

لومړی شی چې باید بېل شي هغه بند شوی له مات شوي. بند شوی نوم باید ژر او په ښکاره توګه ناکام شي، ځکه چې براوزر د نوم نه شتون ځواب ترلاسه کوي او ودروي. مات شوی نوم ځنډېږي، د IPv6 له لارې بیا هڅه کوي، بل ټرانسپورټ ته راځي، او تاسو له څرخېدونکي نښان سره پرېږدي. که تاسو څرخېدونکی نښان ووینئ، ستاسو اجازه لړلیک ښایي داسې څه ځواب کړي چې کلاینټ پرې هیڅ نشي کولی.

تش A ریکارډ کلاسیکه تېروتنه ده. له صفر ځوابونو سره NOERROR بیرته ورکول د سم ځواب په څېر ښکاري، نو stub حل کوونکی یې مني، براوزر بیا هڅه کوي، AAAA ازمويي، بل حل کوونکی ازمويي، او ډېر وروسته تسلیمېږي. د پوښتنې برخه تکرار او د معاملې ID کاپي کولو سره د ځواب کوډ 3، یعنې NXDOMAIN، خبرې سمدلاسه پای ته رسوي. دا د هر هغه نوم لپاره وکاروئ چې تاسو یې په قصد رد کوئ.

IPv6 هم د ډیفالټ پر ځای هماغه پرېکړې ته وړ دی. که تاسو د A لپاره NXDOMAIN ځواب ورکړئ او AAAA پرېږدئ، کلاینټ کولی شي د IPv6 له لارې بند شوي نوم ته ورسیږي او فلټر تویېږي. ځینې پلي کونې د بند شوو AAAA پوښتنو ته د loopback پتې سره ځواب ورکوي ترڅو اړیکه سمدلاسه ناکامه شي پرته له دې چې بدیل ته واوړي. یوه تګلاره وټاکئ، په دواړو ریکارډ ډولونو یې پلي کړئ، او دواړه ثبت کړئ.

هغه لار چې هر څه نیسي، هر څه لري

یوازې پر DNS ولاړ ډیزاین هېڅکله addRoute("0.0.0.0", 0) نه ورزیاتوي، نو یوازې پوښتنې TUN انټرفیس ته ننوځي او نور هر څه لاندې شبکه کاروي. دا خوندي بڼه ده، او دا هم څرګندوي چې ولې ځینې اجازه لړلیکونه په Wi-Fi کې کار کوي او په موبایل شبکه کې ناکامېږي.

په هغه شیبه چې ډیفالټ لار شتون ولري، هر بهیر ستاسو دی. هغه TCP پاکټ چې انټرفیس ته رسیږي او نه لېږل کیږي او نه ځواب ورته ورکول کیږي، تر هغه په قطار کې ناست وي چې کلاینټ وخت تېر شي، او د ثبت لپاره هېڅ تېروتنه نشته ځکه چې هېڅ شی غلط نه شو. ما ولیدل چې یو څوک یوه ماسپښین په ماتې اجازه لړلیک تېر کړ، کوم چې په حقیقت کې د 443 پورټ لپاره ورک لېږدونکی و. د هر هغه پاکټ پروتوکول او منزل ثبت کړئ چې تاسو یې غورځولو ته پرېکړه کوئ.

د حل کوونکي ساکټ باید له تونل ووځي

لېږد هغه ځای دی چیرې چې بل تله ناسته ده. د آپریټر حل کوونکي ډېری وخت په شخصي پته وي چې تونل ورته نه رسیږي، نو هغه پوښتنه چې تاسو یې لېږئ هېڅ چیرې نه ځي او اپ د لوستلو وخت تېرېدو راپور ورکوي. اجازه شوې پوښتنې هغه حل کوونکي ته ولېږئ چې تاسو پوهېږئ د رسېدو وړ دی، او لومړی هغه ساکټ VpnService.protect() ته ورکړئ. نه ساتل شوی ساکټ پوښتنه ستاسو خپل تونل ته بیرته لېږي، چیرې چې دا بیا اپ ته رسیږي او تر وخت مودې پورې څرخي.

خرابي د شبکې پرېکون په څېر ښکاري، او له همدې کبله په بګ راپورونو کې دومره اوږد ژوند کوي. د لېږل شوو پوښتنو او ترلاسه شوو ځوابونو لپاره شمارونکي وساتئ: که لومړی شمېر لوړ شي او دویم په صفر پاتې شي، تاسو ساکټ ته ګورئ نه لړلیک ته.

اندازه او چکسم پرته له پیغام ناکامېږي

غله غورځول له اندازې هم راځي. د لوی ځواب ټولګي سره DNS ځواب، یا د پراخو انتخابونو سره TCP لاس ورکول کولی شي هغه د لارې MTU تېر کړي چې تاسو هېڅکله په ښکاره توګه نه دی ټاکلی؛ ټوټه پورته ورک کیږي او کلاینټ یا کوچني اندازې سره بیا هڅه کوي یا هڅه پرېږدي. د انټرفیس MTU په 1280 ټاکل یو محافظه کاره انتخاب دی چې ډېری موبایل لارې یې زغمي، او ښکاره اوسلېدل له هغه ډیفالټ غوره دی چې چا نه دی اندازه کړی.

که تاسو پخپله پاکټونه جوړوئ، چکسم بل غله وژونکی دی. هغه UDP چکسم چې پر هغه جعلي سرلیک حساب شي چې د UDP اوږدوالی یا پروتوکول ساحه پرېږدي، داسې پاکټ جوړوي چې ستاسو خواته سم ښکاري او ترلاسه کوونکی یې بې له کومې نښې غورځوي. خپل جعلي سرلیک د مشخصاتو سره ساحه په ساحه پرتله کړئ، او د ډیبګ پر مهال د یوې پېژندل شوې بهیر لپاره حساب شوی چکسم چاپ کړئ.

VpnService ستاسو لپاره څه نه کوي

د دې شاوخوا د ډیزاین کولو دمخه دوه حدود د پېژندلو وړ دي. هېڅ عادي اپ نشي کولی د Wi-Fi څخه بهر سیسټمیز پراکسي یا PAC فایل نصب کړي، او هغه برخه نه ده بدله شوې. د هر اپ لار بدله شوې: د API 29 څخه دمخه VpnService.Builder هېڅکله پراکسي نه شو کولی وړي، او له API 29 څخه setHttpProxy(ProxyInfo.buildPacProxy(uri)) پلیټفارم ته د VPN شبکې لپاره د ارزولو PAC سکریپټ ورکوي. کله چې زاړه API په نښه کوئ یا PAC ماډل قاعده نشي څرګندولی، قاعدې په خپل کوډ کې ارزوئ. UDP هم وړیا نه دی: براوزرونه د SOCKS پراکسي له لارې یوازې TCP لېږي، او ډېری SOCKS5 کلاینټونه هېڅکله UDP ASSOCIATE نه پلي کوي، نو د پراکسي ولاړ ډیزاین UDP غورځوي یا تویوي پداسې حال کې چې TCP روغ ښکاري.

همدا دویم حد هغه لامل دی چې ولې د UDP ولاړ پروتوکول په عادي شبکه کې کار کولی شي او هغه شیبه ناکام شي چې ستاسو VPN وصل شي. که تمه وي چې تونل UDP وړي، لېږدونکی باید د هغې لپاره د لېږد لاره پلي کړي، نه یوازې د بل ساکټ ډول سره TCP لاره.

په دې ترتیب کتنه وکړئ

لړلیک په ترتیب سره بشپړ کړئ او په لومړي هغه پړاو ودروئ چې ناکام شي، ځکه چې هر وروستی کتنه شور ده تر هغه چې پخوانۍ ټینګه نه وي.

1. نصب شوې لارې ولیکئ او تایید کړئ چې غیر DNS پاکټونه په اصل کې TUN انټرفیس ته ننوځي که نه.
2. د یو بند شوي او یو اجازه شوي نوم لپاره د پوښتنې نوم، پرېکړه او د ځواب کوډ ثبت کړئ.
3. تایید کړئ چې د حل کوونکي ساکټ ساتل شوی او ټاکل شوی حل کوونکی د تونل له داخله ځواب ورکوي.
4. د انټرفیس MTU او په لاس جوړ شوي یو ځواب چکسم تایید کړئ.
5. هماغه پاڼه په Wi-Fi او موبایل شبکه کې تکرار کړئ، ځکه د آپریټر حل کوونکي او د لارې MTU توپیر لري.

که پنځه واړه ټینګ وي او پاڼه لا هم ځنډېدلې وي، بل شکمن پخپله لېږدونکی دی: نیول شوې غوښتنه له نیول شوي ځواب سره پرتله کړئ او د ورک شوي بایټ شمېر یا نیم بند ساکټ پلټنه وکړئ. د VpnService.Builder مرجع د لارې، DNS او MTU قراردادونه پوښي، او protect() جلا VpnService غږ دی نه د builder انتخاب؛ نښلول شوی انټرفیس یوازې دا مانا لري چې لومړی قرارداد پوره شو.