Android VpnService نښلوي خو هېڅ پاکټ شبکې ته نه رسېږي

ټنل پورته کېږي، د کیلي نښه ښکاري، او په براوزر کې هره غوښتنه لا هم د وخت پای ته رسېدو سره ناکامېږي. په VpnService اپلیکیشن کې دا ترکیب معمولاً معنا لري چې د لوستلو حلقه ژوندې ده او د وتلو نیمه ماتېده، نه دا چې سرور لاس ورکول رد کړي. Android لا دمخه انټرفیس جوړ کړی، د اپلیکیشن ترافیک ته ننوتلی او ستاسو پروسې ته د فایل ډیسکریپټر ورکړی. له هغه ډیسکریپټر وروسته هر څه ستاسو کوډ دی، او یو ورک شوی کال د ټول جریان بلعولو لپاره کافي دی.

سیستم څه درکوي او څه نه درکوي

establish() د tun انټرفیس لپاره ParcelFileDescriptor بېرته راګرځوي. سیستم په هغه کې وتونکي IP پاکټونه لیکي او تمه لري چې ستاسو پروسه هغه ولولي، پریکړه وکړي چې چېرته ځي او د عادي ساکټ له لارې یې واستوي. لاندې د کرنل لېږد نشته، نو کله چې څوک نه لولي پاکټونه غورځول کېږي او د انټرفیس شمارونکي هېڅکله نه خوځېږي.

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

بلاک کوونکې لوستنه پریکړه کوي چې حلقه خوځېږي که نه

setBlocking(true) ډیسکریپټر بلاک کوونکي حالت ته وړي او له API 21 راهیسې شته. په زړو نسخو کې حل لار یو کوچنی JNI مرستندوی دی چې په خام ډیسکریپټر fcntl سره O_NONBLOCK پاکوي. حالت مهم دی ځکه ټاکي چې پرته له انتظار پاکټ لوستنه څه کولی شي.

په نه-بلاک کوونکي حالت کې هغه لوستنه سمدلاسه منفي ارزښت سره بېرته راځي، او هغه حلقه چې پایله نه ګڼي یو کور ګرځوي پرته له دې چې کوم ترافیک وخوځوي. په بلاک کوونکي حالت کې لوستنه انتظار کوي، چې د لېږد تار غواړي، خو بیا تار نه شي قطع کېدلی. ډیسکریپټر بندول د لوستنې ناکامولو ملاتړ شوې لار ده ترڅو حلقه ووځي. پروسه وژل یا تار قطع کول کېدای شي بل پیل د داسې ډیسکریپټر سره پرېږدي چې نور له انټرفیس سره نه ځي.

په هر کال کې د انټرفیس د MTU اندازې بفر ته یو پاکټ ولولئ، او صفر یا منفي بېرته راتلل د خالي پاکټ پر ځای تېروتنه وګڼئ.

protect() د لومړي لېږلو دمخه، نه وروسته

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

ترتیب protect، بیا connect یا bind، بیا send دی. له connect وروسته protect کال کول کېدای شي پخوانۍ د لارې پریکړه پر ځای پرېږدي، نو ساکټ غلطه لار کاروي حتی که کال true بېرته راوړی وي. بېرته راتلونکی بولین وګورئ او کله چې false وي په لوړ غږ ناکام شئ، د داسې send په داخلېدو پر ځای چې کار نه شي کولی.

د sendto څخه د اجازې تېروتنه په هغه ساکټ چې هېڅکله protect() ته نه دی رسېدلی، د دې تېروتنې عادي نښه ده.

د UDP بېلګه HTTPS نه وړي

د لېږد بېلګه چې ډېری درسونه کاپي کوي یوازې UDP سمبالوي. TCP ته لاس ورکول، د ترتیب شمېرې، تاییدونه او بیا لېږل غواړي، او هغه حلقه چې د tun ډیسکریپټر او ساکټ ترمنځ بار کاپي کوي هغه له دې څخه هېڅ نه ورکوي. له همدې کبله د UDP DNS پوښتنه تېرېدلی شي پداسې حال کې چې هره HTTPS غوښتنه ودريږي. یا د کاروونکي تشیال کې TCP سټیک وچلوئ یا نښلونونه دې سیمه ییز پراکسي ته ورکړئ چې په وسیله کې TCP پای ته رسوي او جریان لېږدوي.

د بیا لیکلو دمخه جلاوالی وآزموئ: یوه UDP پوښتنه واستوئ او هماغه هوسټ ته یو TCP نښلون پرانیزئ. که UDP لار کار وکړ او TCP لار په لومړي SYN ودرېده، ستونزه د لېږد په کوډ کې ده نه په سرور کې. هغه یوه پرتله ډېر وخت خوندي کوي چې د بې ګټې سرور لاګونو لوستلو ته تېرېږي.

د لارو لیست او د هر اپلیکیشن فلټرونه هغه څه محدودوي چې ګورئ

addAddress, addRoute او addDns ټاکي چې سیستم ټنل ته څه لېږي. د لارو لیست څخه بهر منزل هېڅکله ستاسو ډیسکریپټر ته نه رسېږي، نو څومره لېږد منطق هم وي نه یې سمولای شي. خپل builder کالونه ثبت کړئ او له هغو پتو سره یې پرتله کړئ چې اپلیکیشن واقعاً هغو ته رسېدو هڅه کوي.

د هر اپلیکیشن غوراوي خپله بنده لري: addAllowedApplication او addDisallowedApplication API 21 غواړي، او په زړو نسخو کې هغه میتودونه نه شته. هغه ډیزاین چې د پاکټ له مخې فلټر کوي هلته هېڅ نشي کولای.

بیا جوړول زړه ډیسکریپټرونه پرېږدي

establish() بیا کالول نوی ډیسکریپټر راوړي او پخوانی انټرفیس بندوي. زوړ ډیسکریپټر اوس ناسم دی، نو هغه تار چې لا پر هغه بلاک دی تېروتنه اخلي، او د زړې لارې لپاره جوړ شوي ساکټونه ممکن بدلولو ته اړتیا ولري. onRevoke هغه بېرته کال دی چې کاروونکي یا سیستم اخیستی ټنل لپاره دی. ژوند دوره یو مالک سره ساتل، چې له بیا جوړولو دمخه لوستونکی بندوي، ډېری نښلول شوي-خو مړه حالتونه مخه نیسي.

هره تېروتنه د هغې د پړاو له مخې ولولئ. له recvfrom څخه د نښلون بیا تنظیم معنا دا ده چې لرې سر بند شو پداسې حال کې چې ستاسو کوډ لا لوستل. د ناسم پتې تېروتنه د سرلیک شننې یا آفسیټ ستونزې ته اشاره کوي، نه شبکې ته.

د کار ترتیب: بلاک کوونکی حالت روښانه، په هر لوستلو یو پاکټ، سرلیک شنل شوی، ساکټ ساتل شوی، بار لېږل شوی، په سپارلو کې پاک بندول، او د منزل پوښونکی د لارو لیست.