ম্যানেজ করা কাজের অ্যাপের জন্য VPN ও প্রক্সি অবস্থা কীভাবে পড়বেন

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

অ্যাপ ও তার প্রোফাইল থেকেই শুরু করুন

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

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

প্ল্যাটফর্ম যে অবস্থা জানায় তা পড়ুন

আপনার সাপোর্ট টুলিংয়ের বিদ্যমান একটি অ্যাক্টিভিটির ভেতরে, API 23 বা পরবর্তীতে, একটি বাইট না পাঠিয়েই নেটওয়ার্ক অবস্থা পড়া যায়। কলে সক্ষমতা পড়ার জন্য স্বাভাবিক ACCESS_NETWORK_STATE ম্যানিফেস্ট অনুমতি দরকার।

val cm = getSystemService(android.net.ConnectivityManager::class.java) ?: return
val network = cm.activeNetwork
val caps = network?.let { cm.getNetworkCapabilities(it) }
val hasVpn = caps?.hasTransport(android.net.NetworkCapabilities.TRANSPORT_VPN)
val proxy = cm.defaultProxy

প্রতিটি মান একটি সংকীর্ণ প্রশ্নের উত্তর দেয়। সক্রিয় নেটওয়ার্ক হলো সেই মুহূর্তে কলকারী প্রক্রিয়ার ডিফল্ট নেটওয়ার্ক। সক্ষমতা পরীক্ষা বলে দেয় সেই ডিফল্ট নেটওয়ার্কটি VPN-সমর্থিত কি না। প্রক্সি কলটি কার্যকর ডিফল্ট HTTP প্রক্সি জানায়, এবং ফেরত দেওয়া অবজেক্টটি হয় স্থির প্রক্সি নয় PAC স্ক্রিপ্ট বর্ণনা করতে পারে।

যদি ডিফল্টের বদলে প্রতি-নেটওয়ার্ক দৃশ্য দরকার হয়, একই নেটওয়ার্কের লিংক বৈশিষ্ট্য পড়ুন এবং cm.getLinkProperties(network)?.httpProxy এর সঙ্গে তুলনা করুন। ডিভাইস ব্যবস্থাপনা যে প্রক্সি ইনস্টল করে তা ডিফল্ট-প্রক্সি কলে দেখা যায় এবং লিংক বৈশিষ্ট্যে দেখা যায় না, যা নীতি-প্রদত্ত প্রক্সি ও নেটওয়ার্ক-প্রদত্ত প্রক্সির মধ্যে তফাত করার দ্রুত উপায়।

আউটপুটটি প্রকাশ্য প্রতিবেদনের বদলে আপনার সাপোর্ট চ্যানেলে রাখুন। প্রক্সি হোস্টনাম, PAC URL এবং অভ্যন্তরীণ সাফিক্স প্রকাশ করে আপনার প্রতিষ্ঠান ট্র্যাফিক কীভাবে রুট করে, এবং ব্যর্থতা বর্ণনা করতে এগুলোর কোনোটিই দরকার নেই।

প্রতিটি ক্ষেত্র সংকীর্ণভাবে ব্যাখ্যা করুন

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

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

শূন্য ডিফল্ট প্রক্সি বোঝায় এই API কার্যকর কনফিগারেশনের জন্য কোনো ডিফল্ট HTTP প্রক্সি জানায় না। এটি খুব কমই বাদ দেয়: একটি অ্যাপ নিজের SOCKS সেটিং বহন করতে পারে, নিজের HTTP ক্লায়েন্ট বাস্তবায়ন করতে পারে, বা গেটওয়েতে থাকা একটি প্রক্সি দিয়ে চালিত হতে পারে যা ডিভাইস কখনো জানে না।

PAC হলো সেই ক্ষেত্র যা একক-মান উত্তরকে হারিয়ে দেয়। একটি স্ক্রিপ্ট একটি গন্তব্য প্রক্সি দিয়ে পাঠাতে পারে আর অন্যটি সরাসরি, তাই একই অ্যাপের এক সেকেন্ডের মধ্যে দুটি অনুরোধ ভিন্ন পথ নিতে পারে। আর যে অ্যাপ তার সকেট বাছাই করা নেটওয়ার্কে বেঁধে দেয়, বা bindProcessToNetwork কল করে, সেটি ডিফল্ট মানতে বাধ্য নয়।

এই স্ন্যাপশট আপনাকে যা বলতে পারে না

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

এটি সকেটের উপরে কী ঘটে সে সম্পর্কেও কিছু বলে না। ম্যানেজ করা ডিভাইসে ব্যর্থ হওয়া একটি TLS হ্যান্ডশেক ট্রাস্ট-স্টোর সমস্যা, পিনিং মিলহীনতা বা প্রক্সি যে নাম প্রত্যাখ্যান করে তা হতে পারে, এবং এর কোনোটিই সংযোগ-পাঠে দেখা যায় না।

এইজন্যই দুই অর্ধেক একসঙ্গে গুরুত্বপূর্ণ: স্ন্যাপশট সংকুচিত করে কোথায় দেখবেন, আর অ্যাপের নিজের ডায়াগনস্টিকস বলে কী সত্যিই ব্যর্থ হয়েছে।

প্রশাসক ব্যবহার করতে পারেন এমন আকারে তা জানান

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

তারপর থামুন এবং পথের মালিককে উত্তর দিতে দিন। কোনো কর্পোরেট সার্টিফিকেট, প্রক্সি ঠিকানা বা VPN এন্ট্রিকে ব্যবস্থাপনা সরানোর বা অনুমোদিত রুট এড়ানোর অনুমতি ভাববেন না; তা একটি সাপোর্ট কেসকে নীতি-ঘটনায় পরিণত করে।

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