IPsec গেটওয়ের জন্য WireGuard প্রোফাইল: বরং কী জিজ্ঞাসা করবেন

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

প্রোফাইলে এন্ডপয়েন্ট পুনরায় ব্যবহার করা দুটিকে সেতু করে না। পরবর্তী ধাপ হল গেটওয়ে যিনি চালান তাঁর কাছে একটি অনুরোধ।

প্রথম অনুরোধ: প্রোটোকল সংস্করণ

IPsec একটি পরিবারের নাম দেয়, একক কর্মপ্রবাহ নয়। IKEv2 ও IKEv1 তাদের বিনিময়, প্রমাণীকরণের বিকল্প এবং নেটওয়ার্ক পরিবর্তনের সময় আচরণে ভিন্ন। যে গেটওয়ে কেবল IKEv1 সমাপ্ত করে তার আচরণ IKEv2 অফার করে এমন গেটওয়ের থেকে সম্পূর্ণ আলাদা হবে। ক্লায়েন্ট কনফিগারেশনও তার সাথে ভিন্ন হয়।

জিজ্ঞাসা করুন পরিষেবাটি কোন সংস্করণ সমাপ্ত করে এবং এটি মান-ভিত্তিক বাস্তবায়ন চালায় নাকি নিজস্ব ক্লায়েন্টসহ কোনো বিক্রেতার রূপ। অপারেটিং সিস্টেমের মেনু প্রায়ই সেই উত্তর একটি লেবেলের পিছনে লুকায়। লেবেলটিই প্রোটোকল নয়।

দ্বিতীয় অনুরোধ: ক্লায়েন্টের প্রমাণীকরণ পদ্ধতি

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

একটি WireGuard প্রাইভেট কী এর কোনোটিই নয়। এটি একটি Curve25519 কী যা একটি নির্দিষ্ট হ্যান্ডশেকে ব্যবহৃত হয়। কোনো রূপান্তরই এটিকে সার্টিফিকেট বা EAP ক্রেডেনশিয়ালে পরিণত করে না। যে টুল অন্যথা দাবি করে সে ফাইলটির নাম বদলায় বা অসম্পর্কিত কিছু তৈরি করে।

RFC 7296-এ IKEv2 স্পেসিফিকেশন বর্ণনা করে সেই সংস্করণের একটি বাস্তবায়নকে কী সমর্থন করতে হবে। এটি অস্পষ্ট অপারেটর উত্তরের জন্য একটি তথ্যসূত্র, ক্লায়েন্ট কনফিগারেশনের নির্দেশিকা নয়।

তৃতীয় অনুরোধ: বিশ্বস্ত পরিচয় ও গন্তব্যগুলো

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

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

এন্ডপয়েন্টের একটি পরীক্ষা ক্লায়েন্টের ত্রুটির চেয়ে ভিন্ন প্রশ্নের উত্তর দেয়। অ্যাসোসিয়েশন ছাড়া পৌঁছানো যায় এমন পোর্ট প্রমাণীকরণের দিকে ইঙ্গিত করে, আর পৌঁছানো যায় না এমন পোর্ট পথের দিকে।

# what does the endpoint offer on its IPsec ports?
sudo nmap -sU -p 500,4500 198.51.100.44

# strongSwan: what did the IKE exchange negotiate?
sudo swanctl --list-sas
sudo swanctl --list-conns

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

যখন উভয় প্রোটোকলকে একসাথে থাকতে হয়

উভয় নেটওয়ার্ক পরিচালনা করা উভয় প্রোটোকল রাখার একটি বৈধ কারণ। সাধারণ নকশা WireGuard ও IPsec আলাদা ইন্টারফেস বা আলাদা গেটওয়েতে সমাপ্ত করে। অনুমোদিত ট্র্যাফিক তখন তাদের মধ্যে রাউট করা হয়।

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

এটি যা নয় তা হলো স্বচ্ছ রূপান্তর। WireGuard-এর মাধ্যমে আসা ট্র্যাফিক IPsec টানেলে পুনরায় উৎপন্ন হয়, এবং মাঝখানের প্রতিটি নীতি তার উপর প্রযোজ্য।

প্রথমে সার্ভারের প্রোটোকল ও প্রমাণীকরণের প্রয়োজনীয়তা নির্ধারণ করুন। তারপর অপারেটর যে ক্লায়েন্ট ও নথিভুক্তির পথ সমর্থন করে তা ব্যবহার করুন, এবং সেই সময় প্রাইভেট কী ওয়েব কনভার্টার থেকে দূরে রাখুন।