Android VPN لارښوونه: د main جدول څخه مخکې تګلاره قواعد
Android د هر منزل لټون څخه مخکې د uid او نښې قواعدو سره لارښوونې جدول ټاکي، نو main ته اضافه شوې لاره کېدای شي هېڅکله ونه کتل شي.
په Android کې main جدول ته اضافه شوې لاره په هر لیست کې سمه ښکاري او بیا هم ټرافیک نه وړي. لامل دا دی چې main جدول د څو انتخابونو څخه یو دی، او لومړی ترې نه پوښتل کیږي. د Android شبکې خدمت داسې تګلارې قواعد جوړوي چې د منزل پتې کې نه موجود معلومات سره د لارښوونې جدول ټاکي — د اپلیکیشن uid، په پاکټ باندې نښه، هغه انټرفیس چې له هغې راغی — او د منزل لټون وروسته، د هغو قواعدو په ټاکل شوي جدول کې ترسره کیږي.
په ټاکلې ترتیب درې پریکړې
وتونکی پاکټ درې جلا پریکړې کوي. لومړی، یو تګلاره قاعده ټاکي چې کوم لارښوونې جدول پلي کیږي. دوهم، په هغه جدول کې لاره بله ټوپ او وتونکی انټرفیس ټاکي. دریم، netfilter کنډکونه ټاکي چې پاکټ ژوندی پاتې کیږي، بدلیږي که بیا لارښوونه کیږي.
ترتیب مهم دی ځکه چې هر پړاو یوازې خپلې پوښتنې ته ځواب ویلای شي. د اور وژنې دېوال هغه قاعده چې پاکټ مني جدول نه ټاکي، او هغه لاره چې هغه جدول ته اضافه شي چې هیڅ قاعده یې نه ټاکي، بې اغیزې پاتې کیږي. د Android VPN په اړه ډېره ګډوډي له دې څخه راځي چې له درېیو یوه سمه شي او بدلون ونه لیدل شي، ځکه خرابي په بله کې وه.
| Stage | Selector | What it cannot decide |
|---|---|---|
| Policy rule | uid range, mark, incoming interface | Which route exists inside the table |
| Route lookup | Destination prefix, longest match | Whether the packet is allowed out |
| Netfilter hook | Chain position, match conditions | Which table was selected |
نښې یو پیک شوی ساحه ده، نه هغه لیبل چې تاسو یې مالک یاست
Android څو حقایق په یوه نښه ارزښت کې پیک کوي: کومه شبکه وټاکل شوه، ایا اپلیکیشن په ښکاره توګه شبکه وټاکله، ایا ساکټ له VPN څخه ساتل شوی، او د اجازو اړوند بټونه. د AOSP fwmark سرلیک د اوسني ونې لپاره هغه ترتیب تعریفوي، او ترتیب د پلیټ فارم داخلي خبر دی چې د خپرونو ترمنځ بدلیږي.
له همدې امله په Android کې د iptables -j MARK --set-mark په مرسته ټول نښه ارزښت لیکل خطرناک دي. دا ټګ نه زیاتوي؛ دا هغه شبکه غوراوی بدلوي چې سیستم ورته مخکې کړی دی. بیا پاکټ له نورو قواعدو سره سمون خوري، کوم چې د VPN د پیلیدو یا د یو ناتړلي اپلیکیشن د اړیکې له لاسه ورکولو په څېر ښکاري، د دې پورې اړه لري چې کوم بټونه بیا لیکل شوي.
که باید نښو ته لاس ووهئ، لومړی اوسنی ارزښت ولولئ او ماسک وکاروئ ترڅو یوازې هغه بټونه بدل شي چې تاسو یې پوهیږئ:
ip rule show
ip route show table all | head -40
ip route get 10.20.4.11د اړیکې نښه د پاکټ نښې څخه جلا شی ده، او هیڅ یو یې لاره نه ده. په ځوابي پاکټونو باندې نښه بیا رغول د وتلو پر مهال د جدول د ټاکلو څخه جلا ګام دی، له همدې امله یو اړخیز سمونونه هغه اړیکې جوړوي چې خلاصیږي او بیا ځوړن کیږي.
د قواعدو او جدولونو مالک څوک دی
د Android شبکه خدمت، netd، قواعد او د هرې شبکې جدولونه جوړوي. AOSP RouteController هغه ځای دی چې دا قواعد د VPN، فزیکي شبکو او uid حدونو لپاره سره یوځای کیږي، او د هغې ژوند دوره له شبکې پیښو سره تړلې ده نه له کنفیګ فایل سره.
دوه پایلې ترې راځي. لومړی، هغه لومړیتوبونه او جدول شمېرې چې په یوه وسیله کې ومومئ د جوړښت داخلي توضیحات دي، نه انټرفیس: په بله Android نسخه کې ورته ښکاره شمېرې کولای شي بشپړ بل څه معنی ولري. دوهم، کله چې شبکې بدلې شي حالت بیا جوړیږي، نو هغه قاعده چې نن د root شیل څخه داخلېږي کېدای شي د راتلونکي Wi-Fi بدلون وروسته ورکه وي.
دا ورکیدل ډېری وختونه داسې راپور کیږي چې سیستم یوه لاره نه مني. په حقیقت کې هغه څه چې وشول دا دي چې هغه قاعده چې جدول یې ټاکه نوره نشته، او په جدول کې لاره اوس د پاکټ له نظره نه رسیدونکې ده. کله چې یو کار کوونکی ترتیب د بیا نښلولو وروسته کار کول بند کړي، د لارو لیست نه، د قواعدو لیست وګورئ.
د کنډکونو د ترتیب پوښتنو عمومي ځواب نشته
دا پوښتنه چې ایا iptables د VPN لارښوونې مخکې ځي، د پاکټ لاره نه په نومولو سره ځواب نشي موندلای. په سیمه ییز ډول جوړ شوی پاکټ output کنډک تیریږي، چېرې چې د نښې بدلون د بیا لارښوونې کتنه هڅوي — دا دوهمه لټون ده، نه د لومړي وروسته سمون. د tether کړی شوی کلینټ څخه راغلی پاکټ prerouting لار تیریږي او پرځای یې مخته لېږل کیږي، او هغه ځنځیرونه چې دا ویني بل دي.
نو یو هماغه قاعده کولای شي د یو اپلیکیشن ټرافیک لپاره اغېزمنه او د tether ټرافیک لپاره ناښکاره وي، او هغه شمېرونکی چې په صفر پاتې کیږي تاسو ته وایي چې پاکټ کومه لار واخیسته، نه دا چې قاعده غلطه ده. د هرې سمونې شرط بدلولو مخکې د شمېرونکو سره لاره ټاکئ.
دا هغه پړاو هم دی چې د تګلارې لارښوونې تېروتنه لیدل ستونزمن کیږي. هغه جدول ته لارښوونه چې شته خو منزل نه لري شبکه نه رسیدونکې تولیدوي چې د اور وژنې دېوال د غورځولو په څېر ښکاري، پداسې حال کې چې د اور وژنې دېوال غورځول د لارښوونې تور سوري په څېر ښکارېدونکی وخت ختمول تولیدوي.
د سیستم په داخل کې تشخیص وکړئ، یا یې پرېږدئ
د اجازه لرونکې بیا کتنې لپاره، له هر څه لاس وهلو مخکې څلور حقایق ثابت کړئ: د اپلیکیشن uid او پروفایل، هغه شبکه چې Android د هغې لپاره وټاکله، ایا VPN هغه اپلیکیشن په بشپړه توګه رانغاړي، او ایا ستونزه په دواړو پته کورنیو کې شته. د هر اپلیکیشن لپاره استثنا پرته له کومې لارښوونې خرابۍ ډېرې د VPN کار نه کولو راپورونه تشریح کوي.
بیا هغه قواعد، ماسکونه او جدولونه ولولئ چې واقعیا نافذ دي، او د کتنې په کړکۍ کې د شبکې بدلون وساتئ. که چلند د بیا نښلولو په اوږدو کې بدل شي، تاسو مدیریت شوې ژوند دوره ګورئ، نه ورکه لاره.
د عادي اړتیاوو لپاره ملاتړ شوي کنټرولونه وکاروئ: د هر اپلیکیشن شاملول او استثنا په VPN اپلیکیشن کې، او د پلیټ فارم خپله شبکه ټاکنه د هر هغه څه لپاره چې ځانګړې لاره غواړي. که یو ځانګړی امتیاز لرونکی یوځای کیدل واقعیا باید د لارښوونې ماشین سره همکاري وکړي، هغه دقیق Android نسخه چې تاسو یې ملاتړ کوئ هدف وګرځوئ او د هغې ژوند دوره د هغې د مالک برخې له لارې وساتئ. د پلیټ فارم ځنځیرونه فلش کول یا لوړ لومړیتوب قاعده داخلول تشخیص په دوهم شبکه مدیر بدلوي، او تلیفون به هغه ته سم رفتار وکړي.