IPsec کے اندر IPsec: بیرونی ٹنل کو کون سے پتے لے جانے چاہئیں

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

چار گیٹ ویز کا ماڈل

بیرونی گیٹ ویز A اور B دو سائٹس کے درمیان پہلی ٹنل بناتے ہیں۔ A کے پیچھے ٹرانزٹ پتے 10.60.0.2 کے ساتھ اندرونی گیٹ وے C، اور B کے پیچھے ٹرانزٹ پتے 10.70.0.2 کے ساتھ اندرونی گیٹ وے D ہے۔ ایپلیکیشن نیٹ ورک C اور D کے پیچھے رہتے ہیں، اور مثال میں ہر پتہ جان بوجھ کر ایک دوسرے پر نہیں چڑھتا۔

application net -> C -> A == outer IPsec == B -> D -> application net
                       \---------- inner IPsec ----------/

C transit: 10.60.0.2      D transit: 10.70.0.2
A and B:    underlay addresses only

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

ہر تہہ صرف اپنی حفاظت ہٹاتی ہے

C، D کے لیے ایک ایپلیکیشن پیکٹ مرموز کرتا ہے۔ نتیجہ C سے D تک پتہ شدہ ہوتا ہے، اور وہی A تک پہنچتا ہے۔ اس کے بعد سب کچھ اسی دوبارہ تحریر پر منحصر ہے۔

A اسے B کے لیے دوبارہ مرموز کرتا ہے۔ B بیرونی تہہ کو کھولتا ہے، C سے D جانے والا پیکٹ دیکھتا ہے اور اسے اب بھی مرموز حالت میں آگے بھیجتا ہے۔ D اندرونی حفاظت ہٹا کر ایپلیکیشن پیکٹ پہنچاتا ہے۔

لہٰذا A اور B اندرونی سرے اور ان کا میٹا ڈیٹا دیکھتے ہیں، مگر ایپلیکیشن پے لوڈ کو کھولنے والے فریق وہ نہیں۔ یہ ڈیزائن کی حقیقی خصوصیت ہے، C، D یا ایپلیکیشن ہوسٹوں کے قابل اعتماد ہونے کا دعویٰ نہیں۔

بیرونی سلیکٹرز اندرونی گیٹ ویز کے نام لیتے ہیں

یہیں اس طرح کی بیشتر تعمیریں ناکام ہوتی ہیں۔ پالیسی پر مبنی بیرونی ٹنل کے لیے، جو سلیکٹر آپ طے کرتے ہیں ان میں وہ پتے ہونے چاہئیں جو A اور B واقعی سنبھالتے ہیں: 10.60.0.2/32 اور 10.70.0.2/32، درست مقامی اور دور ترتیب میں۔

حتمی ایپلیکیشن سب نیٹ بیرونی سلیکٹرز میں رکھنا کام نہیں کرتا، کیونکہ جب پیکٹ A تک پہنچتا ہے تو اندرونی encapsulation وہ چیز پہلے ہی دوبارہ لکھ چکا ہوتا ہے جو A کو محفوظ رکھنی ہے۔ تب بیرونی پالیسی کسی سے نہیں ملے گی، اور ٹنل بغیر ڈیٹا لیے اوپر آ جائے گی۔

بیرونی اجازت کو UDP 500 تک محدود نہ کریں۔ اندرونی کنکشن کا اپنا ڈیٹا راستہ ہے، جو طے شدہ بات کے مطابق ESP یا UDP encapsulation استعمال کرتا ہے، اور بیرونی پالیسی کو وہ پروٹوکول اجازت دینی چاہیے۔

ہر گیٹ وے پر swanctl --list-sas سے نتیجہ جانچیں اور تصدیق کریں کہ چائلڈ سیکیورٹی ایسوسی ایشنز وہ پتے رپورٹ کرتی ہیں جو آپ نے ارادہ کیا، نہ کہ جو آپ نے فرض کیے۔ اگر فہرست ایپلیکیشن سب نیٹ دکھائے، تو بیرونی پالیسی غلط تہہ کے لیے لکھی گئی ہے۔ روٹنگ ڈیبگ کرنے سے پہلے سلیکٹرز درست کریں، کیونکہ روٹنگ ٹھیک دکھے گی اور کاؤنٹر نہیں ہلیں گے۔

فارورڈنگ اور تکرار کا جال

سلیکٹرز روٹنگ کی جگہ نہیں لیتے۔ A اور B کو C اور D کے درمیان دونوں سمتوں میں ٹریفک فارورڈ کرنا ہوگا، یعنی IP فارورڈنگ فعال، ٹنل کی طرف اشارہ کرنے والے راستے اور دوسری طرف موجود واپسی راستہ۔

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

جال تکرار ہے۔ A کا B کے بیرونی سرے تک راستہ A کی تعمیر کردہ ٹنل کے بجائے نچلے نیٹ ورک کی پیروی کرے، ورنہ encapsulation اپنے اندر سفر کرنے کی کوشش کرتا ہے اور کنکشن کبھی مکمل نہیں ہوتا۔

تہیں شامل کرنے سے پہلے ترجمہ دیکھیں

کوئی اور چیز ٹیون کرنے سے پہلے A اور B پر کوئی بھی سورس NAT دیکھیں۔ IPsec پالیسی لاگو ہونے سے پہلے C کا پتہ دوبارہ لکھنے والا اصول طے شدہ سلیکٹرز توڑ سکتا ہے، اور یہ بھی بدل سکتا ہے کہ D دوسری طرف کیا وصول کرتا ہے۔

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

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

fail-closed ثابت کریں اور MTU جانچیں

راستے کا غائب ہونا بذات خود fail-closed پالیسی نہیں ہے۔ کوئی دوسرا ٹیبل، ڈیفالٹ راستہ یا پالیسی اصول خاموشی سے متبادل دے سکتا ہے، اور جاننے کا واحد طریقہ بیرونی ٹنل نیچے کر کے دیکھنا ہے کہ ایپلیکیشن ٹریفک کیا کرتی ہے۔ اسے اتفاقاً دریافت کرنے کے بجائے مینٹیننس ونڈو میں جان بوجھ کر کریں۔

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

دونوں encapsulations کے لیے بجٹ رکھیں۔ چلتی IKE چھوٹے پیکٹوں کا نتیجہ ہے، اور دو ہیڈر شامل ہونے کے بعد پورے سائز کے ایپلیکیشن پیکٹ پھر بھی ناکام ہو سکتے ہیں؛ اعداد کے جمع ہونے کا فرض کرنے کے بجائے اصل راستے پر معلوم پے لوڈ سائز کے ساتھ جانچیں۔ حساب آسان ہے، راستہ نہیں۔