Windows اور strongSwan: IKE تجویز میں چار تبدیلیوں کا میل
جب دونوں فریق کلید کے تبادلے کے گروپ پر متفق نہ ہوں تو مشترکہ سائفر کافی نہیں۔ چاروں تبدیلیوں کا موازنہ کریں، پھر ایک محدود پروفائل پالیسی لاگو کریں۔
دونوں فریق AES کی حمایت کرتے ہیں، دونوں SHA-256 قبول کرتے ہیں، پھر بھی ٹنل اوپر نہیں آتا۔ تجویز اس جزو پر ناکام ہوئی جس کا کسی نے موازنہ نہیں کیا، عام طور پر کلید کے تبادلے کے گروپ پر۔ یہ رہنما کچھ بھی بدلنے سے پہلے اصل تبادلہ پڑھتا ہے، ایک محدود پالیسی لاگو کرتا ہے اور پچھلے پیرامیٹر بحال کرنے والا واپسی کا راستہ چھوڑتا ہے۔
گروپ بدلنے سے پہلے ناکامی پڑھیں
«پالیسی میل کی خرابی» خلاصہ ہے، تشخیص نہیں۔ اس کا مطلب ہے کہ باہمی طور پر قابل قبول تجویز نہیں ملی، اور یہ نہیں بتاتا کہ کون سا جزو مسترد ہوا۔ اسے تحقیقات کا آغاز سمجھیں، کسی مخصوص گروپ کے بارے میں ثبوت نہیں۔
جواب عام طور پر سرور کی طرف ہوتا ہے۔ مناسب سطح کا strongSwan لاگ کلائنٹ سے موصول ہونے والی تجویز اور قبول کرنے کے لیے ترتیب دی گئی تجویز کی فہرست دیتا ہے، اور دونوں فہرستوں کا فرق ناکام جزو کا نام بتاتا ہے۔
یہ مت سمجھیں کہ کلائنٹ وہی پیش کرتا ہے جو کوئی پرانی فورم پوسٹ کہتی ہے۔ فعال پروفائل اور اس کی نصب شدہ پالیسی پیش کردہ فہرست کا تعین کرتے ہیں، اور اپ ڈیٹ شدہ Windows بلڈ اس اسکرین شاٹ سے مختلف مجموعہ پیش کر سکتا ہے جس سے آپ نقل کر رہے ہیں۔
دونوں فہرستیں لکھ لیں۔ چار تبدیلی کی جگہیں اور ایک گروپ مختصر فہرست ہے، اور اس کا سطر بہ سطر موازنہ کسی بھی تجربے سے کم وقت لیتا ہے۔ چار جگہیں نظر میں رکھنا آسان ہے۔ لاگ فائل نہیں۔
ایک مانوس نام کا نہیں، ہر تبدیلی کا موازنہ کریں
IKE تجویز ایسے انتخاب کا مجموعہ ہے جن سب کو میل کھانا چاہیے۔ انکرپشن مذاکرات کی حفاظت کرتا ہے، سالمیت یا کوئی PRF اس کی تصدیق کرتا ہے، اور Diffie-Hellman گروپ نئی کلید کا مواد قائم کرتا ہے۔ پہلے دو میں میل کھانے اور تیسرے میں مختلف ہونے والی تجویز دونوں فریقوں کے لیے پھر بھی ناقابل قبول ہے۔
یہاں جن دو Windows فیلڈز میں الجھن ہوتی ہے وہ مختلف مراحل سے تعلق رکھتی ہیں۔ DHGroup IKE کلید کے تبادلے پر لاگو ہوتا ہے، جبکہ PfsGroup ٹریفک کی حفاظت کرنے والی چائلڈ ایسوسی ایشن پر لاگو ہوتا ہے۔ دوسرے کو بدلنے سے پہلے کی ناکامی درست نہیں ہو سکتی۔
گروپوں کے نام مختلف عمل آوریوں میں مختلف ہوتے ہیں، اور یہ الجھن کا الگ ذریعہ ہے۔ strongSwan modp2048 اور ecp256 لکھتا ہے، جبکہ Windows Group14 اور ECP256 جیسے گنتی نام استعمال کرتا ہے، اس لیے موازنے سے پہلے ترجمہ کرنا پڑتا ہے۔ دونوں ناموں کے ساتھ دو کالم کی نوٹ رکھیں۔ پھر اگلی عدم مطابقت سیکنڈوں میں درجہ بند ہو جاتی ہے۔
| Transform | Windows parameter | strongSwan name | Failure it causes |
|---|---|---|---|
| Encryption | CipherTransformConstants | aes, aes256gcm and similar | No common proposal at all |
| Integrity or PRF | AuthenticationTransformConstants | sha256, sha512 and similar | Proposal rejected after encryption matches |
| Key-exchange group | DHGroup | modp2048, ecp256 | Exchange fails during key establishment |
| Child SA protection | PfsGroup | esp proposal groups | Tunnel negotiates, data association does not |
ایک مکمل اور محدود پالیسی لاگو کریں
مقامی IKEv2 پروفائل کے لیے معاون ذریعہ فی کنکشن IPsec پالیسی ہے، جو فیلڈ بہ فیلڈ کے بجائے ایک آبجیکٹ کے طور پر مقرر کی جاتی ہے۔ پہلے پیش نظارہ کریں، پھر لاگو کریں، اور پچھلے پیرامیٹر تبدیلی کے ریکارڈ میں رکھیں۔
Set-VpnConnectionIPsecConfiguration -ConnectionName "Northwind IKEv2" -AuthenticationTransformConstants SHA256128 -CipherTransformConstants AES256 -EncryptionMethod AES256 -IntegrityCheckMethod SHA256 -DHGroup ECP256 -PfsGroup ECP256 -WhatIf-WhatIf سوئچ مقامی تبدیلی کا پیش نظارہ دکھاتا ہے اور کچھ لاگو نہیں کرتا۔ یہ مفید ہے اور ساتھ ہی عام جال بھی، کیونکہ پیش نظارہ صرف یہ ثابت کرتا ہے کہ پیرامیٹر مقامی cmdlet کے لیے نحوی طور پر قابل قبول ہیں۔ یہ نہیں بتاتا کہ گیٹ وے نتیجے میں آنے والی تجویز قبول کرے گا یا نہیں۔
وہیں رہتے ہوئے دائرہ بھی ملائیں۔ تمام صارفین کے اسٹور میں موجود کنکشن کو متعلقہ تمام-صارف پیرامیٹر درکار ہے، اور اسی ظاہری نام کے ساتھ فی صارف پروفائل میں ترمیم کرنے سے کوئی دوسرا آبجیکٹ بدلتا ہے جو ٹنل استعمال نہیں کرتا۔
پھر جانچ سے پہلے strongSwan طرف کو اسی مجموعے پر لائیں۔ دونوں سروں پر مربوط تبدیلی ہی اس کی واحد صورت ہے جو ہم آہنگ ہوتی ہے؛ ایک طرف بدل کر بار بار دوبارہ کوشش کرنے سے اسی مستردگی سے بھرا لاگ بنتا ہے۔
تبادلے اور کلید کی تجدید کی الگ الگ جانچ کریں
کامیاب کنکشن ایک مشاہدہ ہے، اور کلید کی تجدید دوسرا۔ ابتدائی IKE مذاکرات ایک پیرامیٹر مجموعہ استعمال کرتے ہیں، اور ٹریفک اٹھانے والی چائلڈ ایسوسی ایشن بعد میں اپنی پالیسی کے ساتھ دوبارہ مذاکرات کر سکتی ہے۔ جو سیٹ اپ جڑتا ہے اور پھر کچھ دیر بعد گر جاتا ہے وہ عام طور پر دوسرا معاملہ ہوتا ہے۔
ipsec statusall | grep -A6 "Northwind"
Get-VpnConnection -Name "Northwind IKEv2" | Format-List *پہلا حکم قائم شدہ ایسوسی ایشنوں کے بارے میں سرور کا نظریہ دکھاتا ہے، جس میں چائلڈ SA اور اس کی باقی عمر شامل ہے۔ دوسرا دکھاتا ہے کہ کلائنٹ پروفائل میں اب کیا ہے، اور یہی تصدیق کرنے کا واحد طریقہ ہے کہ آپ کی مقرر کردہ پالیسی ہی مؤثر پالیسی ہے۔
کامیابی کا اعلان کرنے سے پہلے مکمل کلید کی تجدید دیکھیں۔ اس کا مطلب ہے کنکشن کو اتنی دیر اوپر رکھنا کہ چائلڈ ایسوسی ایشن بدل جائے، اور پھر تصدیق کرنا کہ ٹریفک جاری ہے۔ زیادہ تر پالیسی عدم مطابقتیں اسی مرحلے میں چھپی ہوتی ہیں، کیونکہ ابتدائی مذاکرات ایسے مجموعے کے ساتھ بھی کامیاب ہو سکتے ہیں جسے تجدید قبول نہیں کرتی۔
واپسی پچھلا پیرامیٹر مجموعہ ہے، کوئی ڈھیلا متبادل نہیں۔ اگر کلائنٹ نے صرف کمزور پرانا گروپ پیش کیا تھا، تو جواب کلائنٹ اور سرور کی مشترکہ پالیسی بہتر کرنا ہے، اس گروپ کو گیٹ وے میں شامل کرنا نہیں جہاں ہر آئندہ فریق اس تک نیچے مذاکرات کر سکے۔
چار پیرامیٹر، گروپ، کنکشن کا دائرہ اور کلید کی تجدید کا نتیجہ درج کریں۔ یہ مختصر نوٹ ہے، اور رہنما اور اس کہانی کے درمیان فرق یہی ہے کہ ٹنل ایک بار کیسے اوپر آیا۔