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-ന്റെ നെറ്റ്വർക്ക് സംരക്ഷണങ്ങൾ ദുർബലമാക്കാനോ ആവശ്യമില്ല.