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-এর নেটওয়ার্ক সুরক্ষা দুর্বল করার দরকার নেই।