IP پتے کے ساتھ خرابی 868؟ Windows پہلے کیا حل کرتا ہے

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

کلائنٹ رابطہ کرنے سے پہلے نام حل کرتا ہے

Windows کا مقامی VPN کنکشن اپنا پروفائل پڑھتا ہے، سرور کا پتہ حل کرتا ہے، ٹنل شروع کرتا ہے اور اس کے بعد ہی توثیق کرتا ہے۔ خرابی 868 دوسرے مرحلے کی ہے۔ چونکہ بعد کے مراحل کبھی نہیں چلتے، تلاش پہلے ناکام ہونے پر ڈائیلوگ اسناد کے مسئلے جیسا لگ سکتا ہے۔

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

کون سا نام، جب فیلڈ پتہ دکھاتی ہے

دکھائے گئے نام کی بجائے محفوظ قدر پڑھیں۔ کنکشن کا لیبل اس کا سرور پتہ نہیں، اور ملتے جلتے لیبل والی دو اندراجیں آپ کو غلط کے پیچھے بھیجتی ہیں:

Get-VpnConnection -Name "Work VPN" |
    Select-Object Name, ServerAddress, TunnelType

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

Resolve-DnsName vpn.example.com

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

Windows 7 دوبارہ منسلک ہونے کا نمونہ

اس خرابی کے پیچھے کا دھاگہ ایسی مشینوں کی وضاحت کرتا ہے جو ایک بار جڑیں اور پھر بعد کی کوشش میں 868 کے ساتھ ناکام ہوئیں، جبکہ پروفائل میں کچھ نہیں بدلا۔ شرکا نے بتایا کہ Remote Access Connection Manager سروس دوبارہ شروع کرنے یا سائن آؤٹ کر کے دوبارہ سائن ان کرنے سے کنکشن عارضی طور پر بحال ہوا۔ یہ متبادل راستے ہیں، ثابت شدہ بنیادی وجہ نہیں۔

اس نمونے کو الگ مفروضہ سمجھیں۔ دوبارہ شروع کرنا کلائنٹ کی حالت ری سیٹ کرتا ہے، اس لیے بعد کی عارضی کامیابی یہ ثابت نہیں کرتی کہ DNS ریکارڈ غلط تھا:

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

منتظم کے لیے کیا جمع کرنا ہے

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

پرانی بلڈز کا متبادل راستہ اس بات کا ثبوت ہے کہ رویہ موجود تھا، یہ وعدہ نہیں کہ وہی سروس دوبارہ شروع کرنا موجودہ مشین ٹھیک کر دے گا۔ دستاویزی ہوسٹ نام کو لفظی پتے سے بدلنا بھی مرمت نہیں۔

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