কেন ব্লক করা Android অ্যাপ তবুও নেটওয়ার্ক ব্যবহার দেখায়

আপনি আপনার Android VPN ফায়ারওয়ালে একটি অ্যাপ ব্লক করেন, অ্যাপটি কাজ করা বন্ধ করে, আর তার ব্যবহারের সারি ক্রমেই বাড়তে থাকে। লোভনীয় সিদ্ধান্ত হলো ব্লকটি ফাঁক গলিয়েছে, বা কাউন্টারটি নষ্ট। কোনোটিই অনুসরণ করে না। একটি ব্যবহারের রেকর্ড বলে যে কোনও পর্যবেক্ষণ বিন্দুতে ওই পরিচয়ের কাছে বাইট আরোপিত হয়েছে; এটি বলে না যে কোনও দূরবর্তী সেবা একটি অনুরোধ গ্রহণ করেছে কি না। একবার আপনি জানলে কোন সীমানা পরিমাপ করা হয়েছে এবং কোন পরিচয়ের উপর তা ধার্য হয়েছে, দুটি পর্যবেক্ষণ আর পরস্পরবিরোধী থাকে না।

কাউন্টার বাইট মাপে, বিতরণ নয়

Android ট্র্যাফিককে একটি UID-এর কাছে আরোপ করে এবং দুই দিকেই তা গোনে, আর তা করে ইন্টারফেস সীমানায়, অ্যাপের অনুরোধ সফল হওয়ার মুহূর্তে নয়।

প্রত্যাখ্যাত একটি সংযোগ-প্রচেষ্টাও প্যাকেট সরায়: SYN, রিসেট বা তার পরের পুনঃপ্রেরণগুলি, সঙ্গে দুটিরই আগে যাওয়া DNS কোয়েরি। কিছুই বিতরণ না হলেও ওই বাইটগুলি থাকে, এবং কিছু পথে কোনও ফিল্টার কী করবে ঠিক করার আগেই সেগুলি গোনা হয়।

এই কারণেই ব্লক করা অ্যাপের সারি বাড়তে পারে যদিও প্রতিটি অনুরোধ ব্যর্থ হয়। কাউন্টার উত্তর দেয় "এই পরিচয়ের কাছে কত বাইট আরোপিত হয়েছে", "এই পরিচয় ইন্টারনেটে পৌঁছেছে কি না" নয়। একটি চার্ট গৃহীত স্ট্রিমকে ভদ্রভাবে প্রত্যাখ্যাত হ্যান্ডশেক থেকে আলাদা করতে পারে না, আর দুই দিক একসঙ্গে যোগ করা মোটও পারে না।

আরোপণ আইকন নয়, UID অনুসরণ করে

সারিটি প্রতি UID-এর, আর একটি UID একাধিক প্যাকেজ ভাগ করতে পারে, অন্যদিকে দৃশ্যমান একটি অ্যাপ কাজটি নিজের আলাদা পরিচয়ে চলা কোনও কম্পোনেন্টের হাতে দিতে পারে। শেয়ার করা WebView প্রসেসে আঁকা ব্রাউজার ট্যাব, ব্যাকগ্রাউন্ড সিঙ্ক সেবা, বা মূল অ্যাপের সঙ্গে ইনস্টল করা সহযোগী প্যাকেজ — সবই এমন ট্র্যাফিক তৈরি করে যা ব্যবহার স্ক্রিন আপনার প্রত্যাশিত নামে, বা আপনি ব্লক করা অ্যাপের অধীনে দেখাতে পারে। ব্লক করা প্যাকেজ আর তার অনুরোধ বহনকারী সহায়ক দুটি আলাদা বিষয়, আর নিয়মটি কেবল একটিকে ঢেকেছিল।

সংখ্যাগুলি ভুল মনে হলে লেবেল নয়, UID মেলান। ব্যবহার API UID দিয়ে জিজ্ঞাসা করা হয়, আর যে সংখ্যার সঙ্গে মেলাবেন তা adb shell dumpsys package <package> | grep userId= ছাপে, তাই একই UID-এর দুই এন্ট্রি কাউন্টারের দৃষ্টিতে একই পরিচয়।

