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 ਦੀ ਨੈੱਟਵਰਕ ਸੁਰੱਖਿਆ ਕਮਜ਼ੋਰ ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ।