OpenVPN راستہ strongSwan XFRM پالیسی سے کیوں ہارتا ہے

پیکٹ OpenVPN راستے پر چلتے ہوئے بھی IPsec پالیسی کی گرفت میں آ سکتے ہیں، اور یہ امتزاج درست زاویے کے سوا ہر زاویے سے روٹنگ کی خرابی جیسا لگتا ہے۔ Linux راستہ حل کرتا ہے اور پھر الگ سکیورٹی پالیسی ڈیٹا بیس سے رجوع کرتا ہے، اس لیے زیادہ مخصوص منزل کا راستہ کسی مماثل XFRM پالیسی کو ہٹاتا نہیں۔ نظر آنے والی علامت وہ ٹریفک ہے جو میزبان چھوڑتی ہے اور کبھی نہیں پہنچتی، جبکہ دونوں سرنگیں خود کو صحت مند قرار دیتی ہیں۔ تین اختیارات اسے حل کرتے ہیں، اور آپ کون سا چنتے ہیں یہ اس پر منحصر ہے کہ دو راستوں میں سے کس کو وہ سابقہ لے جانا ہے۔

دو فیصلے، ایک نہیں

راستے کا انتخاب ایک تنگ سوال کا جواب دیتا ہے: کون سی اگلی چھلانگ اور ماخذ پتہ یہ پیکٹ لے جائے۔ سکیورٹی پالیسی ڈیٹا بیس دوسرے کا جواب دیتا ہے: کیا اس پیکٹ کو IPsec تحفظ درکار ہے، اور کن انتخاب کنندگان کے تحت۔ دونوں ایک ہی پیکٹ کے لیے چلتے ہیں، اور پہلا پورا کرنا دوسرے کے بارے میں کچھ نہیں کہتا۔ اسی لیے میٹرک بدلنے یا جامد راستہ شامل کرنے سے علامت اچھوتی رہ سکتی ہے۔

چوڑا IPsec انتخاب کنندہ عام سبب ہے۔ 172.16.0.0/12 کی حفاظت کرنے والی پالیسی 172.20.8.0/24 کو بھی ڈھانپتی ہے، جہاں منتظم شاید OpenVPN سرنگ کے ذریعے پہنچنا چاہتا ہے۔ ارادہ صرف روٹنگ جدول میں موجود ہے، اور پالیسی ڈیٹا بیس کو اس کی کبھی خبر نہیں ہوئی۔

اسے دو میٹرک کا مقابلہ نہیں بلکہ تشکیل شدہ دو حفاظتی راستوں کا تصادم سمجھیں۔ اصلاح اسی جزو میں ہونی چاہیے جو غلط دائرے کے ساتھ تشکیل دیا گیا تھا۔

وہ راستہ پڑھیں جو کرنل واقعی چنتا ہے

کرنل جو تلاش کرتا ہے اس سے شروع کریں، جس میں ماخذ پتہ اور کوئی بھی پالیسی قاعدہ شامل ہے جو اسے کسی دوسرے جدول میں موڑ سکتا ہے۔ مرکزی جدول کا راستہ کبھی نہ دیکھا جا سکتا ہے اگر کوئی پہلے کا قاعدہ دوسرا جدول چنے، اور طویل ترین سابقہ کی مطابقت صرف اسی جدول کے اندر لاگو ہوتی ہے جسے کوئی قاعدہ چنتا ہے۔

ip rule show
ip route show table all
ip route get 172.20.8.20 from 10.44.7.15

آخری حکم ہی اہم ہے، کیونکہ یہ چنے گئے راستے کے ساتھ وہ ماخذ پتہ چھاپتا ہے جو کرنل استعمال کرے گا۔ اس اخراج کا موازنہ اس انتخاب کنندہ سے کریں جس سے IPsec پالیسی مطابقت رکھتی ہے۔ جب راستہ OpenVPN انٹرفیس کی طرف اشارہ کرے اور پالیسی اب بھی اسی جوڑے سے مطابقت رکھے، تو آپ نے اندازہ لگائے بغیر تصادم دہرا دیا ہے۔

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

وہ پالیسی بھی پڑھیں جو لاگو ہوتی ہے

پالیسی فہرست سمت، انتخاب کنندگان اور وہ سانچہ دکھاتی ہے جو طے کرتا ہے کہ مماثل پیکٹ کے ساتھ کیا ہوگا۔ پہلے باہر جانے والی سمت پڑھیں، پھر واپس آنے والی ٹریفک کے لیے اندر آنے والا پہلو، کیونکہ یک طرفہ استثنا ایسا رابطہ بناتا ہے جو شروع ہو کر کبھی مکمل نہیں ہوتا۔

ip -s xfrm policy
swanctl --list-sas

فہرست کے انتخاب کنندگان کا موازنہ ان سابقوں سے کریں جن پر رابطے نے گفت و شنید کی۔ strongSwan کی راستہ تنصیب بند کرنا وہ پالیسیاں نہیں ہٹاتا، اور میٹرک بدلنا یہ نہیں بدلتا کہ پالیسی کس ماخذ و منزل جوڑے کی حفاظت کرتی ہے۔ یہ دونوں جعلی اصلاحات ابتدا ہی میں خارج کرنے کے قابل ہیں، کیونکہ لوگ پہلے یہی آزماتے ہیں۔

اگر فہرست میں آپ کے متوقع سابقے کے لیے کوئی پالیسی نہ ہو، تو مسئلہ کہیں اور ہے اور روٹنگ جدول غالباً سچ کہہ رہا ہے۔ اگر اس میں سابقے کو ڈھانپنے والی زیادہ چوڑی پالیسی ہو، تو آپ نے گرفت پا لی ہے۔

جب دونوں راستے جائز ہوں تو تین اختیارات

IPsec انتخاب کنندہ تنگ کرنا سب سے صاف اختیار ہے جب چوڑا سابقہ ضرورت کے بجائے سہولت تھا۔ دور کی ٹریفک کے انتخاب کنندہ کو ان ذیلی نیٹ ورکس تک کم کرنا جو واقعی IPsec کے پیچھے ہیں، ایک ہی وقت میں ہر میزبان کے لیے تصادم ہٹا دیتا ہے، اور اس کی قیمت نئی کلید کی گفت و شنید ہے، نیا جزو نہیں۔

جب چوڑا انتخاب کنندہ رہنا ہی چاہیے تو گزر کا استثنا جراحی اختیار ہے۔ strongSwan ایسا الگ رابطہ فراہم کرتا ہے جس کا child pass موڈ استعمال کرتا ہے، جو کرنل کو بتاتا ہے کہ مماثل ٹریفک کو IPsec پر کارروائی نہیں کرنی چاہیے۔ loopback کا دور کا پتہ اس رابطے کو آنے والے ساتھیوں کے لیے منتخب ہونے سے روکتا ہے، اور انتخاب کنندگان کو ہر چیز کے بجائے حقیقی مجاز جوڑے کی وضاحت کرنی چاہیے۔

connections {
    openvpn-exception {
        remote_addrs = 127.0.0.1
        children {
            openvpn-exception {
                local_ts = 10.44.7.0/24
                remote_ts = 172.20.8.0/24
                mode = pass
                start_action = trap
            }
        }
    }
}

strongSwan ترتیب کی مثالیں اس پالیسی قسم اور loopback ساتھی کی روایت کی دستاویز کرتی ہیں۔ تیسرا اختیار XFRM انٹرفیسوں کے ساتھ راستے کی بنیاد پر ڈیزائن ہے، جو پالیسی کو عالمی انتخاب کنندہ کے بجائے نامزد انٹرفیس سے گزرنے والی ٹریفک سے جوڑتا ہے۔ یہ ایڈجسٹمنٹ نہیں بلکہ منتقلی ہے، اور ٹریفک کو اب بھی طے شدہ انتخاب کنندگان پورے کرنے ہوں گے۔

باقی کو کمزور کیے بغیر استثنا ثابت کریں

تبدیلی لوڈ کرنے کے بعد استثنا اور ایک عام منزل آزمائیں جسے محفوظ رہنا چاہیے۔ دونوں سمتیں جانچیں، پھر OpenVPN سرنگ گرا دیں اور تصدیق کریں کہ مستثنیٰ ٹریفک کے ساتھ کیا ہوتا ہے۔ ایسا استثنا جو سرنگ بند ہونے پر وہ سابقہ خاموشی سے کھلے طور پر بھیجے، وہ پالیسی فیصلہ ہے جو آپ کو جان بوجھ کر کرنا چاہیے، کسی واقعے کے دوران دریافت کرنا نہیں۔

لکھیں کہ کون سا سابقہ کون سا راستہ استعمال کرتا ہے اور کیوں۔ ورنہ چوڑا انتخاب کنندہ دیکھنے والا اگلا انجینئر وہی تحقیقات دوبارہ کھولے گا، اور جواب کسی commit پیغام میں پڑا رہے گا جسے کوئی نہیں پڑھتا۔