اینڈرائیڈ گھر کے IPsec VPN سے کیوں جڑتا ہے اور ونڈوز کیوں نہیں

فون بغیر کسی شکایت کے روٹر کے VPN میں شامل ہو جاتا ہے جبکہ اسی Wi-Fi پر موجود لیپ ٹاپ ایسا نہیں کر پاتا۔ وہی اسناد، وہی سرور، وہی منٹ۔ فرق پاس ورڈ کا نہیں بلکہ پروٹوکول کی سپورٹ کا ہے: روٹر ایسا پروفائل دکھاتا ہے جو ایک آپریٹنگ سسٹم نافذ کرتا ہے اور دوسرے نے کبھی نہیں کیا۔

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

ایک مینو، تین پروٹوکول

ایک ہی IPsec عنوان کے نیچے، صارفی فرم ویئر تین کافی مختلف سرنگیں چھپا سکتا ہے۔ پہلی XAUTH کے ساتھ IKEv1 ہے: مشترکہ گروپ راز، پھر اس کے اوپر صارف نام اور پاس ورڈ۔ دوسری L2TP/IPsec ہے، جہاں PPP مشترکہ کلید سے محفوظ IPsec ٹرانسپورٹ کے اندر چلتا ہے۔ تیسری IKEv2 ہے، جو سرٹیفکیٹ یا EAP سے تصدیق شدہ ہوتا ہے۔

لیبل نہیں، فیلڈز پڑھیں۔ گروپ راز اور صارف فہرست کا مطلب IKEv1 XAUTH ہے۔ مشترکہ کلید اور PPP اکاؤنٹ کا مطلب L2TP/IPsec ہے۔ گروپ راز کے بغیر سرور سرٹیفکیٹ کا مطلب IKEv2 ہے۔

فون اور لیپ ٹاپ کے درمیان سپورٹ کا خلا

اینڈرائیڈ کے اندر IKEv1 XAUTH PSK کلائنٹ موجود ہوتا ہے، اور یہی وجہ ہے کہ فون ایسے روٹر کے ساتھ کامیاب ہوتا ہے جو اور کچھ پیش نہیں کرتا۔ ونڈوز میں ایسا نہیں: اس کا مقامی کلائنٹ L2TP/IPsec اور IKEv2 سنبھالتا ہے، اور چالو کرنے کے لیے IKEv1 XAUTH کا کوئی آپشن نہیں۔ راز دوبارہ درج کرنے سے مدد نہیں مل سکتی، کیونکہ کمیاب چیز پروٹوکول ہے، اسناد نہیں۔

ایپل کا پہلو چلتا ہوا ہدف ہے۔ نئے macOS اور iOS ریلیز IKEv2 کی طرف جاتے ہیں، پرانے سسکو طرز کے پروفائل کچھ بلڈز میں زندہ رہتے ہیں، اور اپ گریڈ گزشتہ ماہ کام کرنے والی چیز کو ہٹا یا سخت کر سکتا ہے۔ کل جڑنے والا اور آج نہ جڑنے والا Mac، روٹر میں بغیر کسی تبدیلی کے، عام طور پر یہی معاملہ ہے۔

دو سیٹنگز جو بصورت دیگر درست پروفائل توڑ دیتی ہیں

Synology کا L2TP/IPsec صفحہ Enable SHA2-256 compatible mode (96 bit) کے لیبل والا چیک باکس پیش کرتا ہے۔ iOS 14 اور macOS Big Sur سے آگے ایپل کلائنٹس اس کٹے ہوئے موڈ کو مسترد کرتے ہیں، اس لیے ان کے لیے یہ خانہ ہٹانا پڑتا ہے۔ اگر یہ آن رہے تو سرنگ تصدیق کرتی ہے اور پھر گر جاتی ہے، جو خراب اسناد جیسا لگتا ہے مگر ایسا نہیں۔ بنانے والا اس ٹوگل کو دستاویز کرتا ہے، اور عام طور پر جب یہ اہم ہونے لگتا ہے وہ آپریٹنگ سسٹم کی اپ گریڈ ہے۔

ونڈوز سرٹیفکیٹ دو الگ اسٹورز میں رکھتا ہے، اور IKEv2 صرف مشین والا پڑھتا ہے۔ کلائنٹ سرٹیفکیٹ کو اس کی نجی کلید کے ساتھ کمپیوٹر اکاؤنٹ میں درآمد کریں؛ آپ کے صارف اکاؤنٹ کے تحت رکھا سرٹیفکیٹ مینجمنٹ کنسول میں دکھائی دیتا ہے اور کبھی IKEv2 سروس تک نہیں پہنچتا۔ EAP-TLS واحد موقع ہے جہاں صارف سرٹیفکیٹ قابل استعمال ہوتا ہے، اور دستخط کرنے والے CA پر مشین کو پھر بھی بھروسہ کرنا ہوگا۔ یہاں غلطی تصدیق کی ناکامی کے طور پر ظاہر ہوتی ہے، غائب سرٹیفکیٹ کی درخواست کے طور پر نہیں۔

جب روٹر ویسا ہی رہے

جو روٹر صرف XAUTH PSK بولتا ہے وہ آگے تین راستے چھوڑتا ہے: بنانے والے کا کلائنٹ، ایک تیسرے فریق کا کلائنٹ جو اب بھی یہ پروفائل نافذ کرتا ہے، یا سرنگ کے سرے کو کسی ایسی چیز پر منتقل کرنا جو IKEv2 بولتی ہو۔ مثلاً AVM اپنے روٹرز کے لیے ونڈوز کلائنٹ سافٹ ویئر اور ایک برآمد شدہ کنفیگریشن فائل شائع کرتا ہے۔ وہ راستہ معاون ہے، اور اس کا مطلب ہر لیپ ٹاپ پر بنانے والے کا ٹول نصب کرنا ہے۔

جب لیپ ٹاپ آپ کے نہ ہوں کہ دوبارہ بنائیں، تو سپورٹ خوب صورتی سے زیادہ اہم ہے۔

سلامتی کی قیمت بھی تولیں۔ ایک گروپ راز ہر صارف کو ڈھانپتا ہے، لہٰذا جو اسے رکھتا ہے وہ سرور کی جگہ لے سکتا ہے اور وہ صارف نام اور پاس ورڈ پکڑ سکتا ہے جو کلائنٹ پیش کرتا ہے۔ جہاں سرٹیفکیٹ والا IKEv2 دستیاب ہو، وہ منتقلی کسی بھی کلائنٹ حل سے زیادہ قیمتی ہے۔

باہر سے اندر تک تشخیص کریں

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

کام کرنے والے فون پروفائل کو کنٹرول کے طور پر رکھیں۔ جب فرم ویئر اپ ڈیٹ کے بعد صرف لیپ ٹاپ خراب ہو تو سرور کا پہلو پہلے کی طرح برتاؤ کر رہا ہے۔ جب دونوں خراب ہوں تو کسی بھی کلائنٹ کو چھونے سے پہلے سرٹیفکیٹ یا سننے والے پورٹ کو دیکھیں۔