IPsec تجویز میں کیا شامل ہوتا ہے؟ IKE اور ESP فیلڈز
تجویز ایک مکمل پیشکش ہے، الگورتھم کی تھیلی نہیں۔ دیکھیں کون سی فیلڈز IKE کی ہیں اور کون سی ESP کی، اور ایک عدم مطابقت پورے سیٹ کو کیوں مسترد کرتی ہے۔
IKE شروع ہوتا ہے، دونوں فریق AES کا اعلان کرتے ہیں، اور سرنگ پھر بھی NO_PROPOSAL_CHOSEN کے ساتھ ناکام ہوتی ہے۔ لاگ تجویز کا نام بتاتا ہے مگر وہ فیلڈ نہیں جو میل نہیں کھائی۔ تجویز ایک مکمل پیشکش ہے، اور ایک غیر موافق فیلڈ پوری ترکیب کو باطل کر دیتی ہے، صرف اس سطر کو نہیں۔ اسے آزاد الگورتھم انتخابات کی تھیلی کے طور پر پڑھنا ہی وہ عام وجہ ہے جس سے عدم مطابقت پوشیدہ رہتی ہے۔
الگ تجاویز فہرستوں والی دو بات چیت
IKEv2 دو سلامتی انجمنیں بناتا ہے۔ پہلی IKE SA ہے، جو کنٹرول تبادلے کی خود حفاظت کرتی ہے، اور دوسری CHILD SA ہے، جو آپ کا ٹریفک ESP کے ذریعے لے جاتی ہے۔ ہر ایک کی اپنی تجاویز فہرست ہے، اور فریق ایک کو قبول اور دوسری کو مسترد کر سکتا ہے۔
یہ تقسیم ایک عام الجھن کی وضاحت کرتی ہے: کام کرنے والی IKE SA صرف یہ ثابت کرتی ہے کہ کنٹرول چینل کے الگورتھم میل کھائے۔ اگر CHILD تجویز ناکام ہو، تو سرنگ ایک بھی پیکٹ نہیں لے جاتی، چاہے پہلا مرحلہ مکمل ہو اور لاگ اوپر سے صحت مند دکھائی دیں۔
ہر فہرست کے اندر ترتیب بھی اہم ہے۔ جواب دینے والا آغاز کرنے والے کی ترتیب شدہ پیشکشوں میں سے چنتا ہے، اس لیے کسی وسیع طور پر موافق اندراج کو تنگ اندراج سے اوپر منتقل کرنا یہ بدلتا ہے کہ کون سا سیٹ نصب ہوگا، جبکہ کسی الگورتھم کا نام تبدیل نہیں ہوتا۔ ڈیفالٹ پر انحصار کرنے کے بجائے اس ترتیب کو ترتیب میں محفوظ کریں۔ مستحکم ترتیب سائٹس کے درمیان لاگ موازنہ کو بھی بامعنی بناتی ہے۔
کون سی فیلڈز کس تجویز کی ہیں
فیلڈز کا مجموعہ چھوٹا ہے، مگر دونوں بات چیتوں میں یکساں نہیں۔ جدول سطر بسطر پڑھیں، کیونکہ ایک کالم کی فیلڈ دوسرے میں نہیں ہو سکتی۔ نحو عمل درآمد کے مطابق مختلف ہوتی ہے؛ strongSwan کی تجاویز کی دستاویزات ایک ٹھوس حوالہ ہیں۔
| Field | IKE SA proposal | CHILD SA proposal |
|---|---|---|
| Encryption | Required | Required |
| Integrity | Required unless AEAD | Required unless AEAD |
| PRF | Required | Not present |
| DH group | Required | Only for PFS |
| ESN | Not present | Optional |
انکرپشن فیلڈ سائفر اور بیشتر نحوی ڈھانچوں میں اس کی کلید کی لمبائی بتاتی ہے۔ سالمیت کی فیلڈ وہ ہیش بتاتی ہے جو مخفی متن کی تصدیق کے لیے استعمال ہوتا ہے، اور PRF وہ فعل بتاتا ہے جو IKE SA کے لیے کلیدی مواد نکالتا ہے۔ DH گروپ تازہ مشترکہ خفیہ مواد قائم کرتا ہے، اسی لیے یہ دونوں طرف نظر آتا ہے مگر مختلف مقاصد کے لیے۔
توسیع شدہ ترتیبی نمبر صرف ڈیٹا راستے کے ہیں۔ وہ ترتیب کی وسعت بڑھاتے ہیں اور CHILD تجویز کے حصے کے طور پر طے ہوتے ہیں، اس لیے وہاں کی عدم مطابقت CHILD پیشکش مسترد کرتی ہے جبکہ IKE SA اچھوتا رہتا ہے۔
ایک مکمل پیشکش کیسے منتخب ہوتی ہے
ہر تجویز ایک مجموعہ ہے، اور جواب دینے والا ایسا مجموعہ تلاش کرتا ہے جس میں ہر لازمی فیلڈ قابل قبول ہو۔ دونوں فہرستوں میں AES اور SHA-256 ہو سکتے ہیں اور پھر بھی کوئی موافق اندراج نہ ہو، کیونکہ کلید کی لمبائی، PRF یا DH گروپ مختلف ہیں۔ موازنہ ہر الگورتھم کے بجائے ہر تجویز پر ہوتا ہے۔
جب کچھ بھی میل نہ کھائے، جواب دینے والا ناکام SA قسم کے ساتھ NO_PROPOSAL_CHOSEN بھیجتا ہے۔ ترتیب تبدیل کرنے سے پہلے پڑھیں کہ اطلاع کس تجاویز فہرست سے متعلق ہے؛ IKE تجویز مسترد ہونے پر ESP الگورتھم بدلنا ڈیبگنگ کا ایک دور ضائع کرتا ہے۔
پروفائل ٹیون کرتے وقت انتخاب کا رویہ جاننا مفید ہے۔ کچھ عمل درآمد آغاز کرنے والے کی ترتیب کو ترجیح دیتے ہیں، دیگر مقامی پالیسی کے مطابق دوبارہ ترتیب دیتے ہیں، اس لیے دو فروشندگان کے درمیان کام کرنے والا سیٹ غائب ہو سکتا ہے جب آپ یہ الٹ دیں کہ کون سا فریق کنکشن شروع کرتا ہے۔
AEAD فیلڈ شامل کرنے کے بجائے ہٹاتا ہے
AES-GCM اور ChaCha20-Poly1305 ایک ہی عمل میں تصدیق اور انکرپشن کرتے ہیں۔ جب ان میں سے کوئی ESP کے لیے منتخب ہو، تو سالمیت کا الگورتھم الگ سے طے نہیں ہوتا، کیونکہ AEAD ساخت اسے پہلے ہی ڈھانپ لیتی ہے۔ اس لیے AES-GCM کو SHA-256 کے ساتھ جوڑنے والی تجویز بہترین حالت میں ضرورت سے زائد اور بدترین حالت میں مسترد ہوتی ہے۔
PRF IKE جانب اب بھی الگ ہے، کیونکہ وہ پے لوڈ کے تحفظ کے بجائے کنٹرول چینل کے لیے کلیدیں نکالتا ہے۔ اسی لیے IKE تجویز قانونی طور پر AEAD سائفر کو PRF اور DH گروپ کے ساتھ جوڑ سکتی ہے، جبکہ متعلقہ ESP تجویز صرف AEAD سائفر اور اختیاری PFS گروپ درج کرتی ہے۔
کلید کی لمبائی انکرپشن ٹوکن کا حصہ ہے، اس لیے AES-128-GCM اور AES-256-GCM مختلف پیشکشیں ہیں۔ 256-bit کلیدیں فرض کرنے والی گائیڈ سے نقل شدہ پروفائل 128-bit کے لیے ترتیب دیے گئے اینڈ پوائنٹ سے میل نہیں کھائے گا، چاہے دونوں سطریں AES-GCM کہیں۔ دو فریق سائفر خاندان پر متفق ہو سکتے ہیں اور پھر بھی ڈیش کے بعد کی تعداد کی وجہ سے ایک دوسرے کو مسترد کر سکتے ہیں۔
ترتیب نہیں، نصب شدہ SA پڑھیں
ترتیب شدہ تجاویز فہرست ایک پیشکش ہے؛ نصب شدہ SA نتیجہ ہے۔ strongSwan اور Linux کرنل پر دونوں منظر دستیاب ہیں:
sudo swanctl --list-sas
sudo ip xfrm state
sudo ip xfrm policyswanctl --list-sas ہر SA کے لیے طے شدہ الگورتھم چھاپتا ہے، بشمول یہ کہ CHILD AEAD استعمال کرتا ہے یا نہیں۔ ip xfrm state دکھاتا ہے کہ کرنل نے واقعی کیا نصب کیا ، اور یہیں تصدیق ہوتی ہے کہ کلید کی تجدید آپ کے دستاویزی سیٹ سے مختلف سیٹ پر واپس نہیں گئی۔
اصلاح کے بعد وہ آؤٹ پٹ ترتیب کے ساتھ محفوظ رکھیں۔ جب کلائنٹ اپ ڈیٹ اپنے ڈیفالٹ بدلتا ہے، تو محفوظ شدہ سیٹ آپ کو موازنہ کے لیے بنیادی خط دیتا ہے، اور موازنہ تحقیق کو شروع سے دوبارہ شروع کرنے کے بجائے ہلنے والی فیلڈ کی طرف اشارہ کرتا ہے۔