L2TP/IPsec خرابی 789، 720 یا 691: پہلے درست مرحلہ ٹھیک کریں

Windows 11 ہر L2TP/IPsec مرحلے کے لیے مختلف نمبر بتاتا ہے، اور یہ نمبر ناکامی کا اندازہ لگانے کے بجائے مرحلے کی نشاندہی کرتا ہے۔ 789 PPP لنک موجود ہونے سے پہلے ناکام ہوتا ہے، 720 لنک اٹھنے کے دوران ناکام ہوتا ہے، اور 691 لنک اٹھنے اور اسناد مسترد ہونے کے بعد ناکام ہوتا ہے۔ مفید فیصلہ یہ نہیں کہ کون سی درستی سب سے مقبول ہے؛ یہ ہے کہ کوڈ کس مرحلے تک پہنچنے کا ثبوت دیتا ہے۔ پہلے وہ پڑھیں، پھر ہر کوشش میں ایک تہہ بدلیں تاکہ اگلا کوڈ آپ کو کچھ اور بتا سکے۔

کوڈ کو مرحلے کے طور پر پڑھیں، خرابیوں کی فہرست کے طور پر نہیں

L2TP کنکشن مقررہ ترتیب میں تین حدود عبور کرتا ہے۔ IKE UDP 500 پر حفاظتی انجمنوں پر بات چیت کرتا ہے، NAT گزر گاہ اس ٹریفک کو UDP 4500 پر منتقل کرتی ہے، اور اس کے بعد ہی L2TP سرنگ وہ PPP سیشن لے کر چلتی ہے جو صارف کی تصدیق کرتا ہے اور پتہ تفویض کرتا ہے۔

یہی ترتیب بدلتے ہوئے خرابی کوڈ کو مفید ثبوت بناتی ہے۔ 789 سے 720 پر جانے کا مطلب ہے کہ IPsec اب بات چیت کر رہا ہے اور ناکامی لنک کے قیام کی طرف منتقل ہو گئی ہے۔ 720 سے 691 پر جانے کا مطلب ہے کہ لنک اٹھ گیا اور گیٹ وے نے شناخت مسترد کر دی۔ اگر آپ پانچ درستیاں ایک ساتھ لگائیں تو وہ اشارہ کھو دیتے ہیں اور نہیں بتا سکتے کہ کون سی تبدیلی کام کر گئی۔

789: راستے اور مقامی پالیسی کے درمیان انتخاب کریں

کوڈ 789 ابتدائی حفاظتی مذاکرات کے دوران پروسیسنگ کی خرابی ہے۔ IPsec نے کبھی قابل استعمال انجمن نہیں بنائی، اس لیے اکاؤنٹ ابھی آزمایا نہیں گیا۔ اکاؤنٹ سے نہیں، راستے اور مشترکہ کلید سے شروع کریں۔

تصدیق کریں کہ UDP 500 اور UDP 4500 سرور تک پہنچتے ہیں اور پہلے سے مشترکہ کلید بائٹ بائٹ میچ کرتی ہے، بشمول حروف کے بڑے چھوٹے ہونے اور آخر کے خالی مقامات کے۔ اگر سرور NAT کے پیچھے ہے تو Windows کو دستاویزی رجسٹری ویلیو بھی درکار ہو سکتی ہے۔ جب سرور NAT کے پیچھے ہو تو 1 اور جب دونوں سرے ایسے ہوں تو 2 استعمال کریں، پھر دوبارہ شروع کریں کیونکہ پالیسی ایجنٹ ویلیو کو آغاز پر پڑھتا ہے:

reg add "HKLM\SYSTEM\CurrentControlSet\Services\PolicyAgent" /v AssumeUDPEncapsulationContextOnSendRule /t REG_DWORD /d 1 /f

اڈاپٹر کی بھاری مرمت دوسری شاخ کی ہے۔ Wi-Fi ڈیوائس اور WAN منی پورٹ ہٹا کر پھر ہارڈویئر کے لیے دوبارہ اسکین کرنا تب جائز ہے جب مقامی IPsec اسٹیک خود خراب ہو اور دیگر VPN اقسام بھی اسی طرح ناکام ہوں۔ جب صرف ایک L2TP سرور ناکام ہو اور باقی تمام نیٹ ورک راستے کام کریں تو یہ بیکار کوشش ہے۔

720: اس اڈاپٹر اور سرور پول کے درمیان انتخاب کریں

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

فیصلے کے لیے اثر کا دائرہ استعمال کریں۔ ایک Windows مشین کا ناکام ہونا خراب WAN منی پورٹ، رکی ہوئی Remote Access سروس یا خراب کنکشن پروفائل کی طرف اشارہ کرتا ہے۔ کئی کلائنٹس کا بیک وقت ناکام ہونا سرور کی طرف اشارہ کرتا ہے: ختم شدہ پتہ پول، رکی ہوئی RRAS سروس یا ایسا پول جو اب کلائنٹ سب نیٹ سے میل نہیں کھاتا۔ دوسرا پہلو بدلنے سے پہلے اس پہلو کو درست کریں جس کی طرف نمونہ اشارہ کرتا ہے۔

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

691: اسناد اور رکے ہوئے مددگار کے درمیان انتخاب کریں

کوڈ 691 تصدیق کا انکار ہے، اور یہ وہ کوڈ ہے جسے سب سے زیادہ غلط پاس ورڈ کے طور پر غلط پڑھا جاتا ہے۔ سرنگ اوپر ہے، گیٹ وے نے شناخت دیکھی اور اسے مسترد کر دیا۔ وجہ اب بھی پاس ورڈ کے خانے سے باہر ہو سکتی ہے۔

پہلے ڈومین کا خانہ چیک کریں، پھر پاس ورڈ کے درست حروف۔ خالی جگہ، اقتباس یا شیل کا خاص حرف رکھنے والا پاس ورڈ سرور تک پہنچنے سے پہلے خراب ہو سکتا ہے؛ Linux پر، pppd اقتباس کے بغیر ویلیو یا غائب ڈومین کے لیے E=691 جیسا ہی انکار بتاتا ہے۔ راز کو چسپاں کرنے کے بجائے دوبارہ ٹائپ کریں، اور کوئی بھی محفوظ اسناد صاف کریں جن میں پرانی ویلیو ہو سکتی ہے۔

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

شاخیں الگ کرنے کے لیے، وہی صارف نام کسی دوسرے کام کرنے والے VPN پروفائل یا RADIUS ٹیسٹ اکاؤنٹ پر آزمائیں۔ اگر وہ کامیاب ہو تو اسناد ٹھیک ہیں اور مقامی کلائنٹ راستہ مشکوک ہے۔ اگر وہ اسی طرح ناکام ہو تو مسئلہ اکاؤنٹ یا گیٹ وے پالیسی ہے۔

ہر کوشش میں ایک تہہ بدلیں

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

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

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