AWS Site-to-Site VPN میں MODP3072 کہاں آتا ہے
MODP3072 IANA کا گروپ 15 ہے، لیکن یہ گروپ ایک مرحلے سے تعلق رکھتا ہے۔ ٹنل میں ترمیم کرنے سے پہلے ضرورت کو Phase 1 یا Phase 2 کی DH فہرستوں سے جوڑیں۔
کوئی آپ کو ایسی ضرورت بھیجتا ہے جس میں IKEv2، ESP اور MODP3072 لکھا ہوتا ہے، اور کنسول میں اس نام کا کوئی فیلڈ نہیں ہوتا۔ غلطی یہ ہے کہ ایسا فیلڈ تلاش کرنے لگیں۔ IKEv2 مذاکرات کا نسخہ ہے، ESP وہ پروٹوکول ہے جو آپ کی محفوظ ٹریفک لے کر چلتا ہے، اور MODP3072 کلید کی تبدیلی کا گروپ ہے، یعنی IANA کا گروپ 15۔ یہ تین حقائق تین مختلف جگہوں پر رہتے ہیں، اور گروپ دو بار ظاہر ہوتا ہے۔
یہ جملہ ایک ہی سیٹنگ نہیں ہے
کچھ بھی چھونے سے پہلے ضرورت کو اختیارات کی فہرستوں میں بدلیں۔ نیچے دیا گیا جدول پوری مطابقت ہے۔
| Agreed requirement | AWS option to review | Still a separate decision |
|---|---|---|
| IKEv2 | Allowed IKE versions | Encryption, integrity, key-exchange choices |
| MODP3072 for the IKE exchange | Phase 1 DH groups, group 15 | Phase 2 key-exchange and PFS policy |
| MODP3072 for the protected-traffic exchange | Phase 2 DH groups, group 15 | The initial IKE exchange group |
| A named encryption algorithm | That phase's encryption list | Integrity and DH-group agreement |
MODP3072 گروپ 15 ہے، اور AWS اس وقت Phase 1 اور Phase 2 دونوں کی DH گروپ فہرستوں میں 15 قبول کرتا ہے۔ دونوں جگہوں پر اسے قبول کرنا دونوں جگہوں پر اس کا تقاضا کرنے کے برابر نہیں، اور اس کا ہرگز یہ مطلب نہیں کہ آپ کے ساتھی کا مقصد دونوں تھا۔
Phase 1 اور Phase 2 مختلف چیزوں پر مذاکرات کرتے ہیں
Phase 1 IKE سیکیورٹی ایسوسی ایشن بناتا ہے: دونوں گیٹ ویز کیسے تصدیق کرتے ہیں، کلیدوں پر کیسے متفق ہوتے ہیں اور اپنی گفتگو کیسے محفوظ رکھتے ہیں۔ Phase 2 وہ CHILD SA بناتا ہے جو آپ کی اصل ٹریفک لے کر چلتا ہے، اور اس کی کلید کی تبدیلی وراثت میں ملی نہیں بلکہ نئی ہو سکتی ہے۔
اسی تقسیم کی وجہ سے یہ اہم ہوتا ہے جب ساتھی کامل آگے کی رازداری کی بات کرتا ہے۔ PFS Phase 2 کی خصوصیت ہے، اور Phase 1 فہرست میں موجود گروپ یہ فراہم نہیں کرتا۔ پوچھیں کہ ہر ضرورت کس تبدیلی پر لاگو ہوتی ہے، ساتھ میں انکرپشن موڈ، کیا سالمیت AEAD سائفر سے ملتی ہے، اور دونوں طرف کلید کی تجدید کی توقعات۔
AES لفظ یا ایک DH نمبر سے مکمل قابلِ قبول سیٹ اخذ نہ کریں۔ دو گفتگوں کے دو نصف حصوں سے بنائی گئی پالیسی ہی وہ راستہ ہے جس سے ٹنل ایسی چیز تجویز کرتا ہے جس پر کسی ٹیم نے اتفاق نہیں کیا۔
اجازت یافتہ فہرست مذاکرات کا نتیجہ نہیں ہے
اختیارات کی فہرستیں بتاتی ہیں کہ ہر فریق کیا قبول کرنے کو تیار ہے۔ وہ نہیں بتاتیں کہ کیا منتخب ہوا۔ نئے کنکشن کے لیے واقعی منتخب کردہ IKE اور CHILD-SA تجاویز پڑھیں، پھر تصدیق کریں کہ ضرورت صرف اجازت یافتہ نہیں بلکہ پوری ہوئی ہے۔ فہرست میں موجود مضبوط اختیار صرف یہ ثابت کرتا ہے کہ وہ دستیاب تھا۔
تجدید پر بھی نظر رکھیں۔ پہلا IKEv2 CHILD SA اور بعد میں PFS والی CHILD تبدیلی مختلف مطابقت کی شرائط سامنے لا سکتی ہیں، کیونکہ دوسری تبدیلی PFS گروپ کے ساتھ نئی کلیدی مواد بناتی ہے۔ اگر آپ کا قبولیت ٹیسٹ ٹنل کے صرف پہلے منٹ کا احاطہ کرتا ہے، تو اس نے وہ حصہ آزمایا ہی نہیں جو آپ کے ساتھی کے لیے اہم ہے۔
AWS ٹنل اختیارات کا حوالہ Phase 1 اور Phase 2 کو الگ الگ فہرست کرتا ہے، اور اگلی ضرورت آنے سے پہلے یہی ڈھانچہ سمجھنا لائق ہے۔
وہی ٹنل بدلیں جس کا واقعی مقصد ہے
Site-to-Site VPN کنکشن میں دو ٹنل ہوتے ہیں جن کے اپنے اختیارات اور اپنی حالت ہوتی ہے۔ کچھ بھی جائزہ لینے یا تبدیل کرنے سے پہلے AWS ٹنل کا بیرونی پتہ کسٹمر گیٹ وے کی طرف کے پیر سے ملائیں، اور یہ نہ سمجھیں کہ ایک محفوظ کرنا دونوں کو اپ ڈیٹ کرتا ہے۔
منظور شدہ تبدیلی کے لیے ضروری ہے کہ کسٹمر گیٹ وے کی طرف اسی پالیسی کے لیے تیار ہو اور منتخب ٹنل کو جس رکاوٹ کا سامنا ہوگا اس کے لیے وقت کی کھڑکی ہو۔ اگر جس مرحلے کو آپ بدل رہے ہیں اس میں پیر گروپ 15 کے لیے تیار نہیں، تو ٹنل اوپر آنا بند کر دے گا، اور کنسول آپ کو نہیں بتائے گا کہ کس طرف نے انکار کیا۔
متفقہ پالیسی کو مرحلہ، پروٹوکول نسخہ، انکرپشن، سالمیت اور DH گروپ کے طور پر درج کریں، پھر ان تبدیلیوں پر اس کی تصدیق کریں جن کی اسے حفاظت کرنی ہے۔ روٹنگ، ٹریفک منتخب کنندگان اور ایپلیکیشن اجازتیں الگ رہتی ہیں؛ یہ نقشہ مکمل گیٹ وے کنفیگریشن نہیں ہے، اور تنوع کے لیے اضافی الگورتھم فعال کرنے کی سفارش بھی نہیں ہے۔