Android 12 এবং IKEv1 VPN: লঞ্চ সংস্করণ, IKEv2 ও তৃতীয় পক্ষের অ্যাপ

দুটি ফোনই সেটিংসে Android 12 দেখায়, কিন্তু তাদের একটিই এখনও আপনার গেটওয়ে দেওয়া পুরোনো IPsec XAuth প্রোফাইল চালু করে। পার্থক্যটি ব্যবহারকারীর নাগালের সেটিং নয়: নেটিভ লিগ্যাসি IKEv1 পথ নিয়ন্ত্রণ করা গার্ডটি ডিভাইসটি যে SDK স্তর নিয়ে এসেছে তা দেখে, শুধু এখন চলা সংস্করণ নয়। এই একটি বিবরণই ঠিক করে ফ্লিট তুলনার অর্থ আছে কি নেই, এবং তিনটি মাইগ্রেশন পথের কোনটি আপনার সত্যিই দরকার।

দুটি Android 12 ফোন একই পরীক্ষার কেস নয়

নতুন ডিভাইসকে লিগ্যাসি IKEv1 প্রোফাইল চালু করা থেকে বিরত রাখা AOSP পরিবর্তনটি DEVICE_INITIAL_SDK_INT কে Android S-এর সাথে তুলনা করে, অর্থাৎ API 31। নেটিভ লিগ্যাসি স্টার্টআপ পথে যোগ্য প্রোফাইল কোনো কাজের সংযোগ তৈরির আগেই অসমর্থিত-অপারেশন ব্যর্থতা তোলে। Android 11 নিয়ে আসা ও পরে আপডেট হওয়া ফোন এখনও ওই গার্ড পেরোয়; Android 12-এ শুরু হওয়া মডেল পেরোয় না।

ডিবাগিং চালু করে একটি ডিভাইসে দুটি সংখ্যা পড়া যায়:

adb shell getprop ro.product.first_api_level
adb shell getprop ro.build.version.sdk
adb shell getprop ro.build.version.release

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

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

পথ এক: যেখানে এখনও চলে সেখানে নেটিভ লিগ্যাসি স্ট্যাক রাখা

লিগ্যাসি স্ট্যাক হলো সেটিই যা সিস্টেম VPN স্ক্রিন থেকে IPsec XAuth PSK, IPsec Hybrid RSA ও L2TP/IPsec PSK প্রোফাইল পড়ে। API 31-এর নিচে আসা ডিভাইসে আপগ্রেডের পরেও এটি কার্যকর পথ থাকে, তাই পুরোনো হ্যান্ডসেটে পাইলট সফল হতে পারে যখন নতুন হ্যান্ডসেট একই প্রোফাইল চালু করতে পারে না।

প্রকৃত তুলনা ডিভাইস শ্রেণি অনুযায়ী, Android সংস্করণ অনুযায়ী নয়: ফ্লিটের মডেলগুলো তালিকাভুক্ত করুন, তাদের লঞ্চ API স্তর পড়ুন, এবং প্রোফাইল এখনও চালু করে এমন ডিভাইস ও পারে না এমন ডিভাইসে ভাগ করুন। অন্য যেকোনো উপায় এমন সহায়তা নীতি তৈরি করে যা ব্যবহারকারী নতুন ফোন কেনার মুহূর্তেই নিজের বিরোধ করে।

পথ দুই: প্ল্যাটফর্ম IKEv2 প্রোফাইল

IKEv2-এর জন্য Android-এর সার্বজনীন প্রভিশনিং মডেল আলাদা বস্তু, পুনঃনামকৃত IKEv1 প্রোফাইল নয়। IKEv2 প্রোফাইলের প্ল্যাটফর্ম API API 30-এর সাথে এসেছিল এবং গেটওয়ে যে প্রমাণীকরণ পদ্ধতি দেয় তা নিয়ে IKEv2 আশা করে, সাধারণত সার্টিফিকেট-ভিত্তিক বা EAP। IKEv1 XAuth বা Hybrid থেকে IKEv2-তে তার-সামঞ্জস্যপূর্ণ আপগ্রেড নেই: গেটওয়েকে নতুন প্রোটোকলের জন্য কনফিগার করতে হবে, এবং প্রোফাইলকে মিলতে হবে এমন পরিচয় বহন করতে হবে।

এটিই দীর্ঘতম জীবনের পথ, এবং এটিই আসল কাজটি প্রকাশ করে। পরিচয় যাচাই, ব্যবহারকারী প্রমাণীকরণ, DNS, স্প্লিট-টানেল রুট ও সম্পদ অনুমোদন সবই মাইগ্রেশন পার হতে হবে; শুধু হ্যান্ডশেক সফল করলে ব্যবহারকারীরা এমন টানেলে আটকে থাকে যা কোথাও পৌঁছায় না।

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

পথ তিন: তৃতীয় পক্ষের ক্লায়েন্ট অ্যাপ্লিকেশন

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

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

গেটওয়ে কী দিতে পারে তার ভিত্তিতে বেছে নিন

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

দুটি বিষয় পরিকল্পনাটিকে রক্ষণীয় করে। প্রথমত, প্রতিটি ব্যতিক্রমের কারণ মডেল ও লঞ্চ স্তরসহ লিখে রাখুন, যাতে অডিটর দেখতে পান সীমাটি প্ল্যাটফর্ম গার্ড, ব্যাখ্যাহীন পছন্দ নয়। দ্বিতীয়ত, মাইগ্রেশনকে পরিকল্পিত কাজ হিসেবে নিন: IKEv1 স্ট্যান্ডার্ড ট্র্যাকে বাতিল (RFC 9395), অর্থাৎ বাকি ডিভাইসগুলো কমতেই থাকবে এবং ব্যতিক্রমগুলোও তাদের সাথে শেষ হওয়া উচিত।