IPsec سیکیورٹی پالیسی روٹ ٹیبل میں اندراج کیوں نہیں ہے

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

ٹیبل سے نہیں، تلاش سے شروع کریں

کرنل سے پوچھیں کہ وہ واقعی کیا کرے گا: ip route get 10.20.0.5 منتخب راستہ، باہر جانے والا انٹرفیس اور وہ ماخذ پتہ چھاپتا ہے جو وہ استعمال کرے گا۔ سابقہ، پالیسی قاعدہ، نشان یا ترجیحی ماخذ یہ سب جواب بدل سکتے ہیں، اسی لیے زندہ تلاش آنکھ سے ٹیبل پڑھنے سے بہتر ہے۔

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

دونوں طرف منتخب کنندگان ملائیں

پالیسی ڈیٹا بیس کے اپنے اندراجات ہوتے ہیں، اور ہر ایک سمت، ماخذ، منزل اور پروٹوکول بتا کر پھر کہتا ہے کہ ملتے پیکٹوں کے ساتھ کیا ہونا چاہیے۔ انہیں فہرست کرنے کے لیے ip xfrm policy استعمال کریں؛ جھنڈے بتاتے ہیں کہ عمل تحفظ، بائی پاس یا بلاک ہے۔ جس پالیسی کے منتخب کنندگان آپ کے آزمائشی بہاؤ سے وسیع یا تنگ ہیں وہ اس سے نہیں ملے گی، اور پیکٹ غیر محفوظ نکل جائے گا۔ آپ اسی خرابی کی تلاش میں ہیں، گمشدہ راستے کی نہیں۔

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

پالیسی کا میل کھانا نصب شدہ حالت نہیں ہے

ملتی پالیسی صرف کہتی ہے کہ پیکٹ محفوظ ہونا چاہیے؛ تحفظ کرنے کے لیے کرنل کو ابھی بھی سیکیورٹی انجمن درکار ہے۔ انہیں ip xfrm state سے فہرست کریں، یا جب strongSwan گفت و شنید کرے تو swanctl --list-sas سے، اور ہر اندراج کے منتخب کنندگان اور شمار کنندگان پڑھیں۔

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

راستے پر مبنی سرنگ کو اب بھی کیا درکار ہے

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

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

کچھ بھی ترمیم کرنے سے پہلے ملکیت واضح کریں

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

ترتیب کی ملکیت طے کرتی ہے کہ آپ کی درستی دوبارہ آغاز کے بعد بچے گی یا نہیں۔ ایک جزو حالت نصب کر سکتا ہے جبکہ دوسرا راستے سنبھالتا ہے، اور دوسرے پر ہاتھ سے کی گئی ترمیم اگلی بار سرنگ اٹھنے پر مٹا دی جاتی ہے۔ مالک ترتیب بدلیں، پھر دونوں مناظر دوبارہ پڑھیں؛ RFC 4301 یہ تقسیم کسی اور کو سمجھانی پڑے تو دونوں ڈیٹا بیس الگ رکھتا ہے۔