OpenVPN নাকি IKEv2: প্রোটোকল বেছে নেওয়ার আগে চারটি যাচাই

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

ক্লায়েন্ট না থাকলে আলোচনা শেষ

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

Windows-এ একটি কমান্ড ইতিমধ্যে থাকা প্রোফাইলগুলো তালিকাভুক্ত করে এবং প্রতিটির ধরন দেখায়। এটি যে নাম ছাপে সেটিই পরের যাচাইগুলো ব্যবহার করে।

Get-VpnConnection -AllUserConnection
Get-VpnConnection -Name <profile-name> | Select-Object Name, ServerAddress, TunnelType

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

গতিশীলতা প্রোটোকলের প্রতিশ্রুতি নয়, যৌথ সেটিং

IKEv2 MOBIKE ব্যবহার করতে পারে যখন উভয় প্রান্ত এটি সমর্থন ও চালু করে, যা ক্লায়েন্টকে তার ঠিকানা বদলালেও টানেল ধরে রাখতে দেয়। RFC 4555 এই এক্সটেনশনটি সংজ্ঞায়িত করে, আর শর্তসাপেক্ষ ভাষাটি গুরুত্বপূর্ণ: যে সার্ভার সামর্থ্যটি উপেক্ষা করে সে বরং নতুন করে দরকষাকষি করে। ফলাফল ফাইল স্থানান্তরে একই রকম দেখাতে পারে আর লাইভ কলে সম্পূর্ণ ভিন্ন।

যে পরিবর্তনটি আপনার সত্যিই গুরুত্বপূর্ণ সেটি পরীক্ষা করুন, এমন কিছু চালু রেখে যা আপনি দেখতে পারেন। Windows-এ ping -t <internal-host> চালু রাখুন, অথবা সাধারণ ping অন্যত্র, তারপর Wi-Fi থেকে সেলুলারে যান এবং ফাঁক খেয়াল করুন। MOBIKE ব্যর্থতা ক্লায়েন্ট লগে নীরব ঠিকানা হালনাগাদের বদলে সম্পূর্ণ পুনঃপ্রমাণীকরণ হিসেবে দেখা যায়। আপনি মাপছেন টানেলটি পরিবর্তনটি টিকিয়ে রাখে কি না, প্রোটোকল সমর্থনের বিজ্ঞাপন দেয় কি না তা নয়।

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

ক্রেডেনশিয়াল স্ট্যাকের নয়, সেবার

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

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

openssl x509 -in client.crt -noout -subject -issuer -dates

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

টানেলটি আসলে কী রুট করে তা যাচাই করুন

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

Windows-এ দুটি কমান্ড রুট ও নাম অনুসন্ধান ঢেকে দেয়। Linux-এ সমতুল্য হলো ip route show default এবং resolvectl query <internal-host>।

Get-NetRoute -DestinationPrefix 0.0.0.0/0
Resolve-DnsName <internal-host>

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

যাচাইয়ের পর রক্ষণাবেক্ষণ বিবেচনা করুন

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

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