Tasker او WireGuard: د یوې تونل لپاره سم Intent لېږل
Tasker کولی شي له WireGuard څخه وغواړي چې د لرې کنټرول ترلاسه کوونکي له لارې یوه نومول شوې تونل پورته کړي۔ کنټرولر لا هم د CONTROL_TUNNELS اجازې ته اړتیا لري۔
د WireGuard فعالیت پیلول اپ مخې ته راولي، نه یوه ټاکلې تونل پورته کوي۔ هغه اتومات چې اپ پرانیزي او انتظار کوي په ازموینه کې بریالی شي او لومړی ځل چې تلیفون له مخکې د کور سکرین پر وي ناکام شي۔ WireGuard د نومول شوو تونلونو لپاره د لرې کنټرول ملاتړ شوې لاره وړاندې کوي، او هغه له هغې تنګه ده چې ډېری ترکیبونه یې وړاندیز کوي۔ لاندې چک لیست هغه لاره له اجازې څخه تر لیدل شوې پایلې پورې وهي۔
وګورئ چې لرې کنټرول فعال دی
د لرې کنټرول ترلاسه کوونکی تل نه اوري۔ د WireGuard په تنظیماتو کې یوه اختیار شته چې د تونلونو لرې کنټرول فعالوي، او تر هغه چې دا اختیار نه وي فعال شوی، ترلاسه کوونکی غوښتنې له پامه غورځوي پرځای دې چې په لوړ غږ ناکام شي۔ تلواله ارزښت په قصد دی، ځکه چې د تونلونو پورته کولو وړ صادر شوی ترلاسه کوونکی به په هر هغه وسیله کې د امنیت سوري وي چې اپ پر نصب دی۔ له انټرفیس څخه یې فعال کړئ او ولیکئ چې تاسو دا کړی، ځکه چې دا هغه تنظیم دی چې راتلونکی کاروونکی یې پرته له دې چې پوه شي څه پرې تکیه وو بندولی شي۔
پورتنۍ ترلاسه کوونکی یوازې نومول شوې UP او DOWN غوښتنې سمبالوي، نو دلته د تونل جوړولو یا د هغې ترتیب سمولو لپاره هېڅ لاره نشته۔ پرې تکیه کولو دمخه تایید کړئ چې برخه په نصب شوي جوړښت کې شته: adb shell dumpsys package com.wireguard.android | grep -i receiver اعلان شوې ترلاسه کوونکي لیستوي، او د لرې کنټرول ترلاسه کوونکي پرته جوړښت به هېڅکله ځواب ونه وایي۔ که چېرې کاري بهیر بل پای ټکی یا بل سیال ته اړتیا لري، هغه بله تونل ده او د اپ په داخل کې جلا لاسي ترتیب دی۔
وګورئ چې کنټرولر کومه اجازه لري
WireGuard ترلاسه کوونکی په خطرناکه اجازه ساتي، com.wireguard.android.permission.CONTROL_TUNNELS، چې کنټرول کوونکی اپ باید ولري۔ خپل خپرونکی نشي کولی هغه اجازه جوړه کړي چې لېږدونکي هېڅکله اعلان کړې نه وي یا هېڅکله ورته نه وي ورکړل شوې۔ دا هغه ګام دی چې اتومات ترکیبونه په چوپتیا سره هغه وړتیا مني چې اتومات یې نه لري۔
د کار لیکلو دمخه دواړه خواوې وګورئ۔ لومړی کمانډ اعلان شوې اجازه لیستوي، او دویم ښیي چې د کنټرولر بنډل رښتیا هغه لري که نه۔ کنټرولر چې اجازه په خپل مانیفست کې اعلانوي خو د اجرا په وخت کې هېڅکله ورته نه وي ورکړل شوې، بیا هم ناکام شي، او ناکامي د خبرو اترو پرځای د چوپتیا په بڼه راځي۔
adb shell pm list permissions -g -d | grep -i control_tunnels
adb shell dumpsys package net.dinglisch.android.taskerm | grep -i control_tunnels
که کنټرولر اجازه نه لري، د لاسي خپرونکي جوړولو پرځای هغه یوځای کول وکاروئ چې اپ یې رښتیا ملاتړ کوي۔ د Intent لېږل او لیدل چې غږونه بریالي شو یوازې دا ثابتوي چې Android هغه ومنل، نه دا چې WireGuard پرې عمل وکړ۔ ناتایید شوې لېږل د ناپېژاندې په توګه ونیسئ، نه د بریا په توګه۔
د Intent ساحې د نصب شوي اپ سره پرتله کړئ
څلور ساحې ټوله غوښتنه وړي، او هر یوه د ناکامۍ هغه طریقه لري چې دقیقاً د نورو په څېر ښکاري۔ کړنه، د تونل اضافي ساحه، بنډل او هدف په سمه توګه د یوې ټولګې په توګه ترلاسه کړئ۔
Action: com.wireguard.android.action.SET_TUNNEL_UP
Extra: tunnel:lab-wg
Package: com.wireguard.android
Target: Broadcast Receiver
کړنه UP یا DOWN نوموي او بل هېڅ نه، اضافي ساحه دقیقاً ترتیب شوی د تونل نوم وړي، بنډل رسول WireGuard ته محدودوي، او هدف باید ترلاسه کوونکی وي نه فعالیت۔ د تونل نوم چې لیکنيزه تېروتنه ولري هماغه چوپتیا پیدا کوي چې بند ترلاسه کوونکی، نو د دې پایلې دمخه چې اتومات خراب دی نوم په اپ کې ولولئ۔ د DOWN کړنه هماغه اضافي ساحه او بنډل سره com.wireguard.android.action.SET_TUNNEL_DOWN ده۔ د ازموینې پر مهال یو وخت یوه غوښتنه ولېږئ، ځکه چې دوه خپرونکي چې یو بل ته ګټه وهي هغه حالت جوړوي چې هیڅوک یې نه شي نسبتولی۔
هماغه غوښتنه د وسیلې شل څخه ازموئ ترڅو Intent له اتومات څخه جلا کړئ۔ که هغه کمانډ ناکام شي او د Tasker کار بریالی شي، توپیر د لېږدونکي اجازه ده نه د ساحو ارزښتونه۔
adb shell am broadcast -a com.wireguard.android.action.SET_TUNNEL_UP -e tunnel lab-wg --receiver-permission com.wireguard.android.permission.CONTROL_TUNNELS
وګورئ چې ټریګر څه نه پوښي
د اپ پیل یا مخې ته راتلو پېښه کولی شي یو تړاو وغواړي، خو کېدای شي اپ له دې پېښې دمخه د نوم پلټنه یا لومړنۍ غوښتنه هڅه کړې وي۔ ټریګر هغه وخت چالانېږي چې سیستم د حالت بدلون وپېژني، دا هغه وخت دی چې اپ کار پیل کړی وي۔ که اپ باید هېڅکله له تونل بهر اړیکه ونه لري، د پیل ټریګر د بندولو قاعده نه ده او د ځنډ په زیاتولو سره نشي کولی داسې وګرځول شي۔ د بندولو چلند لپاره ملاتړ شوې تل فعاله یا د هر اپ پالیسي ترتیب کړئ، او ټریګر یوازې د اسانتیا لپاره وساتئ۔
د بندولو چلند په بشپړه توګه بل ځای کې ژوند کوي۔ adb shell settings get global always_on_vpn_app هغه بنډل نوموي چې د تل فعال په توګه پن شوی، او adb shell dumpsys connectivity | grep -i vpn هغه VPN شبکې ښیي چې سیستم یې اوس تعقیبوي۔ له دې څخه هیڅ یو د پیل ټریګر لخوا نه شي بدلول کېدای۔
هماغه استدلال د غونډې بلې خوا ته هم صدق کوي۔ د تونل ښکته کول ځکه چې یوه کړکۍ فوکس له لاسه ورکړ په شالید کې کار، د تصدیق مرستندویان او هر بل اپ چې پر تړاو تکیه وو ماتوي۔ د فوکس بدلون پرځای قصد شوی غونډې پای تعریف کړئ، او کله چې اتومات کانټیکسټونه بدلوي د چټکو UP او DOWN تسلسلونو څخه ډډه وکړئ۔
پایلې وګورئ، نه لېږل
هغه خپرونکی چې پرته له تېروتنې بېرته راځي Android منلی او نه نور۔ د تونل حالت له اپ څخه ولولئ، او د کاري بهیر چمتووالی له هغې څخه ولولئ چې بل ګام ورته رښتیا اړتیا لري۔ دا دوه جلا څېړنې دي، او لومړۍ تېرول دویمه نه معنی کوي۔
د انټرفیس حالت هم مستقیم ولولئ: adb shell ip -brief addr show tun0 د تونل انټرفیس او د هغې پته چاپوي، او هغه انټرفیس چې پرته له پتې شته پورته دی خو د کارولو وړ نه دی۔ بیا خپله خصوصي خدمت تایید کړئ، ځکه چې هغه تونل چې پرته له لاس ورکولو یا پرته له لارې پورته وي بیا هم په هغه کار کې ناکامېږي چې مهم و۔ هغه اتومات چې یو نومول شوی تړاو د خپلې ریښتینې اجازې په حدودو کې کنټرولوي اړ نه دی چې انټرفیس ته لاس ووهي، root کمانډ وچلوي یا د Android شبکې ساتنې کمزورې کړي۔