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 च्या नेटवर्क संरक्षण कमकुवत करण्याची गरज नाही।