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 की नेटवर्क सुरक्षा कमज़ोर करने की ज़रूरत नहीं है।