بغیر جواب کے باہر جانے والا ESP اس بات کا مطلب نہیں کہ VPN مر گیا ہے
ESP ہر ایسوسی ایشن کے لیے ایک سمت کی حفاظت کرتا ہے اور کچھ تصدیق نہیں کرتا۔ سرور کو بے جواب کہنے سے پہلے اندرونی گفتگو اور آنے والی SA کو ملا کر دیکھیں۔
آپ نے IPsec ہوسٹ پر ٹریفک پکڑی، ESP پیکٹ باہر جاتے دیکھے، واپس کچھ آتا نہیں دیکھا، اور یہ نتیجہ نکالا کہ دور والا سرا خراب ہے۔ یہ گرفت اس نتیجے کی تائید نہیں کرتی۔ ESP گفتگو کی ایک سمت کی حفاظت کرتا ہے اور IP سطح پر کچھ تصدیق نہیں کرتا، اس لیے واپسی والا ESP نہ ہونا اتنا ہی آسانی سے یہ معنی رکھ سکتا ہے کہ ایپلیکیشن کے پاس کہنے کو کچھ نہیں تھا، جتنا کہ یہ کہ سرنگ مر گئی ہے۔ کسی بھی سرے کو قصوروار ٹھہرانے سے پہلے اندرونی تبادلہ اور وصول کرنے والے سرے کی حالت پڑھیں۔
افسانہ: ہر محفوظ پیکٹ کو جواب ملتا ہے
ESP درخواست اور جواب کا پروٹوکول نہیں ہے۔ یہ وہ سب کچھ خفیہ اور تصدیق شدہ کرتا ہے جو پالیسی منتخب کرتی ہے، اور وصول کرنے والا اس اندرونی پیکٹ کو خود پیکٹ بنائے بغیر تصدیق، ڈکرپٹ اور پہنچاتا ہے۔ وہ UDP استفسار جسے منزل نظر انداز کرتی ہے، یا وہ ICMP گونج جسے آنے والی پالیسی رد کرتی ہے، دونوں سمتوں میں خاموشی کو درست نتیجہ بنا کر پیدا کرتی ہے۔ اس خاموشی کو نقل و حمل کی خرابی سمجھنا آپ کو ایسی نیٹ ورک خرابی تلاش کرنے بھیجتا ہے جو کبھی تھی ہی نہیں۔
یک طرفہ گرفت دراصل یہ ثابت کرتی ہے کہ بھیجنے والے کے اسٹیک نے اس مشاہداتی نقطے پر کچھ خفیہ کیا۔ آمد کے بارے میں کچھ نہیں، اور جواب دینے کے ارادے کے بارے میں بھی کچھ نہیں۔ مفید سوال „جواب کیوں نہیں“ نہیں بلکہ „اندرونی گفتگو نے کیا پیدا کرنا چاہیے تھا“ ہے۔
دو SA، دو SPI، ایک گفتگو
IPsec سیکیورٹی ایسوسی ایشنز یک طرفہ ہوتی ہیں، اس لیے عام محفوظ تبادلہ الگ شناختوں اور خودمختار حالت کے ساتھ آنے والی ایسوسی ایشن اور جانے والی ایسوسی ایشن چلاتا ہے۔ جانے والے پیکٹ کے SPI کے لیے واپسی کی ٹریفک ڈھونڈنا اس لیے ایک قسم کی غلطی ہے، کیونکہ کوئی بھی جواب ساتھی کی اپنی جانے والی SA کے تحت اپنے SPI کے ساتھ سفر کرتا ہے۔ اس کے بجائے جوڑی کو ٹریفک منتخب کنندگان اور ساتھی کے پتوں سے ملائیں۔
کلید کی تجدید چند سیکنڈ کے لیے تصویر کو پیچیدہ کرتی ہے، کیونکہ پرانی اور متبادل حالت ایک دوسرے پر آ سکتی ہے۔ اگر علامت کلید کی تبدیلی کے آس پاس شروع ہوئی، تو صرف کنکشن کا نام نہیں بلکہ ایسوسی ایشن شناختیں اور وقت کے نشانات اکٹھے جمع کریں۔
کچھ بھی جواب دینے سے پہلے وصول کرنے والے کو کیا کرنا ہے
| Stage | What to look at | Wrong conclusion if skipped |
|---|---|---|
| Sender encrypts | outbound SA packet counter | "the tunnel is up" |
| Peer receives | inbound SA counter and replay window | "the peer is down" |
| Inner delivery | target host or service logs | "routing is broken" |
| Application replies | the app's own trace | "the reply was dropped" |
| Protected return | the peer's outbound SA | "ESP only works one way" |
ہر قطار الگ طور پر ناکام ہوتی ہے اور ہر خرابی کا الگ مالک ہوتا ہے، اسی لیے ایک گرفت ان کو الگ نہیں کر سکتی۔ آنے والا شمار کنندہ آمد کا واحد براہ راست ثبوت ہے، کیونکہ تصدیق یا تکرار کی جانچ میں ناکام پیکٹ کسی جواب کے بغیر رد کر دیا جاتا ہے۔ اس لیے جس ساتھی کا آنے والا شمار کنندہ نہیں ہلا، وہ آپ کو اپنی پالیسی کے بارے میں کوئی معلومات نہیں دیتا۔
پہنچانا ڈکرپشن سے الگ مرحلہ ہے۔ حالت درست ہو سکتی ہے اور پیکٹ پھر بھی بعد میں آنے والی پالیسی یا ایسے راستے سے رد ہو سکتا ہے جو اندرونی منزل شامل نہ ہو، اس لیے یہ فرض کرنے کے بجائے کہ صاف شمار کنندہ کا مطلب ہے پیکٹ آپ کی مطلوبہ جگہ گیا، یہ دیکھیں کہ ہدف ہوسٹ نے سادہ متن دیکھا یا نہیں۔
مقامی ESP UDP نہیں ہے
مقامی ESP IP پروٹوکول 50 ہے، جو نہ TCP ہے نہ UDP اور اس کے کوئی پورٹ نہیں۔ اس لیے UDP 500 پر IKE کی اجازت دینے والا فائر وال قاعدہ ڈیٹا راستے کے بارے میں کچھ نہیں کہتا، اور پورٹوں کے گرد لکھا فلٹر سرنگ کو بات چیت کرنے دے کر پھر اس میں لے جانے والی ہر چیز رد کر سکتا ہے۔ ڈیٹا راستے کو الگ سے، اسی موڈ میں جانچیں جو آپ نے واقعی دیکھا۔
NAT کے پیچھے شکل بدل جاتی ہے: محفوظ پے لوڈ UDP کے اندر سفر کرتا ہے، عام طور پر پورٹ 4500 پر، جیسا کہ RFC 3948 بیان کرتا ہے۔ کوئی بھی قاعدہ لکھنے سے پہلے فعال موڈ درج کریں، کیونکہ راستے کا آلہ مقامی ESP اور UDP میں لپٹے ESP کے ساتھ بالکل مختلف برتاؤ کر سکتا ہے، اور کچھ درمیانی ڈبے ایک کی اجازت دے کر دوسرا رد کر دیتے ہیں۔
اس واقعے سے متعلق شمار کنندگان پڑھیں
strongSwan ہوسٹ پر swanctl --list-sas دونوں سمتوں میں ہر ایسوسی ایشن کے پیکٹ اور بائٹ شمار کنندگان بتاتا ہے، جو „کبھی نہیں آیا“ کو „آیا مگر جواب نہیں دیا“ سے الگ کرنے کے لیے کافی ہے۔ Linux پر /proc/net/xfrm_stat غائب حالت، غائب پالیسی اور پروٹوکول کی غلطیوں جیسی مجموعی ناکامیوں کو گنتا ہے۔ وہ مجموعے بوٹ سے جمع ہوتے ہیں اور ایک نیٹ ورک نام کی جگہ سے تعلق رکھتے ہیں، اس لیے بڑا عدد کوئی الزام نہیں۔
درست نام کی جگہ میں واقعے کی کھڑکی کے گرد دو پڑھائیاں لیں اور فرق کا موازنہ کریں، ورنہ پچھلے ہفتے کی غلطیاں آج دوپہر کے ٹکٹ پر لگا دیں گے۔ نام کی جگہ اور دونوں وقت کے نشانات ٹکٹ میں لکھیں تاکہ اگلا پڑھنے والا مجموعے پر بھروسا کرنے کے بجائے موازنہ دوبارہ بنا سکے۔
مرحلے کا نام دیں، مشکوک کا نہیں
مفید نتیجہ بتاتا ہے کہ پیکٹ کہاں رکا: کبھی نہیں ملا، ملا اور رد ہو گیا، پہنچا مگر جواب نہیں، یا جواب دیا گیا اور واپسی کے راستے میں کھو گیا۔ ان میں سے ہر ایک الگ مالک اور الگ اگلے حکم کی طرف اشارہ کرتا ہے۔ „VPN سرور سے کوئی جواب نہیں“ چار الگ خرابیوں کو ایک ایسے جملے میں سمیٹ دیتا ہے جسے گرفت نے کبھی جائز نہیں ٹھہرایا۔
گرفت کو تنگ رکھیں، اور کرنل کی خام حالت ٹکٹوں سے باہر رکھیں، کیونکہ اس میں کلید کا مواد ہو سکتا ہے جو ہوسٹ سے باہر نہیں جانا چاہیے۔ شمار کنندگان کے فرق اور وقت کے نشانات ہی وہ حصے ہیں جو اگلے شخص کو دینے کے قابل ہیں۔