Android অ্যাপ VPN-এ চলতে চায় না: কোন স্তর সিদ্ধান্ত নেয়

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

ধাপ 1: অ্যাপ কখন অস্বীকার করে তা জানুন

সময়ই প্রথম পার্থক্যকারী। লগ বাফার পরিষ্কার করুন, ব্যর্থতাটি পুনরুৎপাদন করুন এবং অ্যাপটি অভিযোগ করার আগে কী করেছিল দেখুন:

adb logcat -c
# reproduce the failure in the app
adb logcat -d | grep -iE 'vpn|network|connect|http' | tail -60

যদি অ্যাপটি কোনো বহির্গামী অনুরোধের চেষ্টার আগেই অস্বীকার করে, তবে আপনি স্থানীয় সিদ্ধান্ত দেখছেন। যদি এটি সংযোগ করে, কিছু পাঠায় এবং তারপর ত্রুটি দেখায়, তবে প্রত্যাখ্যান এসেছে অন্য দিক থেকে। যদি টানেল বন্ধ থাকলেও অ্যাপ একইভাবে ব্যর্থ হয়, তবে VPN কখনও পরিবর্তনশীল ছিল না।

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

ধাপ 2: ফোন নিজে নেটওয়ার্ককে কীভাবে দেখে তা পড়ুন

Android VPN অবস্থাকে নেটওয়ার্ক সক্ষমতা হিসেবে প্রকাশ করে, তাই একটি টানেল সক্রিয় আছে বুঝতে অ্যাপের বাণিজ্যিক সরবরাহকারীর তালিকা দরকার নেই। এটি সংযোগ পরিষেবাকে জিজ্ঞাসা করে বর্তমান নেটওয়ার্ক কী, এবং উত্তরটিতে VPN ট্রান্সপোর্ট বিট থাকে:

val cm = context.getSystemService(ConnectivityManager::class.java)
val caps = cm.getNetworkCapabilities(cm.activeNetwork)
val onVpn = caps?.hasTransport(NetworkCapabilities.TRANSPORT_VPN) == true

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

কর্মক্ষেত্র থেকে আপনি একটি পরীক্ষার ডিভাইসে adb shell dumpsys connectivity ব্যবহার করে এবং VPN নেটওয়ার্কের এন্ট্রি খুঁজে একই অবস্থা দেখতে পারেন। টানেল চালু অবস্থার একটি রান টানেল বন্ধ অবস্থার রানের সঙ্গে তুলনা করুন, এবং দুটি আউটপুটই রেখে দিন।

ধাপ 3: সার্ভার আসলে কী দেখে তা পড়ুন

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

ঠিকানাটি অ্যাপ যে পথ ব্যবহার করে সেই পথ থেকেই নিন, ল্যাপটপের ব্রাউজার থেকে নয়। ফোনে ঠিকানা-প্রতিধ্বনি পরিষেবায় একটি সাধারণ অনুরোধ দেখায় দূরবর্তী প্রান্ত কী পায়, এবং সেটি সেলুলার দিয়ে করা অনুরোধের সঙ্গে তুলনা করলে বোঝা যায় ঠিকানাটি আদৌ বদলেছে কি না।

যদি অ্যাপটি সেলুলারে কাজ করে এবং একই অ্যাকাউন্ট দিয়ে টানেলে ব্যর্থ হয়, তবে প্রত্যাখ্যান দূরবর্তী প্রান্তে বা অ্যাপের নিজের নীতিতে। যদি দুটিতেই ব্যর্থ হয়, তবে VPN কোনো পার্থক্যকারী নয় এবং আপনার এন্ডপয়েন্ট পরীক্ষা বন্ধ করা উচিত।

ধাপ 4: প্রমাণকে তিনটি রায়ের একটির সঙ্গে মিলিয়ে নিন

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

যে প্রমাণ রায়টি তৈরি করেছে তার সঙ্গে রায়টি লিখে রাখুন। এই ধাপের মূল্য হল এটি সেই চক্র থামায় যেখানে কেউ হ্যান্ডসেটেই চলা পরীক্ষা ঠিক করতে চারবার আউটলেট নোড বদলায়।

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

ধাপ 5: সমর্থিত পথ নিন এবং তা যাচাই করুন

পণ্যের নথিভুক্ত নীতি ও তার সহায়তা-মালিক দিয়ে শুরু করুন। ক্লায়েন্ট সংস্করণ, সঠিক বার্তা এবং একটি সংকীর্ণ ব্যর্থতার সময়-জানালি পাঠান; শুধু ত্রুটি আছে প্রমাণ করতে সম্পূর্ণ ট্রাফিক ক্যাপচার বা শংসাপত্র পাঠাবেন না।

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

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