IKEv1 بمع XAuth اور OTP: ہر پرامپٹ کس چیز کا مطالبہ کرتا ہے
گروپ PSK، صارف کی XAuth منتقلی اور OTP چیلنج تین مختلف ان پٹ ہیں۔ دوسرا کلائنٹ نصب کرنے سے پہلے ہر پرامپٹ کو اس کے مالک سے جوڑیں۔
PSK، XAuth اور OTP کے ساتھ IKEv1 کسی ایک پیچیدہ پاس ورڈ کا مطالبہ نہیں کرتا۔ یہ ساتھیوں کے درمیان مشترکہ کلید، صارف کی منتقلی اور دوسرا عامل پرتوں میں رکھتا ہے جس کے مطالبے کا طریقہ بیک اینڈ طے کرتا ہے۔ ہر پرت کا اپنا مالک اور اپنا ناکامی پیغام ہے۔ انہیں گڈمڈ کرنے سے لوگ گروپ راز رکھنے والے خانے میں یکبارہ کوڈ دوبارہ لکھتے ہیں۔
دوسرا کلائنٹ نصب کرنے یا اسناد ری سیٹ کرنے سے پہلے ہر پرامپٹ کو اس پرت سے جوڑیں جو اس کا مطالبہ کرتی ہے۔
تین راز، تین مالک
پہلے سے مشترکہ کلید ساتھی تعلق کی ہے اور دونوں سروں کا انتظام کرنے والا اسے ایک بار ترتیب دیتا ہے۔ صارف کی اسناد توثیق بیک اینڈ کی ہیں اور ہر لاگ ان پر جانچی جاتی ہیں۔ دوسرا عامل ٹوکن نظام کا ہے جس کا جواب ہر کوشش پر بدلتا ہے۔ کوئی دوسرے کا متبادل نہیں، اور تینوں کو ایک ہی پاس ورڈ سمجھنے والی تعیناتی اسی پرت پر ناکام ہوتی ہے جسے کسی نے دستاویز نہیں کیا۔
تین کالم لکھیں: مالک، مدت اور وہ ناکامی پیغام جو ہر ایک پیدا کرتا ہے۔ تشخیصی آلہ وہی جدول ہے، کلائنٹ کے خانے کے نام نہیں۔
| Layer | Owner | Lifetime |
|---|---|---|
| Pre-shared key | Peer configuration | Until operators change it |
| XAuth credential | Authentication backend | Per session, per policy |
| One-time code | Token system | Single use |
PSK: شخص کا نہیں، ساتھی کا
اس پرانی ترتیب میں پہلے سے مشترکہ کلید گیٹ وے جوڑے کی توثیق کرتی ہے، اس لیے صارف کا لاگ ان اسے کبھی بدلتا نہیں۔ یہ وہ قدر بھی ہے جو اکثر ایسے انداز میں غلط ہوتی ہے کہ پرامپٹ کے بجائے عام مذاکراتی خرابی پیدا کرتی ہے۔ جب سرنگ کسی صارف پرامپٹ سے پہلے ناکام ہو تو مشتبہ کلید یا تجاویز ہیں۔
صارف کی اسناد پہلے مرحلے کی ناکامی درست نہیں کر سکتیں۔ انہیں گھمانا واحد اسناد ضائع کرتا ہے جسے آپ محفوظ طور پر گھما سکتے ہیں اور غلط نظریے کو مضبوط کرتا ہے۔
XAuth: پرانی صارف منتقلی
XAuth IKEv1 کی ساتھی توثیق کے اوپر صارف توثیق کی منتقلی شامل کرتا ہے اور گیٹ وے طے کرتا ہے کہ کون سا بیک اینڈ اسے جانچتا ہے۔ اس بیک اینڈ کے مطابق منتقلی ڈائریکٹری پاس ورڈ، RADIUS اسناد یا ٹوکن جواب قبول کر سکتی ہے۔ XAuth لفظ منتقلی کی ترسیل کا نام دیتا ہے، اسناد کی قسم کا نہیں۔
دیکھیں کہ گیٹ وے پروفائل کس بیک اینڈ کی طرف اشارہ کرتا ہے۔ یہ بتاتا ہے کہ صارف سے کیا پوچھا جائے گا اور پاس ورڈ ری سیٹ اصل میں کیا بدلتا ہے، اور دونوں کلائنٹ پروفائل میں نظر نہیں آتے۔
OTP: بیک اینڈ جو مانگے
کچھ تعیناتیاں پاس ورڈ کے بعد الگ یکبارہ کوڈ مانگتی ہیں، جبکہ دیگر دستاویزی جدا کنندہ کے ساتھ مشترکہ ان پٹ شکل متعین کرتی ہیں۔ دونوں موجود ہیں، اور آپ کے سامنے کا پروفائل طے کرتا ہے کہ کون سی۔ کسی اور جگہ چلنے کی وجہ سے جوڑنے کا طریقہ ایجاد کرنا اندراج ٹوکن جلانے کا سب سے عام طریقہ ہے۔ یہ صرف گیٹ وے کی اپنی دستاویزات ہی طے کرتی ہیں۔
گیٹ وے کی پیش کردہ منتقلی مکمل کر سکنے والے کلائنٹ کے ساتھ دستاویزی شکل استعمال کریں۔
کلائنٹ کی حد کہاں کاٹتی ہے
Fortinet درج کرتا ہے کہ FortiClient 7.4.4 اور بعد کے ورژن IPsec VPN کے لیے IKEv1 کی حمایت نہیں کرتے، یہ FortiClient مطابقت نوٹ کے مطابق عالمی ہٹاؤ نہیں بلکہ مصنوعات اور ورژن کی حد ہے۔ دیگر کلائنٹ بھی باہم بدلے نہیں جا سکتے: OpenConnect اور openfortivpn مخصوص گیٹ وے پروٹوکول بولتے ہیں، کوئی بھی IKEv1 پروفائل نہیں۔ نصب کلائنٹ کا IKE ورژن، PSK موڈ، XAuth حمایت اور تعامل کا نمونہ الگ الگ جانچیں۔ مختلف طریقے سے جڑنے والا کلائنٹ اصل ضرورت ثابت نہیں کرتا۔
IKEv1 متروک ہے، اس لیے غیر تعاون یافتہ پرانے کلائنٹ پر بنی نئی تعیناتی قلیل مدتی حل ہے۔ گیٹ وے کے مالک سے تعاون یافتہ منتقلی راستہ مانگیں، بشمول یہ کہ وہاں دوسرے عامل کو کیسے سنبھالا جائے گا۔
عامل بند کیے بغیر تشخیص
لاگ میں مراحل الگ کریں: ساتھی مذاکرات، صارف منتقلی، دوسرے عامل کا نتیجہ، پھر پتہ اور راستہ تفویض۔ ہر خانے میں کوڈ آزمانے کے بجائے جزو اور مرحلہ درج کریں۔ ٹیسٹ پاس کرانے کے لیے عامل بند کرنا ایسی سرنگ بناتا ہے جو تعیناتی کے بارے میں کچھ ثابت نہیں کرتی۔
اندراج کے راز اور مشترکہ کلید تنظیم کے عمل کے مطابق محفوظ ذخیرے میں رکھیں۔ مستقل فائل میں یکبارہ کوڈ ایسا عامل ہے جو عامل رہنا چھوڑ چکا ہے۔