جب آپ پورٹل کا URL چسپاں کرتے ہیں تو openfortivpn لاگ ان کیوں ناکام ہوتا ہے

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

https://vpn.example.com/ext جیسا Fortinet پورٹل پتہ ایک ساتھ معلومات کے کئی ٹکڑے رکھتا ہے، اور ان میں سے صرف کچھ ہی VPN کلائنٹ کے ہیں۔

اینڈ پوائنٹ اور realm الگ الگ ان پٹ ہیں

openfortivpn host یا host:port کی صورت میں اینڈ پوائنٹ، نیز اکاؤنٹ اور، جہاں تعیناتی ایک استعمال کرتی ہے، realm کی قدر کا انتظار کرتا ہے۔ realm اکاؤنٹ کا جائزہ لینے سے پہلے گیٹ وے کو بتاتا ہے کہ کون سی تصدیق کی پالیسی لاگو کرنی ہے۔ یہ الگ فیلڈ ہے، کوئی لاحقہ نہیں جسے کلائنٹ URL سے نکالتا ہے۔

جس تعیناتی کا آپریٹر تصدیق کرتا ہے کہ realm ext ہے، اس کے لیے غیر خفیہ کال ایسے دکھتی ہے: openfortivpn vpn.example.com:443 --username=alice --realm=ext۔ وہی قدریں کنفیگریشن فائل میں host، port، username اور realm اندراجات کے طور پر جاتی ہیں۔ پاس ورڈ دونوں صورتوں سے باہر رکھیں اور کلائنٹ کو پوچھنے دیں، تاکہ وہ شیل کی تاریخ یا سب کے پڑھنے کے قابل فائل میں نہ پہنچے۔ پہلا کلائنٹ ابھی ٹنل تھامے ہونے کے دوران دوسری کوشش ایسی وجہ سے ناکام ہوگی جس کا realm سے کوئی تعلق نہیں۔

openfortivpn کا دستی دونوں آپشنز کی فہرست دیتا ہے، اس لیے معاونت کو فون کرنے سے پہلے درست ہجے کی تصدیق آسان ہے۔ تاہم یہ نہیں بتا سکتا کہ آپ کے گیٹ وے پر کون سا realm کنفیگر ہے۔

راستے کا حصہ خودبخود realm نہیں ہوتا

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

realm صارف نام پر ڈومین لاحقہ یا وہ خطہ جہاں گیٹ وے موجود ہے، وہ بھی نہیں ہے۔ کچھ تعیناتیاں alice چاہتی ہیں، کچھ alice@corp چاہتی ہیں، اور گیٹ وے ان میں سے کون سی قبول کرے گا یہ realm طے کرتا ہے۔ غلط realm کی تلافی کے لیے اکاؤنٹ کی شکل بدلنے سے عام طور پر دوسرا، کم معلوماتی انکار آتا ہے۔

ہوسٹ بدل کر realm کی غلطی درست نہ کریں

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

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

مسترد شدہ لاگ ان کو ناکام ٹنل سے الگ کریں

تصدیق کی ناکامیاں اور ٹنل کی ناکامیاں مختلف لمحات میں آتی ہیں، اور پیغامات مختلف ہوتے ہیں۔ نام حل کرنے کی غلطی کسی بھی TLS مصافحے سے پہلے ہوتی ہے۔ TLS کا انکار اسناد بھیجنے سے پہلے ہوتا ہے۔ realm یا اکاؤنٹ کا انکار پورٹل سے HTTP سطح کے جواب کے طور پر واپس آتا ہے۔ ان مراحل کے بعد ہی PPP گفت و شنید شروع ہوتی ہے، اور تب ہی راستہ بندی اور DNS کے مسائل ظاہر ہوتے ہیں۔

درست realm گمشدہ راستہ نہیں بناتا، اور غیر معاون سائن اِن طریقہ کو کام نہیں کرتا۔ اگر پورٹل براؤزر پر مبنی بہاؤ پر اصرار کرتا ہے تو اس بہاؤ کے لیے کلائنٹ کے معاون راستے کو استعمال کریں، بجائے اس کے کہ پاس ورڈ کے تبادلے کو دہرائیں اور امید کریں کہ سیشن مطابقت رکھے گا۔

قدریں وہاں رکھیں جہاں اگلی شروعات انہیں پائے گی

کسی کنکشن کی کامیابی پر، شیل عرف کے بجائے گیٹ وے، پورٹ، اکاؤنٹ اور realm کو زیرِ انتظام پروفائل میں لکھیں۔ ذخیرے یا کنفیگریشن مدیریت کے نظام میں رکھے گئے پروفائل اگلی شروعات کو خاموشی سے کسی دوسرے پروفائل کا realm لینے سے روکتے ہیں۔

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