সময়ের জানালা আপনার নিয়মের আগের হতে পারে

ব্যবহারের ডেটা সরাসরি প্রবাহিত হয় না, বাকেটে সংগ্রহ করে জিজ্ঞাসা করা হয়। দৈনিক মোটের মধ্যে আপনার ব্লক চালু করার আগের মিনিট, আগের ঘণ্টার ব্যাকগ্রাউন্ড সিঙ্ক, বা ইতিমধ্যে পথে থাকা ট্র্যাফিক থাকতে পারে। সঞ্চিত মোটকে একটি প্রত্যাখ্যাত অনুরোধের সঙ্গে মিলিয়ে পার্থক্যকে ফাঁক বলা পরিমাপের ভুল, ফায়ারওয়ালের সন্ধান নয়।

ছোট জানালা আর নতুন শুরু ব্যবহার করুন। নিয়ম বদলানোর সময়ের স্ট্যাম্প টুকে রাখুন, একটি সংগ্রহ-বিরতি অপেক্ষা করুন, তারপর কেবল তার পরের ডেটা দেখুন। নিয়মের পরে শুরু হওয়া জানালাতেও মোট বাড়তে থাকলে আপনার তদন্ত করার মতো কিছু আছে; বাড়া থামলে আগের বৃদ্ধিটি ছিল প্রদর্শিত ইতিহাস।

VPN সেবাটি আপনার কনফিগার করা সেবা নাও হতে পারে

একটি VPN ফায়ারওয়াল কেবল তার নিজের সেবা যে ট্র্যাফিক বহন করে তা দেখে। অন্য কোনও VPN অ্যাপ চালু হয়ে সক্রিয় সংযোগটি নিয়ে নিলে আপনার ফিল্টার আর পথে থাকে না, যদিও তার ইন্টারফেস সেটিংসে এখনও আছে। অ্যাপভিত্তিক বাইপাস তালিকা সেটাই সচেতনভাবে করে, আর কোনও অ্যাপ বাদ দেওয়া প্রোফাইল ফাঁক নয় যখন অ্যাপটি তখন কাজ করে।

IPv4, IPv6 আর DNS-ও আলাদা হতে পারে। IPv4 সামলানো ফিল্টার IPv6 বা একটি প্রাইভেট DNS রিজলভারকে তার বাইরে রাখতে পারে, ফলে অ্যাপের ট্র্যাফিকের অংশ এমন পথে যায় যা আপনার নিয়ম কখনও বর্ণনা করেনি। কিছু পুনর্লিখনের আগে দেখুন কোন অ্যাপ এখন VPN-এর মালিক এবং বর্জন তালিকা কী বলে:

adb shell settings get secure always_on_vpn_app
adb shell dumpsys connectivity
adb shell dumpsys netstats detail

একটি নতুন অনুরোধ পরীক্ষা করুন এবং চারটি তথ্য লিখে রাখুন

একটি নিরীহ অনুরোধ বেছে নিন, একবার করুন, আর চারটি তথ্য লিখুন: বলবৎ নিয়ম, অ্যাপের UID, নেটওয়ার্ক অবস্থা এবং সময়। তারপর দেখুন আপনার ফিল্টার প্রবাহটি লগ করেছে কি না, এবং গন্তব্য বা গেটওয়ে একই সংযোগ দেখেছে কি না। দুই পাশে শনাক্ত একটি প্রবাহই প্রমাণ; সামগ্রিক মোট নয়।

রক্ষণযোগ্য সিদ্ধান্ত বলে কী অস্বীকৃত হয়েছিল আর কোন পর্যবেক্ষণ তা নিশ্চিত করেছে। "কাউন্টার বেড়েছে" কোনও সন্ধান নয়, আর "সব ব্যবহার-কাউন্টার ভুয়া"ও নয়। OSI স্তরের স্লোগান এটি মেটায় না: সৎ উত্তর হলো কাউন্টার আর ব্লক দুটোই সঠিক হতে পারে, যদিও তারা ভিন্ন জিনিস বর্ণনা করে। Android-এর NetworkStatsManager রেফারেন্স নথিভুক্ত করে ওই বাকেটগুলি কীভাবে জিজ্ঞাসা ও আরোপ করা হয়।