ফোনে chroot-এর ভিতরে চলা একটি Linux ডিস্ট্রিবিউশন পান, তার ভিতরে VPN ক্লায়েন্ট ইনস্টল করেন, আর শেল ঘোষণা করে টানেল সম্পূর্ণ হয়েছে। তারপর ব্রাউজারে গেলে ট্রাফিক মোবাইল ডেটা দিয়ে বেরিয়ে যায়, যেন কিছুই হয়নি। অথবা উল্টোটা: ফোনের প্রতিটি অ্যাপ সংযোগ হারায়, কারণ ক্লায়েন্ট Android যে নেমস্পেস সত্যিই ব্যবহার করে সেখানে একটি ডিফল্ট রুট যোগ করেছে। এই দুটি লক্ষণ একই অনুপস্থিত অংশ থেকে আসে, আর কোনোটিই VPN ক্লায়েন্টের বাগ নয়।

শেল বলে সংযুক্ত, অ্যাপগুলো একমত নয়

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

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

দুটোর কোনটি পেয়েছেন তা একটি কমান্ডেই বোঝা যায়। chroot-এর ভিতরের ip route বাইরের Android শেলের একই কমান্ডের সঙ্গে তুলনা করুন। একই আউটপুট মানে chroot হোস্ট নেমস্পেসে: এটি যে নেটওয়ার্ক পরিবর্তনই করে তা পুরো ফোনের জন্য। ভিন্ন আউটপুট মানে লঞ্চার এর জন্য একটি নেমস্পেস তৈরি করেছে, এবং এর টানেল গঠনগতভাবেই Android-এর কাছে অদৃশ্য।

chroot কী বদলেছে আর কী বদলায়নি

ObjectEffect of a chroot
Pathname resolutionChanged: lookups start at the new root
Kernel and driversUnchanged: the phone's kernel, its TUN driver, its limits
Network namespaceUnchanged unless the launcher creates one
Android VPN registrationUnchanged: no app consented, no VPN is selected

chroot সিস্টেম কল একটি কাজ করে: পথ অনুসন্ধানের জন্য ব্যবহৃত ডিরেক্টরি বদলায়। man পৃষ্ঠা স্পষ্ট বলে এটি নিরাপত্তা সীমা নয়, এবং ইন্টারফেস, রুট বা VPN অবস্থা সম্পর্কে কিছুই বলে না। মানুষ Linux কন্টেইনার থেকে যা আশা করে — আলাদা নেটওয়ার্ক স্ট্যাক, ফিল্টার করা ফাইলসিস্টেম, সম্পদের সীমা — তা আসে অন্য প্রক্রিয়া থেকে, যা লঞ্চার ব্যবহার করেছে বা করেনি।

তাই chroot VPN আলাদা করে বলে দাবিগুলো সাধারণত ভুল প্রশ্নের উত্তর দেয়। প্রাসঙ্গিক প্রশ্ন হলো প্রক্রিয়াটি কোন নেমস্পেসে চলে এবং কোন SELinux ডোমেইনে সীমাবদ্ধ, আর দুটোই এটি কীভাবে চালু হয়েছে তার বৈশিষ্ট্য, chroot শব্দটির নয়।

TUN-এ তিনটি জিনিস লাগে, ডিভাইস নোড তার একটি মাত্র

প্রচলিত ইউজারস্পেস টানেলের দরকার নিজে খুলতে পারে এমন TUN ডিভাইস, সেই ডিভাইসের জন্য কার্নেল সমর্থন, এবং ইন্টারফেস ও রুট কনফিগার করার অনুমতি। এগুলো আলাদা শর্ত, আর /dev-এর নিচে একটি পাথ নাম তৈরি করলে নিজে থেকে এর কোনোটিই পূরণ হয় না:

ls -l /dev/net/tun
ip tuntap add dev tun0 mode tun

Android-এ কার্নেলে সাধারণত TUN সমর্থন কম্পাইল করা থাকে, কারণ প্ল্যাটফর্মের নিজের VPN সেবা এটি ব্যবহার করে, কিন্তু এর মানে এই নয় যে আপনার প্রক্রিয়া এটি ব্যবহার করতে পারে। ইন্টারফেস কনফিগারেশনের জন্য নেটওয়ার্ক প্রশাসন সক্ষমতা লাগে, আর SELinux ঠিক করে প্রক্রিয়াটি ডিভাইস নোডে পৌঁছাতে পারে কি না। অস্বীকৃতি স্পষ্ট কারণহীন অনুমতি ত্রুটির মতো দেখায়, আর উত্তর আছে অডিট ট্রেইলে:

