IKEEXT سروس بند ہونے پر L2TP/IPsec ناکام ہوتا ہے

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

ناکامی کے پیچھے سروس

IKE and AuthIP IPsec Keying Modules، جو سروس فہرست میں IKEEXT کے نام سے دکھتی ہے، کلیدوں کا تبادلہ کرتی ہے اور ونڈوز میں UDP 500 اور 4500 ساکٹ رکھتی ہے۔ اسے بند کریں تو L2TP/IPsec اور IKEv2 دونوں اپنا گفت و شنید کرنے والا کھو دیتے ہیں، جبکہ PPTP اور SSTP کام جاری رکھ سکتے ہیں کیونکہ وہ اس پر منحصر نہیں۔ یہی تقسیم بتاتی ہے کہ صارف کیوں بتا سکتا ہے کہ ایک VPN قسم کام کرتی ہے اور دوسری اسی مشین پر مردہ ہے۔ سروس آپریٹنگ سسٹم کا حصہ ہے، اس لیے کوئی پروفائل ترتیب اس کا متبادل نہیں بن سکتی۔

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

سروس کو بغیر اندازے کے واپس رکھیں

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

sc qc ikeext
sc query ikeext

اسٹارٹ اپ کی قسم Disabled پوری علامت کی وضاحت کرتی ہے، اور حل یہ ہے کہ اسے واپس Automatic پر رکھیں اور سروس شروع کریں۔ Services کنسول میں اندراج اپنے ڈسپلے نام، IKE and AuthIP IPsec Keying Modules، کے ساتھ دکھائی دیتا ہے، اس لیے اس فہرست میں IKEEXT تلاش کرنے سے کچھ نہیں ملتا۔ اگر سروس صرف اس وقت شروع ہوئی جب ناکام کنکشن پہلے ہی چل چکا تھا تو دوبارہ شروع کریں، کیونکہ اس ترتیب سے شروع کیا گیا اسٹیک ایسے طریقوں سے ناکام ہو سکتا ہے جو غیر متعلق نظر آئیں۔

sc config ikeext start= auto
net start ikeext

اسے دوبارہ کیا بند کرتا ہے

کچھ تھرڈ پارٹی VPN سوئٹ اپنی IPsec عمل درآمد لاتے ہیں اور تنصیب کے دوران IKEEXT بند کر دیتے ہیں، جس کے بعد ونڈوز کلائنٹ کام کرنا چھوڑ دیتا ہے۔ دوسری مصنوعات ہٹانے نے ان مشینوں پر L2TP/IPsec بحال کیا جہاں پروفائل ترامیم سے کچھ حاصل نہیں ہوتا تھا، اور متضاد جزو کے بغیر دوبارہ تنصیب نے بھی یہی کیا۔ سروس تنصیب کے وقت بند کی گئی تھی، صارف نے اسے تبدیل نہیں کیا۔

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

پہلے مرحلہ پڑھیں، پھر لاگ

جب سروس چل رہی ہو، ناکامی کا مرحلہ طے کرتا ہے کہ آگے کہاں دیکھنا ہے۔ IKE کے دوران رکنا عام طور پر یعنی UDP 500 یا 4500 کبھی سرور تک نہیں پہنچا، یا سرور متعلقہ انکیپسولیشن ترتیب کے بغیر NAT کے پیچھے ہے۔ اسناد کے پرامپٹ تک پہنچنا اور وہاں ناکام ہونا PPP توثیق کا مسئلہ ہے، IPsec کا نہیں۔ ایسا ٹنل جو اوپر آئے اور کہیں نہ پہنچے روٹنگ یا منقسم ٹنل کی خرابی ہے، اور ان تینوں میں سے صرف پہلا VPN پروفائل میں ہوتا ہے۔

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

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

مقامی مرمت کیا ثابت نہیں کر سکتی

سروس بحال کرنا راستے کا وہ نصف ٹھیک کرتا ہے جو لیپ ٹاپ پر ہے۔ کام کرتی سروس صرف مقامی نصف ثابت کرتی ہے: دور کا سرا اب بھی منتخب تجویز، فراہم کردہ اسناد اور وہ ماخذ پتہ قبول کرے گا جہاں سے پیکٹ آتا ہے۔ لیپ ٹاپ پر کیا گیا کچھ بھی ایسی فائر وال کی تلافی نہیں کرتا جو UDP 500 کو ساتھی تک پہنچنے سے پہلے پھینک دیتی ہے۔ کامیاب سروس حالت ایک پیشگی شرط ہے، ٹنل کے اوپر آنے کا ثبوت نہیں۔

پورٹس آزاد کرنے کے لیے IKEEXT بند کرنا صرف اس صورت میں جائز ہے جب آپ تسلیم کریں کہ ونڈوز کے IPsec VPN بند ہو جائیں گے۔ یہ پورٹ کے متضاد مسئلے کو اس خصوصیت کو ہٹا کر حل کرتا ہے جسے پورٹ درکار تھا، اور یہ شاذ و نادر ہی وہ تبادلہ ہے جو صارف کا مقصود تھا۔ کچھ بدلنے سے پہلے تصدیق کریں کہ سروس موجود ہے، Automatic پر مقرر ہے اور چل رہی ہے، دوسرا IPsec اسٹیک نصب نہیں، اور پہلے سے مشترکہ کلید یا سرٹیفکیٹ زنجیر گیٹ وے سے مطابقت رکھتی ہے۔

• IKEEXT موجود ہے، Automatic پر مقرر ہے اور کلائنٹ کے جڑنے سے پہلے چل رہی ہے۔
• کوئی اور چیز UDP 500 یا 4500 کو نہیں روکتی۔
• پرانے کلائنٹ سے دوسرا IPsec اسٹیک باقی نہیں رہتا۔
• کلید یا سرٹیفکیٹ زنجیر گیٹ وے کی ترتیب سے مطابقت رکھتی ہے۔
• ناکام مرحلہ پروفائل میں ترمیم سے پہلے درج کیا گیا۔