Windows اور FortiGate پر IKEv2: تین ترتیبات جنہیں لوگ ملا دیتے ہیں
IKE کلید کا تبادلہ، CHILD SA تحفظ اور ساتھی کی توثیق تین الگ قطاریں ہیں۔ دو ڈائیلاگ میں ایک جیسے گروپ نمبر انہیں یکجا نہیں کرتے۔
Windows کلائنٹ اور FortiGate گیٹ وے کے درمیان IKEv2 معاہدہ مسلسل ناکام ہو رہا ہے، اور نہ ملنے والے نمبر کی تلاش مزید طویل نمبروں کی فہرست دیتی ہے۔ فہرست صرف اسی وقت قابلِ انتظام بنتی ہے جب اسے تین الگ قطاروں میں تقسیم کیا جائے جو الگ الگ ناکام ہوتی ہیں: وہ کلید کا تبادلہ جو IKE کی حفاظت کرتا ہے، CHILD SA پر لگائی جانے والی حفاظت، اور وہ توثیق جو ثابت کرتی ہے کہ ہر فریق کون ہے۔ گروپ نمبر ان میں سے دو قطاروں میں آتے ہیں اور مختلف معنی رکھتے ہیں۔
تین قطاریں جو الگ الگ ناکام ہوتی ہیں
پہلی قطار IKE کے اندر کلید کا تبادلہ ہے، جو گفت و شنید کی حفاظت کرنے والی کلیدیں پیدا کرتا ہے۔ دوسری CHILD SA کے لیے تجویز ہے، جو سرنگ کے اٹھائے ہوئے ٹریفک کی حفاظت کرتی ہے۔ تیسری توثیق ہے، جو طے کرتی ہے کہ ہر فریق کیا پیش کرتا ہے اور دوسرا اسے کیسے جانچتا ہے۔
ناکامیاں مختلف جگہوں پر آتی ہیں۔ تبادلے کی ناکامی کوئی سرنگ بننے سے پہلے ہی گفت و شنید روک دیتی ہے۔ CHILD SA کی ناکامی توثیق کامیاب ہونے کے بعد ہوتی ہے، بعض اوقات صرف کلید بدلنے پر۔ اگر صرف پہلی غلطی پڑھیں تو توثیق کی ناکامی لاگوں میں تبادلے کی ناکامی جیسی لگ سکتی ہے۔
قطاروں کو تقسیم کرنا حساب کتاب نہیں ہے۔ یہ بدلتا ہے کہ کون سی ترتیب بدلنے کے قابل ہے، اور یہ اس پورے میدان کی سب سے مہنگی حرکت کو روکتا ہے، یعنی تجویز کے عدم توازن کو درست کرنے کے لیے کام کرنے والے سرٹیفکیٹ دوبارہ بنانا۔ ایک قطار بدلنے سے باقی دو کو اس کے ساتھ بدلنے پر مجبور نہیں ہونا چاہیے۔ انہیں الگ الگ لکھنے کا پورا مقصد یہی آزادی ہے۔
Windows کے دو فیلڈ کیا کنٹرول کرتے ہیں
Windows دو فیلڈ الگ رکھتا ہے: DHGroup خود IKE تبادلے کی تشکیل کرتا ہے، جبکہ PfsGroup سرنگ کے اندر ٹریفک کی حفاظت کرنے والی IPsec پالیسی کی تشکیل کرتا ہے۔ یہ مختلف مراحل سے تعلق رکھتے ہیں۔ Windows کے IKE فیلڈ کا FortiGate کی phase-2 قدر سے موازنہ غلط جوڑی جانچتا ہے، اور نمبر مل بھی جائیں تو بنیادی تبادلہ پھر بھی ناکام ہو سکتا ہے۔
Get-VpnConnection -Name "Corp-IKEv2"
Get-NetIPsecMainModeSA
Get-NetIPsecQuickModeSAدوسرا اور تیسرا کمانڈ ان سیکیورٹی ایسوسی ایشنز کی رپورٹ دیتے ہیں جو واقعی موجود ہیں، اور یہی اس جواب کے سب سے قریب ہے جو کلائنٹ آپ کو دے سکتا ہے۔ quick-mode ایسوسی ایشن کے بغیر main-mode ایسوسی ایشن CHILD SA کا مسئلہ ہے، اور یہ سرٹیفکیٹ کا مسئلہ نہیں بلکہ phase-2 عدم توازن کی نشانی ہے۔
ایک کوشش میں کیا پیش کیا گیا اور کیا منتخب ہوا، ریکارڈ کریں۔ قابلِ قبول تجویز پر مشتمل پیش کردہ فہرست اور گیٹ وے کی پالیسی سے نہ ملنے والی منتخب تجویز ایک ترتیب کا اختلاف ہے، باہمی عمل کی کوئی معمہ نہیں۔
| Agreement row | Where it is configured in Windows | What it does not decide |
|---|---|---|
| IKE key exchange | DHGroup on the VPN connection IPsec settings | The protection used for tunneled traffic |
| CHILD SA protection | PfsGroup in the same policy object | Which certificate the peer presents |
| Peer authentication | Machine or user certificate, or a supported EAP method | Any group number used for key exchange |
| Certificate validation | Trusted CA store on the validating side | The private key of the certificate being presented |
بیضوی منحنی گروپ آپ کی دستخط کلید منتخب نہیں کرتا
اس میدان میں سب سے زیادہ قائم غلط استنباط یہ ہے کہ بیضوی منحنی DH گروپ منتخب کرنے کے لیے بیضوی منحنی سرٹیفکیٹ درکار ہوتا ہے۔ DH گروپ کلید کے تبادلے کا مواد فراہم کرتا ہے؛ دستخط کا الگورتھم توثیق کے فریم ورک سے طے ہوتا ہے، اور IKEv2 میں یہ دو الگ فیصلے ہیں۔
RFC 7427 اسی لیے موجود ہے کہ یہ فیصلے پہلے آپس میں الجھے ہوئے تھے، اور یہ طے کرتا ہے کہ دستخط کے الگورتھم کلید کے تبادلے سے آزاد ہو کر کیسے اعلان اور انتخاب کیے جاتے ہیں۔ ایک گیٹ وے بیک وقت منحنی گروپ اور دستخط کے طریقوں کا انتخاب سپورٹ کر سکتا ہے۔
اس لیے جب گروپ بدلنے کے بعد گفت و شنید ناکام ہو، تو سرٹیفکیٹ کی کلید کی قسم دیکھنے سے پہلے توثیق کا طریقہ دیکھیں۔ سرٹیفکیٹ بدلنا ایک سست اور خطرناک عمل ہے جو شاذ و نادر ہی جواب ہوتا ہے، اور اسے پہلے کرنا یہ جاننے کی صلاحیت کو تباہ کر دیتا ہے کہ کون سی تبدیلی واقعی مددگار ثابت ہوئی۔ سرٹیفکیٹ کے ذخیرے کو چھونے سے پہلے توثیق کی قطار پڑھیں۔
دونوں کو معاہدے کی شیٹ کی الگ قطاروں میں رکھیں تو یہ غلطی پرکشش رہنا چھوڑ دے گی۔ ایک قطار گروپ گنواتی ہے، دوسری دستخط کے طریقے اور شناختیں گنواتی ہے، اور کوئی بھی دوسری کے بارے میں ثبوت نہیں ہے۔
ہر نجی کلید کو اس کے اصل مالک کے پاس رکھیں
جو گیٹ وے اپنا سرٹیفکیٹ پیش کرتا ہے اسے اس سے ملنے والی نجی کلید درکار ہوتی ہے۔ جو ساتھی زنجیر کی تصدیق کرتا ہے اسے CA سرٹیفکیٹ درکار ہوتا ہے، اور اسے خاص طور پر CA کی دستخط کلید درکار نہیں ہوتی۔ ان تینوں چیزوں کو گڈمڈ کرنا ہی وہ طریقہ ہے جس سے لوگ CA کی نجی کلید VPN ڈیوائس میں درآمد کرتے ہیں تاکہ کوئی سرٹیفکیٹ کسی اور زمرے میں نظر آئے۔
FortiOS پر کردار الگ ہیں: اپنی کلید کے ساتھ مقامی سرٹیفکیٹ، ساتھی کی شناخت کے لیے استعمال ہونے والا بعید سرٹیفکیٹ، اور بعید CA کا اندراج جو اس CA کے دستخط کردہ سرٹیفکیٹوں پر اعتماد قائم کرتا ہے۔ نجی کلید کے بغیر بعید CA اندراج نامکمل نہیں؛ یہ اپنے مقصد کے لیے درست ہے۔
درآمد شدہ CA دستخط کلیدیں اس ڈیوائس کو پڑھ سکنے والے ہر شخص کا اختیار وسیع کرتی ہیں۔ یہ عام ساتھی کی تصدیق بھی حل نہیں کرتیں، کیونکہ تصدیق کے لیے عوامی سرٹیفکیٹ اور اعتماد کا فیصلہ درکار ہوتا ہے، نئے سرٹیفکیٹ بنانے کی صلاحیت نہیں۔
CA دستخط کلید کو جاری کرنے والے کے اپنے عمل کے پاس رکھیں، اور ریکارڈ کریں کہ کون سی ڈیوائس کون سی کلید رکھتی ہے۔ جب آڈٹ پوچھے کہ کون کس کا روپ دھار سکتا تھا تو مالکان کی چھوٹی جدول الگورتھم کی لمبی جدول سے زیادہ قدر رکھتی ہے۔ کوئی ایسی کلید درآمد نہیں کرتا جسے وہ صرف فہرست جانتا ہو۔ فہرست واقعے سے پہلے لکھیں، بعد میں نہیں۔