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 को नेटवर्क सुरक्षा कमजोर पार्न आवश्यक छैन।