Android VPN সার্ভার: root থাকলেও ফোনটি নাগালের বাইরে থেকে যায়
তিনটি আলাদা সমস্যা ঠিক করে ফোনটি VPN ক্লায়েন্টকে সেবা দিতে পারবে কি না: আগত পথ, বিশেষাধিকার মডেল ও ফরওয়ার্ডিং। root কেবল মাঝেরটিতেই হাত দেয়।
root ঠিক করে একটি প্রসেস কোন নেটওয়ার্কিং অপারেশন চেষ্টা করতে পারবে। এটি ফোনকে প্রকাশ্যে নাগালযোগ্য ঠিকানা দেয় না, ক্যারিয়ারের কাছে আগত ম্যাপিং সংরক্ষণ করে না, আর রিবুটের পরও কোনো ডেমনকে সচল রাখে না। Android ফোন VPN সার্ভার হিসেবে কাজ করতে পারবে কি না ঠিক করার সময় তিনটি প্রশ্ন আলাদা করুন: লক্ষ্য ক্লায়েন্ট লিসেনারে আদৌ পৌঁছাতে পারে কি, সার্ভার বাস্তবায়নের জন্য কোন বিশেষাধিকার মডেল দরকার, এবং টানেল ওঠার পর কী ফরওয়ার্ড করতে হবে।
কে এবং কোথা থেকে ফোনে পৌঁছাতে হবে
একই অনুমোদিত LAN-এর ক্লায়েন্ট আর মোবাইল ডেটার ক্লায়েন্ট দুটি ভিন্ন নেটওয়ার্ক পরীক্ষা করছে। আগে লক্ষ্যটি নির্ধারণ করুন, কারণ উত্তর দুটি একে অপরের ওপর প্রযোজ্য নয়। Wi-Fi-তে অচাওয়া আগত ট্রাফিকের সাধারণত আপস্ট্রিম রাউটারে ম্যাপিং দরকার এবং তার পরেও ব্যবহারযোগ্য পাবলিক পথ দরকার। সেলুলারে carrier-grade NAT-এর অর্থ হলো আগত IPv4 প্রায়ই অনুপলব্ধ, ফোন যা-ই অনুমোদন করুক।
শেষ কথাটিই এমন যা root ছুঁতে পারে না। ফোনের স্থানীয় ফায়ারওয়াল আর ক্যারিয়ারের NAT ভিন্ন ব্যবস্থা, আর প্রথমটি বদলালে দ্বিতীয়টিতে কোনো প্রভাব পড়ে না। একটি প্রাইভেট ইন্টারফেস ঠিকানা, মোবাইল-ডেটা আইকন বা লিসেনিং সকেট নাগালযোগ্যতার প্রমাণ নয়। ক্যারিয়ারের পথ যদি সত্যিই বিশ্বব্যাপী রাউটযোগ্য IPv6 দেয়, তবুও তার জন্য সচেতন লিসেনার ও ফায়ারওয়াল নীতি দরকার; ঠিকানা থাকা আর সংযোগ গ্রহণ করা এক নয়।
| Client path | What actually decides reachability |
|---|---|
| Same LAN | The phone's listener and its local firewall |
| Wi-Fi, from the internet | A mapping on the upstream router plus a usable public path beyond it |
| Cellular IPv4 | The carrier's NAT, which the handset does not control |
| Cellular IPv6 | Address, listener and firewall policy together |
সেবা দেওয়া আর ফরওয়ার্ডিং দুটি আলাদা সাফল্য
সম্পূর্ণ VPN হ্যান্ডশেক প্রমাণ করে টানেল আছে। এটি প্রমাণ করে না যে ক্লায়েন্ট ফোনের পেছনের LAN-এ পৌঁছাতে পারে, আর প্রমাণ করে না যে ফোনটি ইন্টারনেট এক্সিট হিসেবে কাজ করতে পারে। এগুলো আলাদা কনফিগারেশন, যা ভেতরের ঠিকানা পরিকল্পনা, রুট, ফেরত আচরণ এবং আপনি যে কাজটি সত্যিই চান তার জন্য সংকীর্ণ পরিসরের ফরওয়ার্ডিং নীতির ওপর দাঁড়ায়।
ব্যর্থতার ধরনটি অনুমেয়: হ্যান্ডশেক সফল হয়, ক্লায়েন্ট সংযুক্ত দেখায়, আর কিছুই লোড হয় না। ক্লায়েন্ট ডিবাগ করার আগে ঠিক করুন দুটি ভূমিকার কোনটি বানাচ্ছেন। ফোনের নেটওয়ার্কে থাকা ডিভাইসে দূরবর্তী প্রবেশ আর পূর্ণ-টানেল ইন্টারনেট এক্সিটের জন্য ভিন্ন ফরওয়ার্ডিং নিয়ম দরকার, আর একটি চাইলে দুটিই দেওয়া আপনার চাওয়া সামর্থ্য না বাড়িয়েই এক্সপোজার বাড়ায়।
বিশেষাধিকার মডেল একটি পছন্দ, root অথবা কিছুই নয় এমন নয়
kernel TUN ডিভাইস ব্যবহার করা প্রচলিত OpenVPN ডেমনের সংশ্লিষ্ট সক্ষমতা, ডিভাইস নোডে প্রবেশাধিকার এবং Android-এর নিরাপত্তা নীতির সহযোগিতা দরকার। root SELinux থেকে সার্বিক অব্যাহতি নয়; বিশেষাধিকারপ্রাপ্ত প্রসেসও প্ল্যাটফর্ম নীতিতে সীমাবদ্ধ থাকে। এজন্যই Linux সার্ভারে সহজে চলা বাইনারি ফোনে অনুমতি সম্পর্কে স্পষ্ট ত্রুটি ছাড়াই ব্যর্থ হতে পারে।
ইউজারস্পেস গেটওয়ে বাস্তবায়নের বিশেষাধিকার মডেল সম্পূর্ণ আলাদা হতে পারে, তাই Android-এ প্রতিটি VPN সার্ভারের root দরকার — এই সাধারণ দাবিটি খুবই বিস্তৃত। root আপনাকে বেশি অপারেশন চেষ্টা করার সামর্থ্য দেয়, সেগুলো অনুমোদিত হবে বা ফলাফল নাগালযোগ্য হবে তার নিশ্চয়তা নয়।
Android-এর নিজস্ব VPN-সেবা নিবন্ধন আবার আলাদা ব্যবস্থা। এটি অ্যাপকে নির্দিষ্ট জীবনচক্রসহ একটি ব্যবস্থাপিত ক্লায়েন্ট ইন্টারফেস দেয়; এটি সাধারণ সার্ভার ইনস্টলার নয়, আর টার্মিনাল থেকে ডেমন চালু করলে সর্বদা-চালু ব্যবস্থাপনা, প্রতি-অ্যাপ নীতি বা নিজস্ব পুনরুদ্ধার পথ পাওয়া যায় না।
আপনি যদি এক্সিট পয়েন্ট চান, আর্কিটেকচার বদলান
লক্ষ্য যদি বিদ্যমান OpenVPN প্রোফাইলের সঙ্গে সামঞ্জস্য না হয়, বরং কেবল ফোনের মাধ্যমে দূরবর্তী ইন্টারনেট নির্গমন হয়, তবে সমর্থিত ওভারলে এক্সিট নোড বেশি উপযুক্ত নকশা। Tailscale নিজস্ব নিবন্ধন, অনুমোদন ও ক্লায়েন্ট-নির্বাচন ধাপসহ Android এক্সিট-নোড ভূমিকা নথিভুক্ত করে।
বিনিময়টি বাস্তব এবং স্পষ্ট করে বলা দরকার: আপনি ভিন্ন প্রোটোকল, ভিন্ন বিশ্বাস মডেল এবং ওই অ্যাকাউন্ট ও সমন্বয় সেবার ওপর নির্ভরতা মেনে নিচ্ছেন। এটি অপরিবর্তিত OpenVPN ক্লায়েন্টকে ওভারলে-এ যোগ করে না, আর আপনাকে পাবলিক ঠিকানায় OpenVPN লিসেনারও দেয় না।
স্থাপনায় আরও যা দরকার
যে পথই নিন, চালনাগত মৌলিক বিষয়গুলোই ঠিক করে এটি এক সপ্তাহ টিকবে কি না। সার্ভারের ক্রেডেনশিয়াল গোপন রাখুন, আলাদা আলাদা ক্লায়েন্ট পরিচয় দিন, এবং দরকার হওয়ার আগেই বাতিলের পরিকল্পনা করুন। আপডেট কীভাবে আসে, ব্যাকগ্রাউন্ডে সেবাটি কী সচল রাখে এবং রিবুট বা নেটওয়ার্ক পরিবর্তনের পর এটি কীভাবে ফিরে আসে তা ঠিক করুন।
সুবিধাজনক দেখানো শর্টকাট এড়িয়ে চলুন: পুরোনো স্ট্যাটিক বাইনারি, কোডে বসানো ইন্টারফেস নাম, আর এমন স্টার্টআপ স্ক্রিপ্ট যা বিদ্যমান ফায়ারওয়াল নীতি মুছে দেয়। তারপর ফলাফল গ্রহণ করুন কেবল একটি নির্দিষ্ট পরীক্ষায়: অনুমোদিত দূরবর্তী ক্লায়েন্ট লক্ষ্য রিসোর্সে পৌঁছায়, নিষিদ্ধ গন্তব্য অনুপলব্ধ থাকে, এবং সমর্থিত জীবনচক্র ইভেন্টের পর ডিভাইস নিজে থেকেই ফিরে আসে। root প্রবেশাধিকার সেই ফলাফলের একটি সম্ভাব্য উপাদান, এবং বিরল ক্ষেত্রেই নির্ণায়ক।