ایک سے زیادہ کلائنٹس کے لیے موزوں IKEv2 ترتیبات کی منصوبہ بندی کریں
ایک فعال ڈیسک ٹاپ پروفائل نے صرف ایک کلائنٹ کی جانچ کی ہے۔ شناخت کے معاہدے پر اتفاق کریں، معاون تقاطع منتخب کریں، پھر ہر پلیٹ فارم کے لیے تجدید اور نیند کی جانچ کریں۔
ایک ڈیسک ٹاپ پر فعال پروفائل ایک کلائنٹ کا کامیاب تجربہ ہے۔ یہ بین الپلیٹ فارم تعیناتی نہیں ہے، اور اسے ایسا سمجھنے سے معروف معاونت کا نمونہ بنتا ہے: Windows جڑتا ہے، فون شناخت کی جانچ میں ناکام ہوتا ہے، اور زیر انتظام لیپ ٹاپ ہر بار جاگنے پر دوبارہ جڑتا ہے۔ فرق حقیقی ہیں اور زیادہ تر قابل قیاس ہیں، اسی لیے منصوبہ اسکرین شاٹ نہیں بلکہ ایک میٹرکس ہونا چاہیے۔
پہلے شناخت کا معاہدہ طے کریں
الگورتھم پر بحث سے پہلے سرور کی شناخت، سرٹیفکیٹ پر اعتماد اور کلائنٹ کی توثیق کا طریقہ دستاویز کریں۔ یہ تینوں طے کرتے ہیں کہ کلائنٹ توثیق کر سکتا ہے یا نہیں، اور پلیٹ فارم انہی حصوں کو مختلف انداز میں بیان کرتے ہیں۔
جانچیں کہ ہر پلیٹ فارم متوقع شناخت کنندہ کو کیسے نام دیتا ہے اور موضوع کے متبادل ناموں کو کیسے سنبھالتا ہے۔ ایک کلائنٹ پر سرور کا نام قبول کرنے والا پروفائل دوسرے پر وہی سرٹیفکیٹ مسترد کر سکتا ہے، کیونکہ شناخت کنندہ کا خانہ کسی مختلف قدر سے بھرتا ہے۔
| Contract element | What to decide | Where platforms diverge |
|---|---|---|
| Server identity | Name or address the client must see | Identifier field and SAN matching |
| Client authentication | Certificate, EAP method or both | Which EAP variants exist and how prompts appear |
| Trust anchor | Which CA and how it is delivered | Store location and provisioning path |
پھر خفیہ نگاری کا تقاطع منتخب کریں
ہر معاون کلائنٹ کی پیش کردہ تجاویز کا موازنہ کریں اور ایک جدید تقاطع منتخب کریں جسے گیٹ وے بھی اجازت دیتا ہو۔ ایک پرانے آلے کے جڑنے کے لیے بہت بڑی پرانی فہرست فعال نہ کریں، کیونکہ وہ فہرست بعد میں آنے والوں سب کے لیے گیٹ وے کی طے شدہ ترتیب بن جاتی ہے۔ لکھیں کہ ہر پرانا اختیار اب بھی کیوں موجود ہے۔ اگر کوئی اس آلے کا نام نہیں بتا سکتا جسے اس کی ضرورت ہے، تو یہ ضرورت نہیں ہے۔
منصوبے میں IKE اور CHILD کی ترتیبات الگ رکھیں۔ IKE تبادلے کے لیے قابل قبول تجویز محفوظ ٹریفک کے لیے خود بخود قابل قبول نہیں ہوتی، اور دونوں کا الگ الگ مذاکرہ ہوتا ہے۔ ایک پرت پر تجویز قبول کرنے والا گیٹ وے دوسری پرت پر اسے مسترد کر سکتا ہے، اور لاگ ایسی ناکامی دکھائے گا جو پہلی پرت کے کامیاب ہونے جیسی لگے۔
قابل تصدیق عمل کے ذریعے اسناد فراہم کریں، اور صارف کا پاس ورڈ، مشترکہ راز اور کلائنٹ کی نجی کلید ان کے اپنے خانوں میں رکھیں۔ ایک جیسے نام والے بکسوں پر آزمائش اور غلطی ہی وہ راستہ ہے جس سے فعال تجربہ ناقابلِ تکرار تجربہ بن جاتا ہے۔
مستحکم حالت نہیں، زندگی کے چکر کی جانچ کریں
ہر کلائنٹ کے لیے ابتدائی توثیق، مطلوبہ ایپلیکیشن، DNS حل اور پتہ خاندانوں کی کوریج کی جانچ کریں۔ پھر صرف بعد میں ظاہر ہونے والے حصوں کی مشق کریں: تجدید، نیند اور عام نیٹ ورک تبدیلی۔
MOBIKE کی معاونت اور دوبارہ توثیق کا رویہ اس مستحکم نتیجے سے مختلف ہو سکتا ہے جو آپ نے ابھی ناپا ہے۔ اسی لمحے کا واقعہ اور انجمن کی حالت ریکارڈ کریں، صرف یہ نہیں کہ انٹرفیس آخر میں جڑا ہوا دکھتا ہے۔
طے کریں کہ VPN کی عدم دستیابی کے دوران براہ راست ٹریفک کیا کر سکتا ہے۔ یہ اس بات سے الگ پالیسی فیصلہ ہے کہ کلائنٹ دوبارہ جڑتا ہے یا نہیں، اور زیادہ تر تعیناتیاں پہلے سوال کو نظر انداز کرتے ہوئے دوسرے کا جواب دیتی ہیں۔ جواب پروفائل ناموں کے ساتھ تعیناتی نوٹس میں لکھیں۔ کسی کو خلل کے دوران اس کی ضرورت ہوگی، اور اسے دوبارہ بنانے کا وقت نہیں ہوگا۔
جب کوئی ایک پلیٹ فارم متفق نہ ہو تو سرور کی شناخت کی جانچ استعمال کریں
جب پروفائل ایک پلیٹ فارم پر کام کرتا ہے اور دوسرا اس کا نام مسترد کرتا ہے، تو کلائنٹ نے جو شناخت کنندہ واقعی بھیجا ہے اس کا موازنہ سرٹیفکیٹ کے شناخت کنندگان سے کریں۔ یہ موازنہ ان میں سے زیادہ تر معاملات کو سائفر فہرستوں کی تبدیلی سے زیادہ تیزی سے حل کرتا ہے۔
جانچ شدہ میٹرکس کو تشکیل کے ماخذ اور اپ ڈیٹ کے طریقہ کار کے ساتھ رکھیں۔ جب پرانے کلائنٹ کی معاونت ختم ہو، تو اگلی آڈٹ کو ملنے کے لیے گیٹ وے میں کمزور مطابقت کی ترتیبات چھپا کر رکھنے کے بجائے اس کی استثنا جان بوجھ کر ہٹا دیں۔ strongSwan کی IKEv2 دستاویزات اس بارے میں مفید حوالہ ہیں کہ تبادلے کیسے تشکیل دیے جاتے ہیں۔