Tasker اور WireGuard: ایک ٹنل کے لیے درست Intent بھیجنا

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 کی نیٹ ورک حفاظت کمزور کرنے کی ضرورت نہیں۔