AH یا ESP؟ فیصلہ اس بات سے کریں کہ پیکٹ کو کس چیز کی حفاظت کرنی ہے

دو IPsec تجاویز ایک ہی SHA پر مبنی سالمیت کا الگورتھم بتا کر بھی مختلف حفاظتی پروٹوکول مانگ سکتی ہیں؛ AH اور ESP ایک ہی تصدیقی ترتیب کی دو ہجے نہیں ہیں۔ پہلے پروٹوکول پڑھیں، پھر اس کے الگورتھم، پھر اس کا موڈ، اور زیادہ تر ابہام ختم ہو جاتا ہے۔ AH پیکٹ کی تصدیق کرتا ہے، ان IP ہیڈر میدانوں سمیت جو سفر میں بدلتے نہیں، جبکہ ESP اپنے احاطے میں آنے والی چیز کی تصدیق اور مخفی کاری کرتا ہے اور بیرونی ہیڈر کو چھیڑتا نہیں۔ یہی فرق کسی بھی ہیش نام سے زیادہ تعیناتیاں طے کرتا ہے۔

AH کیا ڈھانپتا ہے جو ESP نہیں

AH سالمیت، ڈیٹا کے ماخذ کی تصدیق اور اپنی متعین کردہ تکرار مخالف خدمت دیتا ہے، اور کوئی رازداری نہیں۔ اس کے دائرے میں بالائی تہہ کا ڈیٹا اور IP ہیڈر کے وہ میدان آتے ہیں جنہیں اس کے قواعد ناقابلِ تغیر سمجھتے ہیں، یعنی وہی حصہ جو ESP ٹرانسپورٹ موڈ میں باہر چھوڑ دیتا ہے۔ جب تقاضا کہے کہ خود IP ہیڈر کی تصدیق ہونی چاہیے، تو جواب دینے والا پروٹوکول AH ہے۔

یہی دائرہ AH کے عملی طور پر نازک ہونے کی وجہ ہے۔ TTL، ہیڈر کا چیک سم اور بعض اختیارات جیسے بدلنے والے میدان تصدیق نہیں ہو سکتے کیونکہ راؤٹر انہیں دوبارہ لکھ سکتے ہیں، اس لیے پروٹوکول چیک شمار کرنے سے پہلے انہیں صفر کر دیتا ہے۔ اس لیے پتے دوبارہ لکھنے والی ہر چیز صرف پالیسی نہیں، حساب بھی توڑ دیتی ہے۔

NAT انتخاب کو ایک پابندی بنا دیتا ہے

پتوں کا ترجمہ AH کے ابھی تصدیق کردہ IP ہیڈر میں ماخذ یا منزل دوبارہ لکھتا ہے، اس لیے سالمیت کی جانچ دوسرے سرے پر ناکام ہوتی ہے، اور یہ پڑھے جانے والے پیغام کے بجائے پروٹوکول کی غلطی کے طور پر ناکام ہوتی ہے۔ ESP بیرونی ہیڈر کی تصدیق نہیں کرتا، اسی لیے NAT سے گزرنے کے ساتھ ESP کام کرتا ہے اور NAT کے پیچھے AH نہیں۔ سرنگیں جس کے دونوں سرے عام راؤٹروں کے پیچھے ہوں وہی پہلی جگہ ہے جہاں یہ ظاہر ہوتا ہے۔ اس لیے پہلا سوال یہ نہیں کہ کون سا پروٹوکول مضبوط ہے، بلکہ یہ کہ دونوں سروں کے درمیان مترجم موجود ہے یا نہیں۔

اگر ہو تو AH باہر ہو جاتا ہے، اور بات ESP اور اس کے الگورتھم کے انتخاب پر آتی ہے۔ یہ ترجیح نہیں پابندی ہے، اس لیے اس کی جگہ فیصلے کے آخر میں نہیں، شروع میں ہے۔

موڈ سوال کو کئی گنا کر دیتا ہے

ESP ٹرانسپورٹ موڈ میں بالائی تہہ کا بوجھ بچاتا ہے اور IP ہیڈر کو نہیں چھیڑتا؛ سرنگ موڈ میں اندرونی IP ہیڈر سمیت پورا اندرونی پیکٹ لپیٹ کر اس کی حفاظت کرتا ہے۔ AH کے بھی وہی دو موڈ ہیں، اس لیے AH یا ESP دراصل کسی بھی الگورتھم کے انتخاب سے پہلے چار امتزاج ہیں۔

مشترکہ موڈ کے ESP الگورتھم پھر دوسرے پروٹوکول کے بغیر سالمیت طے کرتے ہیں۔ AES-GCM اور ChaCha20-Poly1305 ایک ہی ساخت میں تصدیق اور مخفی کاری کرتے ہیں، اس لیے اوپر AH شامل کرنا کچھ نہیں خریدتا مگر ایک اور ہیڈر اور ایک اور گفت و شنید خرچ کرتا ہے۔ معماری AH اور ESP کو ساتھ اجازت دیتی ہے، اور عملی سوال یہ ہے کہ کیا آپ کا گیٹ وے اور ورژن اس امتزاج کی حمایت کرتے ہیں اور کیا بعد میں کوئی اسے سنبھال سکے گا۔

صرف AH کے لیے ایماندار متبادل

صرف سالمیت والا ESP قسم الگورتھم رکھتا ہے اور مخفی کاری کے دعوے کو جعلی بنانے کے بجائے چھوڑ دیتا ہے، اور NAT سے گزر جاتا ہے۔ اگر پرانا ڈیزائن رازداری کے بغیر تصدیق کی ضرورت کی وجہ سے AH استعمال کرتا تھا، تو وہی قسم براہ راست ترجمہ ہے، نوٹ لگی مخفی سرنگ نہیں۔

تجاویز میں ESP دیکھنا بھی مخفی کاری کا ثبوت نہیں۔ مخفی کاری کا الگورتھم پڑھیں: NULL اندراج کا مطلب صرف سالمیت، اور مشترکہ موڈ اندراج کا مطلب دونوں۔

تین سوالوں میں فیصلہ کریں

پوچھیں کہ رازداری ضروری ہے یا نہیں، راستے میں مترجم ہے یا نہیں، اور کون سے ہیڈر میدان تصدیق ہونے چاہئیں۔ یہ تین جواب ایک پروٹوکول اور ایک موڈ کی طرف اشارہ کرتے ہیں، اور انہیں لکھنا بعد میں RFC دوبارہ پڑھنے سے کم وقت لیتا ہے۔

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

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