iPhone پر IKEv2 سرٹیفکیٹ سیٹ اپ: دستی یا زیرِ انتظام اندراج

RSA کا انتخاب صرف اس لیے کہ گیٹ وے کا سرٹیفکیٹ ٹول اسے بطور ڈیفالٹ استعمال کرتا ہے، اس اہم سوال سے پہلے لیا گیا فیصلہ ہے: یہ iPhone کیسے اندراج ہوں گے؟ صارف کا خود ٹائپ کردہ کنکشن اور انتظام کا فراہم کردہ کنفیگریشن پروفائل مختلف ترتیبات دکھاتے ہیں، اور کچھ سرٹیفکیٹ اختیارات ان دو راستوں میں سے صرف ایک پر موجود ہوتے ہیں۔ ترتیب درست رکھیں تو سرٹیفکیٹ کا منصوبہ مختصر ہو جاتا ہے؛ غلطی کریں تو آپ ایسی اسناد جاری کرتے ہیں جو فون استعمال نہیں کرے گا۔ نیچے دیے گئے مراحل کو ایک تسلسل سمجھیں، کیونکہ ہر مرحلہ اگلے کے لیے دستیاب اختیارات کو تنگ کرتا ہے۔

پہلا مرحلہ: اندراج کا راستہ منتخب کریں

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

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

دوسرا مرحلہ: اپنے منتخب کردہ راستے کے لیے الگورتھم منتخب کریں

دستی طور پر ترتیب دیے گئے iPhone کے لیے، strongSwan کے iOS باہمی عمل کے نوٹس RSA سرور سرٹیفکیٹ کی سفارش کرتے ہیں، کیونکہ دستی کلائنٹ ECDSA سرور سرٹیفکیٹ قبول نہ کر سکے؛ یہی نوٹس macOS کو الگ دیکھتے ہیں۔ اسے معاون کلائنٹ سیٹ کے لیے رہنمائی پڑھیں، Apple آلات کے بارے میں دائمی قانون نہیں۔ زیرِ انتظام پروفائل کے پاس زیادہ جگہ ہے: جب پے لوڈ اور گیٹ وے دونوں معاونت کریں تو یہ ECDSA کلائنٹ شناخت سمیت سرٹیفکیٹ کی قسم واضح طور پر منتخب کر سکتا ہے۔

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

تیسرا مرحلہ: پروفائل کے فیلڈز کو الگ الگ چیزیں سمجھ کر پڑھیں

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

Apple کی IKEv2 پے لوڈ حوالہ جاتی دستاویز RSA کو واضح ECDSA اقسام کے ساتھ ڈیفالٹ سرٹیفکیٹ قسم کے طور پر درج کرتی ہے، اور جاری کنندہ کے نام کی کلید کو مخصوص تصدیق کی ترتیبات سے جوڑتی ہے۔ یہ تعلقات اپنے منتخب کردہ طریقے کی دستاویز میں پڑھیں، کسی کام کرنے والی تعیناتی سے ایک کلید نقل کرنے کے بجائے۔

چوتھا مرحلہ: گیٹ وے کی شناخت کو اس کے سرٹیفکیٹ سے ہم آہنگ کریں

واضح گیٹ وے نام استعمال کریں، مثلاً vpn.example.com اور سرور سرٹیفکیٹ میں مطابق متبادل موضوع نام رکھیں۔ strongSwan کی Apple رہنمائی سرور تصدیق کے لیے توسیع شدہ کلید کے استعمال کی بھی توقع کرتی ہے۔ RSA یا ECDSA کا انتخاب اس میں کچھ نہیں بدلتا: الگورتھم نام کی عدم مطابقت، غائب EKU یا نامکمل زنجیر کو ٹھیک نہیں کر سکتا۔

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

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

پانچواں مرحلہ: کلائنٹ شناخت کو CA اعتماد سے الگ کریں

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

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

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