Windows اور strongSwan کے سائفرز: درست تہہ ملائیں

دونوں سرے AES-128 کہتے ہیں اور ٹنل پھر بھی بننے سے انکار کرتا ہے۔ CBC اور GCM مختلف تبدیلیاں ہیں جو اتفاقاً ایک ہی چابی کی لمبائی رکھتی ہیں، اور ایک پیش کرنے والا کلائنٹ صرف دوسری قبول کرنے والے گیٹ وے کو مطمئن نہیں کرتا۔ AES لفظ ایک خاندان بیان کرتا ہے، معاہدہ نہیں۔

دوسرا محور بھی ہے، اور الجھانے والی غلطیاں وہی پیدا کرتا ہے۔

دو تہیں، دو آزاد فہرستیں

IKE خود مذاکرات کی حفاظت کرتا ہے، جبکہ چائلڈ ایسوسی ایشن اُس ٹریفک کی حفاظت کرتی ہے جو واقعی آپ کے لیے اہم ہے۔ Windows پہلی کو انکرپشن طریقہ اور سالمیت طریقہ کے طور پر، اور دوسری کو سائفر اور تصدیق کی تبدیلی کے مستقل کے طور پر پیش کرتا ہے۔ یہ فیلڈز ایک دوسرے کے متبادل نام نہیں ہیں، اور ایک میں درست قدر دوسرے میں بے معنی یا غلط ہو سکتی ہے۔ اس تقسیم کو ذہن میں رکھ کر پروفائل پڑھنا زیادہ تر الجھن دور کر دیتا ہے۔

عملی نتیجہ یہ ہے کہ آپ کے پاس مکمل طور پر قابل قبول چابی کے تبادلے کی پالیسی اور ایسی ڈیٹا چینل پالیسی ہو سکتی ہے جو ساتھی قبول نہ کرے۔ ایک فہرست مذاکرات کرتی ہے؛ دوسری پیکٹوں کی حفاظت کرتی ہے۔ پہلی میں قدر بدلنے کا دوسری پر کوئی اثر نہیں ہوتا، چاہے کنفیگریشن ڈائیلاگ میں دونوں کتنے ہی مماثل نظر آئیں۔

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

غلطی کو تجاویز کے پاس پڑھیں

جو مرحلہ ناکام ہوا وہ بتاتا ہے کہ کون سی فہرست دیکھنی ہے۔ ابتدائی چابی کے تبادلے کے دوران انکار IKE تجویز کا مسئلہ ہے، اور یہ کسی بھی چائلڈ ایسوسی ایشن کے وجود سے پہلے ہوتا ہے۔ محفوظ ٹریفک ایسوسی ایشن پر مذاکرات کے دوران ناکامی ESP تجویز کا مسئلہ ہے، اور چابی کا تبادلہ پہلے ہی کامیاب ہو چکا ہے۔ کلائنٹ کا عام پالیسی مماثلت کا پیغام دونوں میں سے کسی مرحلے کا نام نہیں لیتا، اسی لیے گیٹ وے کا اپنا نقطہ نظر مفید ہے۔

swanctl --list-conns
swanctl --list-sas
journalctl -u strongswan -n 60 --no-pager

موصول تجویز، ترتیب شدہ تجویز اور منتخب تجویز کا موازنہ کریں اسی ایک کوشش کے لیے۔ یہاں تین مختلف فہرستیں اہم ہیں، اور صرف آخری بتاتی ہے کہ اصل میں کیا استعمال ہوا۔ خلاصہ کرنے کے بجائے ٹکٹ میں اسے لفظ بہ لفظ نقل کریں۔

CBC اور GCM کو الگ متبادل کے طور پر رکھیں

جس گیٹ وے کو جان بوجھ کر کسی بھی خاندان کو قبول کرنے کی اجازت ہے اسے ایک نہیں، دو تجاویز چاہئیں۔ strongSwan میں کوما متبادل الگ کرتا ہے، اور ڈیش ایک ہی سیٹ کے اجزا کو جوڑتا ہے۔ دونوں خاندانوں کو ڈیش سے ملانے پر دو قابل قبول تجاویز کے بجائے ایک ناممکن تجویز بنتی ہے۔

proposals = aes128gcm16-prfsha256-ecp256, aes128-sha256-ecp256
esp_proposals = aes128gcm16-ecp256

پہلا متبادل تصدیق شدہ انکرپشن رکھتا ہے اور پھر بھی سیوڈو رینڈم فنکشن کا نام لیتا ہے، کیونکہ چابی کی اخذ کو ایک کی ضرورت ہوتی ہے چاہے سالمیت سائفر سے آئے۔ دوسرا متبادل الگ سالمیت الگورتھم کے ساتھ روایتی انکرپشن ہے۔ دونوں اس پر منحصر رہتے ہیں کہ لوڈ شدہ کریپٹو عمل درآمد کیا سہارا دیتا ہے۔

ESP تجویز دوبارہ نام دی گئی IKE تجویز نہیں ہے

سائفر ٹوکن دونوں فہرستوں میں یکساں نظر آتا ہے، اور تقریباً کچھ اور منتقل نہیں ہوتا۔ ESP تجویز میں چابی کے تبادلے کا سیوڈو رینڈم فنکشن نہیں ہوتا، اور اس کی سالمیت اور آگے کی رازداری کی شرائط IKE سطر سے نقل کرنے کے بجائے دوسری طرف کی Windows پالیسی کے خلاف دلیل سے طے ہوتی ہیں۔ ایک فہرست کا دوسری میں مشینی ترجمہ ایسی چیز بناتا ہے جو تصدیق پاتی ہے اور کبھی مذاکرات نہیں کرتی۔

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

دونوں سیٹ تصدیق کریں، پھر چابی کی تجدید

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

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