IPsec ESP: یہ کیا لے جاتا ہے اور یہ بہہ رہا ہے یہ کیسے ثابت کریں
ESP ٹنل موڈ میں اندرونی IP پیکٹ لپیٹتا ہے اور SPI کے ذریعے اپنی ایسوسی ایشن پہچانتا ہے۔ حالت پڑھیں، پھر دیکھیں کہ ایک بہاؤ کاؤنٹر کیسے ہلاتا ہے۔
ESP IPsec VPN میں ٹریفک لے جاتا ہے، اور اس کا runbook ایک اصول سے شروع ہوتا ہے: پالیسی بدلنے سے پہلے سیکیورٹی ایسوسی ایشن پڑھیں۔ ESP کا زیادہ تر غیر واضح رویہ ایسے سلیکٹر کی طرف جاتا ہے جو میل نہیں کھاتا تھا، ایسے موڈ کی طرف جو پڑھنے کے بجائے فرض کر لیا گیا، یا ایسے کاؤنٹر کی طرف جسے ایک بہاؤ بھیجتے وقت کسی نے نہیں دیکھا۔ نیچے کے تین مراحل طے کرتے ہیں کہ کیا کیا لے جاتا ہے، ثابت کرتے ہیں کہ ایک بہاؤ اسے استعمال کرتا ہے، اور ایسی واپسی چھوڑتے ہیں جو یادداشت پر منحصر نہیں۔ ہر مرحلہ ایک ایسا مشاہدہ دیتا ہے جو لکھنے کے قابل ہو۔
پڑھنے سے پہلے خانے جانیں
ESP محفوظ ڈیٹا کے آگے ہیڈر اور پیچھے ٹریلر رکھتا ہے۔ ہیڈر ایک سیکیورٹی پیرامیٹر انڈیکس لے جاتا ہے جو طے کرتا ہے کہ وصول کنندہ کون سی ایسوسی ایشن استعمال کرے، دہرائو پکڑنے کے لیے ترتیب نمبر، اور ٹریلر میں پیڈنگ جو پے لوڈ کو سائفر کے لیے سیدھا رکھتی ہے۔ ٹریلر میں اگلے ہیڈر کا خانہ بتاتا ہے کہ محفوظ مواد کیا ہے، اور اسی طرح وصول کنندہ جانتا ہے کہ اس نے کیا ڈی کپسولیٹ کیا۔
موڈ بدلتا ہے کہ اس حفاظت کے اندر کیا بیٹھتا ہے۔ ٹنل موڈ میں محفوظ مواد مکمل اندرونی IP پیکٹ ہوتا ہے، اور نیا بیرونی ہیڈر اسے دو سروں کے درمیان لے جاتا ہے۔ ٹرانسپورٹ موڈ میں حفاظت موجودہ پیکٹ کی اوپری پرت کے پے لوڈ کو لپیٹتی ہے، اس لیے کھولنے کے لیے دوسرا IP ہیڈر نہیں ہوتا۔ کون سا موڈ استعمال ہو رہا ہے یہ کنفیگریشن کی حقیقت ہے، تفسیر کا معاملہ نہیں۔ اسے خاکے سے اندازہ لگانے کے بجائے حالت کے اندراج سے پڑھیں۔
دونوں میں سے کوئی موڈ بیرونی پتہ نہیں چھپاتا جو پیکٹ کو پہنچانا ہے۔ یہ ڈیزائن کی خصوصیت ہے، کمی نہیں، اور اسی لیے درمیانی مبصر پے لوڈ مبہم ہونے پر بھی دیکھ سکتا ہے کہ کون سے دو پتے بات کر رہے ہیں۔
پہلا مرحلہ: حالت پڑھیں، پھر پالیسی
حالت کے اندراجات چابیاں اور کاؤنٹر رکھتے ہیں؛ پالیسی کے اندراجات وہ سلیکٹر رکھتے ہیں جو طے کرتے ہیں کہ کسے انہیں استعمال کرنے کی اجازت ہے۔ Linux میں دونوں پیکٹ کیپچر کے بغیر نظر آتے ہیں، اور اسی ترتیب سے پڑھنا دونوں سوالوں کو الگ رکھتا ہے۔
ip xfrm state
ip xfrm policyحالت کے اخراج میں ایسوسی ایشن کا ماخذ اور منزل، موڈ، اور یہ کہ انکیپسولیشن UDP پورٹ دکھاتا ہے یا نہیں، جانچیں۔ وہ پورٹ بتاتے ہیں کہ NAT ٹراورسل استعمال ہو رہا ہے، جو بدلتا ہے کہ درمیانی فائر وال کو کیا اجازت دینی ہے، مگر یہ نہیں کہ سروں پر کون سے سلیکٹر یا چابیاں لاگو ہوتی ہیں۔
پھر پالیسی کے سلیکٹر پڑھیں۔ جو سلیکٹر آپ کے جانچے جانے والے ٹریفک سے تنگ تر پریفکس بتاتا ہے، وہی سب سے عام سبب ہے کہ کام کرتا ٹنل کسی بہاؤ کو نظر انداز کرتا دکھتا ہے، اور غلط پروٹوکول کا سلیکٹر وہی خاموشی دیتا ہے۔
| Field | Where it appears | What it decides |
|---|---|---|
| Security parameter index | ESP header, and the receiving state entry | Which association and keys the receiver applies |
| Sequence number | ESP header | Replay detection for that association |
| Next header | ESP trailer | What the decapsulated payload contains |
| Inner IP header | Inside tunnel-mode payload only | The original source and destination the endpoints act on |
| Traffic selectors | Policy, not the packet | Which local traffic is allowed to use the association |
فروشندگان کے اوزار وہی معلومات زیادہ آسان شکل میں چھاپتے ہیں۔ ipsec statusall strongSwan پر یہ چائلڈ ایسوسی ایشن، ان کے سلیکٹر اور بائٹ کاؤنٹر کی فہرست دیتا ہے، جو کہ کون سی چائلڈ دیکھنی ہے یہ پہلے سے معلوم ہونے پر خام xfrm اخراج پڑھنے سے اکثر تیز ہوتا ہے۔
دوسرا مرحلہ: ثابت کریں کہ ایک بہاؤ کاؤنٹر ہلاتا ہے
کاؤنٹر تبھی معنی خیز ہوتے ہیں جب آپ جانتے ہوں کہ انہیں کس نے ہلانا چاہیے تھا، اس لیے ایسا ماخذ اور منزل چنیں جسے سلیکٹر یقینی طور پر ڈھکتا ہو اور ایک بے ضرر درخواست بھیجیں۔ پھر وہی اندراج دوبارہ پڑھیں اور موازنہ کریں۔
ip -s xfrm state
tcpdump -ni any espدو پڑھائیاں الگ کہانیاں کہتی ہیں۔ جو پیکٹ باہر کی طرف بڑھتے ہیں مگر اندر کی طرف کبھی نہیں، وہ چابی کے مسئلے کے بجائے فارورڈنگ یا واپسی راستے کے مسئلے کی طرف اشارہ کرتے ہیں، کیونکہ پیکٹ انکیپسولیٹ ہو کر چلا گیا۔ اگر کوئی کاؤنٹر نہ ہلے تو ٹریفک پالیسی سے کبھی میل نہیں کھایا، اور سلیکٹر ہی دیکھنے کی جگہ ہے۔
اسی مرحلے کی گرفت تار پر انکیپسولیشن کی تصدیق کرتی ہے، بشمول یہ کہ بیرونی پیکٹ ESP ہیں یا UDP میں انکیپسولیٹ شدہ ESP۔ یہ آپ کو وہ پتے بھی دکھاتی ہے جنہوں نے بہاؤ کو واقعی لے جایا، اور وہ کبھی کبھی اس کنفیگریشن سے مختلف ہوتے ہیں جو آپ پڑھ رہے تھے۔
تیسرا مرحلہ: ایک چیز بدلیں اور واپسی رکھیں
کچھ بھی ترمیم کرنے سے پہلے ایسوسی ایشن کا ماخذ، منزل، موڈ، سلیکٹر اور کاؤنٹر لکھ لیں۔ اگر کوئی تبدیلی حالت بگاڑ دے، تو وہی ریکارڈ آپ کو پچھلی حالت بحال کرنے دیتا ہے، اندازے سے چلنے والی کنفیگریشن دوبارہ بنانے کے بجائے۔ وہ ریکارڈ لکھنے میں ایک منٹ لیتا ہے اور بعد میں ایک گھنٹہ بچاتا ہے۔ یہ وہی واحد نشانی بھی ہے جو تبدیلی کرنے والے شخص کے بعد بچتی ہے۔
ایک سلیکٹر یا ایک پیرامیٹر بدلیں، اسے دوبارہ لوڈ کریں، اور اسی بہاؤ پر دوسرا مرحلہ دہرائیں۔ ایسوسی ایشن حذف کرنے سے اسے استعمال کرنے والا ہر بہاؤ ٹوٹ جاتا ہے، اس لیے ہدف شدہ ترمیم اور چائلڈ کو دوبارہ لوڈ کرنا کیا ہوتا ہے یہ دیکھنے کے لیے حالت خالی کرنے سے تقریباً ہمیشہ بہتر ہے۔
سلیکٹر ترمیم کی واپسی کا مطلب پچھلی پالیسی بحال کر کے دوبارہ لوڈ کرنا ہے، اس شرط کے ساتھ کہ اگر سلیکٹر مقامی نہ ہو بلکہ گفت و شنید سے طے ہو تو سامنے والے فریق کو مطابق تبدیلی درکار ہو سکتی ہے۔ وہ انحصار تازہ رہتے ہی لکھیں، کیونکہ آدھی بحال شدہ جوڑی دونوں آخری حالتوں میں سے کسی سے بھی سوچنا مشکل ہے۔
آخر میں، دائرہ ایمانداری سے رکھیں۔ بہتا ہوا ESP ایسوسی ایشن ثابت کرتا ہے کہ دو گیٹ وے حصے کی حفاظت کر کے اسے پہنچا رہے ہیں، اور یہ نہیں بتاتا کہ اوپر کی ایپلیکیشن اپنے صارفین کی تصدیق کرتی ہے یا جو محفوظ کرتی ہے اسے خفیہ کرتی ہے۔ یہ الگ ثبوتوں والے الگ کنٹرول ہیں، اور runbook تبھی مکمل ہوتا ہے جب اگلا شخص نوٹوں سے اسے دہرا سکے۔