ipsec.conf নাকি swanctl.conf? strongSwan-এর একটি ফ্রন্টএন্ড বেছে নিন

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

দুটি ফাইল, দুটি লোডার, একটি ডেমন

পুরোনো starter ব্যবস্থা ipsec.conf পড়ে এবং নিজের পুরোনো ব্যবস্থাপনা ইন্টিগ্রেশনের মাধ্যমে সংযোগগুলো charon-কে দেয়। এর পরিচালনাগত প্রবেশবিন্দু হলো ipsec কমান্ড।

swanctl ব্যবস্থা VICI-এর মাধ্যমে সংজ্ঞা লোড করে, swanctl.conf পড়ে এবং swanctl কমান্ড দিয়ে চালিত হয়। systemd-নির্ভর charon ডেমন এই পদ্ধতির সঙ্গে একীভূত।

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

ইনস্টল করা প্যাকেজ ও unit পড়ুন

কেবল-পঠন অবস্থায় শুরু করুন। Ubuntu 24.04-এ প্যাকেজের নাম আলাদা: strongswan-starter, strongswan-swanctl এবং charon-systemd। অনুপস্থিত প্যাকেজ উপকারী তথ্য, এটি ইনস্টল করার নির্দেশ নয়।

একবারেই প্যাকেজ ও unit-গুলোর তালিকা করুন:

dpkg-query -W strongswan-starter strongswan-swanctl charon-systemd
systemctl list-unit-files '*strongswan*'

তারপর সক্রিয় unit ও তার চালু করার কমান্ড দেখুন। unit-এর নাম বলে দেয় কোন ডেমন কনফিগারেশনের মালিক, আর কমান্ড লাইন নিশ্চিত করে কোন ফাইলগুলো পড়তে বলা হয়েছিল। সক্রিয় করা কিন্তু চলছে না এমন unit এখন চলা unit থেকে ভিন্ন কাহিনি বলে।

সক্রিয় unit যদি strongswan-starter হয়, তবে গুরুত্বপূর্ণ ফাইল ipsec.conf। যদি swanctl-সহ charon-systemd হয়, তবে ipsec.conf নিছক সাজসজ্জা।

মিলে যাওয়া নিয়ন্ত্রণ পথ ব্যবহার করুন

প্রতিটি ফ্রন্টএন্ডের সংযোগ ও অ্যাসোসিয়েশন নিয়ে নিজস্ব দৃষ্টিভঙ্গি আছে। swanctl --list-conns লোড করা সংজ্ঞা দেখায়, আর swanctl --list-sas সক্রিয় অ্যাসোসিয়েশন দেখায়। পুরোনো পথ ipsec statusall ব্যবহার করে।

দুটো মিশিয়ে দিলে বিভ্রান্তিকর ত্রুটি হয়। অনুপস্থিত VICI সকেট বা প্রত্যাখ্যাত নিয়ন্ত্রণ অনুরোধ ব্যবস্থাপনা-পথের সমস্যা, প্রমাণ নয় যে প্রতিপক্ষ প্রমাণীকরণ প্রত্যাখ্যান করেছে।

চালু ডেমনের নিজস্ব দৃষ্টিভঙ্গিটি পড়ুন, তারপর ফলাফলের ব্যাখ্যা করুন। যদি ওই দৃষ্টিভঙ্গিতে সংযোগটি না থাকে, সমস্যা লোডিংয়ে, দর-কষাকষিতে নয়।

ফরম্যাট মানে IKE সংস্করণ নয়

পুরোনো প্রোফাইল keyexchange=ikev1 দিয়ে IKEv1 বেছে নেয়। swanctl সংযোগ একটি সংস্করণ সেটিং ব্যবহার করে, যেখানে 1 মানে IKEv1। এগুলো একই ধারণার দুটি শব্দভান্ডার, রূপান্তর নয়।

প্রতিপক্ষের ঠিকানা, স্থানীয় ও দূরবর্তী পরিচয়, প্রমাণপত্রের উৎস, প্রস্তাব এবং child সিলেক্টর—প্রতিটি সচেতনভাবে ম্যাপ করতে হবে। left/right ব্লক swanctl সিনট্যাক্সে পেস্ট করলে এর কিছুই হয় না।

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

প্রোফাইলে হাত দেওয়ার আগে লোডার দেখুন

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

দুটি নিয়ন্ত্রণ পথ সরাসরি লোডিং প্রশ্নের উত্তর দেয়:

swanctl --list-conns
ipsec statusall

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

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