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 ની નેટવર્ક સુરક્ષા નબળી કરવાની જરૂર નથી.