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 ನ ಜಾಲ ರಕ್ಷಣೆಗಳನ್ನು ದುರ್ಬಲಗೊಳಿಸುವ ಅಗತ್ಯವಿಲ್ಲ.