dmesg | grep avc
logcat -d | grep "avc: denied"

root এটি সমাধান করে না। SELinux uid 0-এ চলা প্রক্রিয়াকে অন্যদের মতোই সীমাবদ্ধ করে, তাই root শেল থেকে চালু chroot যে ডিভাইস দেখতে পায় সেটিও অস্বীকৃত হতে পারে। পুরনো ইনস্টলার চালাতে এনফোর্সমেন্ট বন্ধ করা পুরো ফোনের জন্য সিদ্ধান্ত যার পরিণতি টানেলের অনেক বাইরে, আর এটি বাসি বাইনারির সমাধান নয়।

কেন Android অ্যাপগুলো আপনার টানেল এড়িয়ে যায়

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

chroot-এর ভিতরের ডিমন কখনো নিবন্ধন করে না। সম্মতির ডায়ালগ নেই, স্টেটাস বারে চাবির আইকন নেই, প্রতি-অ্যাপ অন্তর্ভুক্তি বা বাদ তালিকা নেই, আর সর্বদা-সক্রিয় নীতিতে অংশগ্রহণ নেই। তাই অ্যাপগুলো ডিফল্ট নেটওয়ার্কই ব্যবহার করে, আর টানেল কেবল শেল নিজে যা পাঠায় তা বহন করে।

উল্টো দিকেও লাভ নেই। হোস্ট নেমস্পেসে রুট ঠেলে দেওয়া সবকিছু ধরে ফেলে, প্ল্যাটফর্ম স্থানীয় রাখতে চাওয়া ট্রাফিকসহ, এবং তা করে প্রতি-অ্যাপ নিয়ন্ত্রণহীনভাবে, ব্যবহারকারীর দেখার বা বাতিল করার উপায় ছাড়াই। chroot ডিমন কেবল একটি অ্যাপের জন্য ট্রাফিক রাউট করে এমন মধ্যম সেটিং নেই।

বাইনারি সামঞ্জস্য আলাদা দেয়াল

নেটওয়ার্কের দিক আকর্ষণীয় হলেও চলনযোগ্য ফাইলের নিজের চাহিদা আছে: CPU আর্কিটেকচার, ডাইনামিক লোডার, C লাইব্রেরি এবং যে কার্নেল সুবিধা এটি আশা করে। Android glibc-এর বদলে bionic ব্যবহার করে, আর ডেস্কটপ ডিস্ট্রিবিউশনের জন্য তৈরি পুরনো বাইনারির এমন লাইব্রেরি লাগতে পারে যা ডিভাইসে আর নেই।

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

Android প্রেক্ষাপটে প্রমাণ করুন এবং পরে পরিষ্কার করুন

আপনার সত্যিই যা দরকার তা গুরুত্বপূর্ণ দিক থেকেই পরীক্ষা করুন: নির্দিষ্ট অ্যাপ খুলুন, নির্দিষ্ট ব্যক্তিগত গন্তব্যে পৌঁছান, কোন রিজলভার উত্তর দিয়েছে নিশ্চিত করুন, তারপর টানেল বিচ্ছিন্ন করে নথিভুক্ত আচরণ নিশ্চিত করুন। chroot-এর ভিতরের টার্মিনাল থেকে পাওয়া ফলাফল কেবল সেই টার্মিনালের নির্বাহ প্রেক্ষাপটের প্রমাণ, এর বেশি নয়।

পরীক্ষার সময় হোস্ট রুট বদলে থাকলে সেগুলো ফিরিয়ে দিন এবং কী বদলেছেন লিখে রাখুন। তারপর দেখুন ফোনে সর্বদা-সক্রিয় VPN কনফিগার করা আছে কি না, কারণ নিয়ম রেখে যাওয়া পুরনো পরীক্ষা মাসখানেক পরে প্ল্যাটফর্মের ত্রুটি মনে হতে পারে।

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

সম্পর্কিত নিবন্ধ