Android always-on VPN: د پای ټکي نوم لومړی څنګه حل کېږي
Android تر تونل مخکې ټرافیک بندوي، خو کلاینټ لا هم خپل پای ټکی حل کول غواړي. دا ترتیب او هغه ځای چې هلته بند پاتې کېږي.
تلیفون بیا پیل کېږي، always-on فعال دی، «پرته له VPN اړیکې بندې کړه» فعال دی، او تونل هېڅکله نه راځي. هېڅ هم غلط تنظیم شوی نه دی: بندښت خپله دنده کوي، او د کلاینټ خپله هڅه چې خپل پای ټکي ته ورسیږي هم د هغې لاندې ده. د پای ټکي نوم باید تر تونل مخکې حل شي، د هغه کلاینټ له خوا چې شبکه سره د خبرو اجازه لري، پداسې حال کې چې نورو ټولو اپلیکیشنونو ته نه ده. دا پوهېدل چې کومه برخه دا کوي او په کوم ترتیب، دا معما د ترتیباتو پوښتنې ته اړوي.
د VPN جوړوونکی واقعاً څه غواړي
د Android VPN اپلیکیشن پلیټ فارم ته د سرور پته نه ورکوي. دا یو ځایي انټرفیس جوړوي: د تونل لپاره پتې او لارې، هغه حل کوونکي چې اپلیکیشنونه باید دننه کې وکاروي، او بیا establish() یو دوتنه ډیسکریپټر بېرته ورکوي چې اپلیکیشن یې د خامو IP پیکټونو په توګه لولي او لیکي. لرې پای ټکی په هغه جوړوونکي کې هېڅ نه ښکاري.
دا اصلي جوړښتي حقیقت دی. پلیټ فارم د tun انټرفیس جوړوي او پر هغې تګلاره پلي کوي؛ اپلیکیشن د کاروونکي په تشه کې ټرانسپورټ پلي کوي، یعني اپلیکیشن پخپله د خپل پای ټکي نوم حل کوي او کوډ شوې اړیکه پرانیزي. نو ځکه د کوربه نوم په بڼه پای ټکی ممکن دی — نه ځکه چې پلیټ فارم نومونه ملاتړ کوي، بلکې ځکه چې پلیټ فارم پای ټکی هېڅکله نه ویني.
د جوړوونکي یوه برخه بیا هم پتې اخلي: DNS سرورونه. دا باید عددي حل کوونکي پتې وي، معمولاً هغه چې آپریټر غواړي د تونل له لارې پوښتنه ترې وکړي. هغه برخه بیانوي چې تونل له پورته کېدو وروسته اپلیکیشنونه پوښتنې چېرته لېږي. دا هېڅ نه وایي چې کلاینټ پای ټکی څنګه مومي، او همدا دوه یو شان تنظیم ګڼل له همدې ځایه ګډوډي پیلېږي.
یوه نه، دوه DNS پوښتنې
لومړنۍ پوښتنه دا ده: تونل له پورته کېدو وروسته اپلیکیشنونه پوښتنې چېرته لېږي؟ ځواب د تونل دننه د حل کوونکي پته ده، د tun انټرفیس له لارې د لاسرسي وړ، او په جوړښت کې عددي.
دوهمه پوښتنه دا ده: کلاینټ خپل پای ټکی د هغه تونل له موجودیت مخکې څنګه مومي؟ هغه لټون د تونل څخه بهر، په اساسي شبکه کې، د کلاینټ په پروسه کې کېږي. دا کولای شي نوم وکاروي، او باید هغه حل کوونکی وکاروي چې وسیله پرته له VPN ورته رسیږي.
| Stage | Who resolves | Path | Failure looks like |
|---|---|---|---|
| Endpoint lookup | The VPN app | Underlying network, protected socket | Never connects; no tunnel interface traffic |
| Peer authentication | Client and server | Tunnel transport | Connects then drops; certificate or key error |
| Private name lookup | Apps via the tunnel | Resolver inside the tun | Tunnel up, internal sites do not resolve |
درې مرحلې، درې بېلابېلې نښې. یو واحد د خطا پیغام چې وایي «نښلول ممکن نه دي» هغوی یوځای کوي، او له همدې امله خلک د DNS سرور برخه سمول پیلوي تر څو هغه ستونزه سمه کړي چې د هغې برخې له لوستلو مخکې پېښېږي.
bootstrap ولې بند پاتې کېدای شي
always-on د فعال بندښت سره یعني هغه ټرافیک چې د VPN دننه نه دی غورځول کېږي، په شمول د هغه اپلیکیشن ټرافیک چې VPN لري. وتل روښانه دي: اپلیکیشن په سوکټ protect() بولي، کوم چې هغه له اساسي شبکې سره تړي نو تونل ته څنګ ته کېږي او وتلو اجازه مومي. هر VPN کلاینټ باید دا د خپل ټرانسپورټ لپاره وکړي، که نه نو هېڅکله سرور ته نه رسیږي.
اوس هغه ځایګی تصور کړئ چېرته چې یوازینی حل کوونکی چې د پای ټکي نوم پېژني خپله د تونل دننه دی. کلاینټ ته نوم حل کولو لپاره تونل ته اړتیا ده، او تونل جوړولو لپاره نوم ته. دا ریښتینې ګردیزه تړاو دی، او هېڅ کلاینټ ترتیبات یې نه حل کوي. دا د ډیزاین تېروتنه ده، نه بګ.
وخت همدا تړاو په نرمه بڼه ښکاره کوي. د پیل پر مهال، تر لومړي خلاصېدو مخکې، وسیله کېدای شي لا هم د کار وړ شبکه نه ولري؛ په captive portal کې شبکه شته خو پرته له پورټاله هر څه بندوي؛ له Wi-Fi څخه ګرځنده شبکې ته د تګ پر مهال د ساتل شوي سوکټ اساسي شبکه بدلېږي او کلاینټ باید دا وپېژني او بیا حل کړي. د دې هر یو bootstrap پېښه ده، او هر یو یې د شپې 3 بجو کشف کولو پر ځای په قصد ازموینې ارزښت لري.
ولې ځواب ثابتول حل نه دی
هڅوونکې لار دا ده چې نوم یو ځل حل کړو او رامنځته شوې پته په عددي برخه کې ولګوو، یا یې په ځانګړي جوړښت کې سخت کوډ کړو. دا د کارېدونکي ښکاري، او نوم په انځور بدلوي. کله چې آپریټر پای ټکی ځای په ځای کوي — کډوالي، anycast بدلون، نوې سیمه ییزه پته — کلاینټ زاړه ته زنګ وهلو ته دوام ورکوي او په UI کې هېڅ هم دلیل نه څرګندوي.
د DNS ریکارډونو عمر ځکه شته چې ځوابونه بدلېدای شي؛ کیشنګ د همدې عمر پر بنسټ تعریفېږي، نه د تل لپاره. ځواب ثابتول هغه میکانیزم غورځوي چې نوم له پتې غوره کوي، په داسې حال کې چې د نوم کارولو عملیاتي لګښت ساتي.
ثابتول معمولاً د دوهم بد عادت سره یوځای راځي: پیژندنې کتنې نرمول ځکه چې اړیکه اوس په بله بڼه ناکامېږي. د سرور پیژندنې تصدیق د bootstrap ستونزې برخه نه ده، او کمزوری کول یې د DNS ناخوالې په مداخلې خطر بدلوي.
هغه ډیزاینونه چې بیا پیل یې زغمي
دوامداره ترتیب ښکلی نه دی. هغه کلاینټ وکاروئ چې ساتل شوي سوکټونه سم پلي کوي او خپل پای ټکی په اساسي شبکه کې حل کوي، او هغه ته د پای ټکي نوم ورکړئ چې په عامه توګه، یا د تونل مخکې د لاسرسي وړ حل کوونکي له لارې حلېږي. بندښت فعال وساتئ؛ د DNS د کار کولو لپاره یې په بشپړه توګه بندول هغه ځانګړنه لرې کوي چې ځایګی د هغې لپاره دی.
چېرته چې پای ټکی باید خصوصي پاتې شي، هغه ښکاره bootstrap لار برابره کړئ چې پلیټ فارم یې کارولی شي — پرته له تونل د لاسرسي وړ حل کوونکی، یا هغه مدیریتي اړیکه چې آپریټر ساتي — او هغه استثنا تنګه وساتئ، د کاروونکي ټاګل نه، بلکې د تګلارې ملکیت کې. د Android VpnService اسناد دا دي چې پلیټ فارم د ساتنې او ژوند دورې په اړه څه تضمین کوي، او VpnService.Builder حواله تصدیقوي چې DNS برخه عددي پتې اخلي.
بیا له بیا پیل وروسته په نوې اړیکه کې درې مرحلې په ترتیب سره وګورئ: د پای ټکي نوم حلېږي، تونل ټینګېږي او همکار تصدیقېږي، او خصوصي نوم د تونل د حل کوونکي له لارې حلېږي. که لومړنۍ مرحله ناکامه شي، بل هېڅ نه شي کار کولی، او سمون د bootstrap لارې ته اړه لري — هېڅکله د حل کوونکي برخې ته.
- د پای ټکي حل د اپلیکیشن دننه، د تونل څخه بهر، په ساتل شوي سوکټ کې کېږي.
- د جوړوونکي DNS برخه د تونل دننه اپلیکیشنونو لپاره ده، نه د کلاینټ خپل پای ټکي لپاره.
- یوازې د تونل له لارې د لاسرسي وړ حل کوونکی بندښت دی، نه ورو پیل.
- له بیا پیل وروسته پای ټکی، تصدیق او خصوصي لټون جلا جلا وآزموئ.