iOS IKEv2 سے strongSwan تک: کوئی تجویز منتخب نہیں ہوئی، فہرست درست کریں

iPhone سرنگ کو بلند کرتا ہے، گیٹ وے کچھ جواب نہیں دیتا اور فون ایک عام ناکامی دکھاتا ہے۔ strongSwan کا لاگ زیادہ مخصوص ہے: no proposal chosen۔ یہ پیغام اس بات کا مطلب ہے کہ قابل قبول سائفر سیٹوں کی دونوں فہرستیں کبھی ایک دوسرے پر نہیں چڑھیں، اس لیے تبادلہ تصدیق شروع ہونے سے پہلے ہی ختم ہو گیا۔ یہ ملاپ کا مسئلہ ہے اور حل یہ ہے کہ فہرستیں ایک دوسرے کو کاٹیں۔

گیٹ وے اپنی پالیسی کہاں بیان کرتا ہے

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

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

اسی لیے کسی دوسرے VPN ایپ سے نقل شدہ پروفائل وہاں کام کر سکتا ہے جہاں آپ کا نہیں کرتا: اس ایپ نے مختلف فہرست بھیجی تھی۔

نام ملنے چاہئیں، بہتر نہیں ہونے چاہئیں

strongSwan سے iOS میں اقدار منتقل کرنے والوں کو دو ترجمے الجھن میں ڈالتے ہیں۔ IKE تجویز میں SHA1 لکھا ہوا سالمیت کا الگورتھم اپنی مختصر شکل میں سفر کرتا ہے، جسے iOS .SHA96 کہتا ہے۔ modp1024 لکھا ہوا Diffie-Hellman گروپ گروپ 2 ہے، جسے iOS .group2 کہتا ہے۔ SHA-256 یا گروپ 14 سے بدلنے پر صرف پرانی جوڑی قبول کرنے والے گیٹ وے سے بات چیت نہیں ہوگی۔ کلائنٹ کو زیادہ مضبوط نہیں، وہی الگورتھم بیان کرنا ہے۔

ان اقدار کو NEVPNProtocolIKEv2 میں واضح طور پر مقرر کریں۔ طے شدہ اقدار بدلی جانے والی پروفائل سے زیادہ وسیع یا زیادہ تنگ ہو سکتی ہیں، اور فرق صرف اس وقت ظاہر ہوتا ہے جب ہینڈ شیک ناکام ہو۔

چائلڈ تجویز بعد میں اور زیادہ خاموشی سے ناکام ہوتی ہے

صرف IKE نہیں، چائلڈ سیکیورٹی ایسوسی ایشن بھی کنفیگر کریں۔ جب صرف IKE پیرامیٹر ملتے ہیں تو سرنگ تصدیق ہو جاتی ہے اور پھر ٹریفک نہیں اٹھاتی، جو انکار سے کہیں زیادہ خاموش ناکامی ہے۔ چائلڈ کی انکرپشن، سالمیت، گروپ اور عمر ایک ہی مرحلے میں مقرر کریں۔ کلائنٹ کی عمر گیٹ وے کی قدر کے برابر یا اس سے کم رکھیں، کیونکہ زیادہ لمبی پر اصرار کسی اور وجہ سے وہی no proposal chosen پیغام دیتا ہے۔ وہاں کی ناہم آہنگی لاگ میں IKE کی ناہم آہنگی جیسی دکھتی ہے۔

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

پرانا سیٹ صرف اس وقت تک رکھیں جب تک ضرورت ہو

SHA-1 کو 1024 بٹ گروپ کے ساتھ پن کرنا ایک پل ہے، منزل نہیں۔ دونوں متروک ہیں اور نئے کلائنٹ انہیں مکمل طور پر رد کر سکتے ہیں، یعنی آپ کی طرف کسی تبدیلی کے بغیر اگلے آلے پر پروفائل ناکام ہوگا۔ پن کو عارضی سمجھیں اور ریکارڈ میں ایسا لکھیں۔

اگر strongSwan آپ کا ہے تو جدید تجویز شامل کریں اور پرانے اندراج کو پرانے آلات کے لیے رہنے دیں جبکہ دونوں سرے اوپر کی طرف بات چیت کریں۔ ڈیمن کی حالت کی آؤٹ پٹ پڑھیں تاکہ دیکھ سکیں کہ ہر کنکشن نے واقعی کون سا سیٹ استعمال کیا۔ پھر جدید جوڑی کی تصدیق ہونے پر کلائنٹ کی طرف کا پن ہٹا دیں۔ سرنگ کا بلند ہونا کافی ثبوت نہیں، کیونکہ یہ اسی سیٹ پر بھی بلند ہو سکتی ہے جسے آپ ہٹانا چاہتے تھے۔ strongSwan کی IKEv2 دستاویزات تجاویز کی نحو اور strict نشان بیان کرتی ہیں۔