IPsec ٹریفک سلیکٹرز: یہ کیا ڈھانپتے ہیں اور کیا نہیں
سلیکٹرز طے شدہ پالیسی ہیں، نہ راستہ اور نہ اجازت۔ انہیں دونوں سروں سے پڑھیں، دیکھیں کہ جواب دینے والا انہیں کیسے تنگ کرتا ہے، پھر ایک منزل کا پیچھا کریں۔
ٹریفک سلیکٹرز اس اندرونی ٹریفک کا نام دیتے ہیں جسے IPsec معاہدہ محفوظ رکھتا ہے، اور یہ جوڑی فرض نہیں کی جاتی بلکہ بات چیت سے طے ہوتی ہے۔ دونوں سرے ایک دوسرے کی مکمل تصدیق کر سکتے ہیں اور پھر بھی اس پر متفق نہ ہوں کہ کون سے پیکٹ سرنگ کے اندر آتے ہیں۔ یہ اختلاف کنکشن کی حالت میں نظر نہیں آتا، جو عام طور پر صحت مند سرنگ کی اطلاع دیتا ہے۔ سلیکٹرز کو دونوں سروں سے پڑھ کر پھر ایک منزل کا پیچھا کرنا اسے کسی بھی پالیسی ترمیم سے جلدی ڈھونڈ لیتا ہے۔
انہیں دونوں سروں سے پڑھیں
ہر سرہ اپنی طرف کو مقامی اور دوسری طرف کو دور کا بتاتا ہے۔ اس لیے وہی سابقہ جوڑی دونوں ترتیبوں میں الٹی نظر آتی ہے، اور یہ درست ہے، متضاد نہیں۔ کام کرتا معاہدہ کاغذ پر غلط دکھے تو سب سے پہلا کام زاویۂ نظر الٹنا ہے۔ دو فائلوں کو الٹے بغیر ساتھ ساتھ موازنہ کرنا ایسی بے ربطی پیدا کرتا ہے جو موجود ہی نہیں۔
اقدار ہمیشہ اکیلی ذیلی نیٹ نہیں ہوتیں۔ IKEv2 سلیکٹرز پتوں کی حدود، پروٹوکول نمبر اور پورٹ حدود لے جا سکتے ہیں، اور اسی طرح پالیسی پورے نیٹ ورک کے بجائے ایک سروس کی حفاظت کرتی ہے۔ مطلوبہ ٹریفک سے تنگ سلیکٹر ایسی سرنگ بناتا ہے جو کچھ منزلیں لے جاتا ہے اور باقی کو خاموشی سے خارج کر دیتا ہے۔
کچھ بھی بدلنے سے پہلے دونوں طرف ایک جدول میں لکھیں۔ یہ مشق عام طور پر ترتیب کی فائل کو چھوئے بغیر سوال حل کر دیتی ہے۔
تنگ کرنا جواب دینے والے کا فیصلہ ہے
آغاز کرنے والا تجویز دیتا ہے، اور جواب دینے والا صرف ذیلی مجموعہ قبول کر سکتا ہے۔ IKEv2 جواب دینے والے کو اجازت دیتا ہے کہ پیش کردہ ٹریفک سلیکٹرز تنگ کرے، اور تنگ شدہ نتیجہ ہی دراصل نصب ہوتا ہے۔ اس لیے آغاز کرنے والے کی ترتیب پڑھنا ایک تجویز بیان کرتا ہے، معاہدہ نہیں۔
اسی لیے کلائنٹ میں شامل ذیلی نیٹ کام کرتی سرنگ بنا کر بھی نئی منزل سے انکار کر سکتا ہے۔ سرور نے تجویز کو اپنی پالیسی کی اجازت تک تنگ کیا، جبکہ کلائنٹ کی فائل اب بھی وسیع حد درج کرتی ہے۔ صرف طے شدہ حالت سچ دکھاتی ہے: Linux پر ip xfrm policy اور strongSwan کی IKEv2 دستاویزات میں child SA فہرست مانگی ہوئی نہیں بلکہ نصب شدہ چیز بتاتی ہے۔ جب دونوں مختلف ہوں تو جواب دینے والے کی پالیسی بدلنی چاہیے۔
رد شدہ تجویز تنگ شدہ سے مختلف علامت ہے۔ رد ہونا بات چیت کے لاگ میں ظاہر ہوتا ہے اور کوئی child تعلق باقی نہیں چھوڑتا۔
ایک منزل کا شروع سے آخر تک پیچھا کریں
وہ حقیقی منزل اور ماخذ پتہ منتخب کریں جو کلائنٹ استعمال کرے گا، پھر اس جوڑی کو تین آزاد فیصلوں سے گزاریں۔ راستہ ایک راہ چنتا ہے، سلیکٹر فیصلہ کرتا ہے کہ وہ راہ محفوظ ہے یا نہیں، اور فائر وال فیصلہ کرتا ہے کہ پیکٹ کی اجازت ہے یا نہیں۔ ہر ایک خود گر سکتا ہے، اور وسیع سلیکٹر باقی میں سے کسی کو درست نہیں کرتا۔
ip route get 10.20.30.41
ip xfrm policy list
swanctl --list-sas
راستے کا سوال اس انٹرفیس اور ماخذ پتے کا نام لیتا ہے جو پیکٹ لے جائیں گے۔ پالیسی فہرست دکھاتی ہے کہ اس جوڑی کے لیے موافق سرنگ پالیسی موجود ہے یا نہیں، اس کی سمت اور سطح سمیت۔ SA فہرست طے شدہ child سلیکٹرز کاؤنٹرز کے ساتھ دکھاتی ہے، اس لیے ٹریفک آزمائے جانے کے بعد صفر پیکٹ والا child تعلق ان سلیکٹرز کی نشانی ہے جو بھیجے جانے والے کو خارج کرتے ہیں۔ تین حکم، تین مختلف جواب، اور ان میں سے صرف ایک خاموش گری کی وضاحت کرتا ہے۔
اگر ایپ اب بھی ناکام ہو اور child کاؤنٹرز حرکت کریں تو مسئلہ سرنگ کے پار ہے۔ یہ تحقیق کو سلیکٹرز کی طرف نہیں بلکہ دور کے میزبان کے سننے والے یا فائر وال کی طرف لے جاتا ہے۔
دونوں مقاصد الگ رکھیں
دفتری ذیلی نیٹ کی حفاظت اور تمام براؤزنگ دور کے اخراج سے بھیجنا مختلف سلیکٹرز والی مختلف ضروریات ہیں۔ ایک کے لیے بنایا گیا پروفائل دوسرے کے لیے کم ہی موزوں ہوتا ہے، اور دونوں کو ملانا یا تو رساؤ یا ٹوٹی تقسیم پیدا کرتا ہے۔ محفوظ حد کو وسیع کرنے کا مطلب دونوں سروں اور ان کی آگے بھیجنے کی پالیسی کو بدلنا ہے، کیونکہ یک طرفہ تبدیلی رد شدہ تجویز بن جاتی ہے۔ چھوٹی ترمیم کے بعد کام کرتی سرنگ کے کام کرنا چھوڑنے کا یہی سب سے عام طریقہ ہے۔
سلیکٹرز خفیہ کاری کی حد بیان کرتے ہیں، راستے راہیں چنتے ہیں، اور ایپ اپنی اجازتیں نافذ کرتی ہیں۔ سب کچھ ڈھانپنے والی سرنگ بھی loopback سے بندھی سروس تک نہیں پہنچ سکتی، اور سرنگ میں جانے والے راستے کو اب بھی منزل شامل کرنے والا سلیکٹر چاہیے۔ تینوں کو ایک ہی آزمائشی درخواست پر جانچیں، اور بے ربطی خود اپنا نام لے گی۔