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 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

ان میں سے صرف ایک کمانڈ آپ کے میزبان کی ہے۔ دونوں چلا کر آؤٹ پٹ کا موازنہ کرنا یہ جاننے کا طریقہ ہے کہ کون آپ سے جھوٹ بول رہا ہے، تشخیصی طریقہ نہیں۔

پیکج کی ملکیت، ترتیب کی لوڈنگ اور پروٹوکول کی مطابقت کو تین الگ سوالات سمجھیں۔ ایک فرنٹ اینڈ کے لیے درست فائل ورنہ بار بار تبدیل ہوتی رہے گی جبکہ کوئی دوسرا ڈیمن چل رہا ہو۔