Windows میں VPN کی خرابی 720: پتوں کا ذخیرہ یا کلائنٹ کا بندھن؟
خرابی 720 کا مطلب ہے کہ کنکشن کو کبھی قابل استعمال پتہ نہیں ملا۔ کسی ایک میزبان کی خرابیوں کو بہت سے میزبانوں کی خرابیوں سے الگ کریں، اس سے پہلے کہ ایڈاپٹر دوبارہ انسٹال کریں۔
خرابی 720 اسناد قبول ہونے کے بعد ظاہر ہوتی ہے، اسی لیے لوگوں کو پاس ورڈ کے خانے میں واپس بھیجتی ہے۔ کنکشن اس مقام تک پہنچا جہاں پتے پر بات چیت ہوتی ہے اور اسے کوئی پتہ نہ ملا۔ دو بالکل مختلف خرابیاں وہی ڈائیلاگ بناتی ہیں: سرور کے پاس تقسیم کرنے کو کچھ نہیں تھا، یا یہی کلائنٹ بات چیت مکمل نہ کر سکا۔ کسی چیز کو چھونے سے پہلے ان دونوں کو الگ کرنا مرمت کا بڑا حصہ ہے، اور یہ فرق Microsoft کے خرابی 720 کے حل کے صفحے پر درج ہے۔
ڈائیلاگ کیا نہیں بتاتا
پیغام PPP بات چیت میں ناکامی بیان کرتا ہے، اور یہ جان بوجھ کر مبہم ہے کیونکہ کلائنٹ نہیں دیکھ سکتا کہ سرور نے کیوں انکار کیا۔ یہ اسناد کی خرابی نہیں ہے اور نہ ٹنل کی خفیہ کاری کے بارے میں کوئی بیان ہے۔ اس کا مطلب ہے کہ پتہ یا بات چیت کے پیرامیٹرز پہنچائے نہیں گئے۔
سرور کی طرف عام وجہ تقسیم ہے: بغیر خالی پتوں والا جامد RRAS ذخیرہ، یا DHCP ترتیب جس کی حد ختم ہو چکی ہو یا ناقابل رسائی ہو، ہر کوشش کرنے والے کلائنٹ میں یہی علامت پیدا کرتی ہے۔ کلائنٹ کی طرف عام وجہ بندھن ہے۔ PPP اٹھانے والے WAN Miniport کو درست اجزا سے باندھنا ضروری ہے، اور غیر فعال بندھن یا داخل شدہ نیٹ ورک فلٹر کسی نظر آنے والی ڈیوائس خرابی کے بغیر بات چیت روک سکتا ہے۔ دونوں خاندانوں کو مختلف ثبوت درکار ہیں، اور ان کے درمیان انتخاب کا تیز ترین طریقہ یہ گننا ہے کہ کتنے کلائنٹ متاثر ہیں۔
پہلے آبادی کو الگ کریں، پھر ذخیرے کو
کوئی بھی ترتیب پڑھنے سے پہلے متاثرہ کلائنٹ گنیں۔ وہ خرابی جو سب کو ایک ساتھ لگے سرور کی حالت ہے، اور وہ خرابی جو ایک مشین کا تعاقب نیٹ ورکس کے درمیان کرے کلائنٹ کی حالت ہے۔ یہ گنتی چیٹ چینل میں ایک پیغام کی قیمت پر ہوتی ہے اور ایک دوپہر بچاتی ہے۔
| Artifact | How you get it | What it rules out | What it cannot rule out |
|---|---|---|---|
| Affected-client count | One message to the people who failed, or a search of today's tickets | A client-only fault, when every client failed within minutes | Which server-side component stopped allocating |
| RRAS event for one attempt | Get-WinEvent on the System log, filtered to the allocation event id | An allocation failure, when no event matches that attempt | A binding fault that appears later in the same negotiation |
| Hidden WAN Miniport bindings | Get-NetAdapter with hidden adapters, then the binding list on the returned name | A disabled ms_wanarp binding or an inserted filter on this client | Pool exhaustion that would also have hit other clients |
| Free-address count | The RRAS pool view, or the DHCP scope statistics | A committed static range or an exhausted scope | Why the address was not delivered to one specific client |
پھر ایک ناکام کوشش کو سرور کے اپنے ریکارڈ سے منسلک کریں، کیونکہ RRAS اس وقت واقعہ درج کرتا ہے جب وہ تقسیم نہ کر سکے اور وہ واقعہ علامت کے بجائے خرابی کا نام لیتا ہے۔ اگر خرابی کسی مخصوص کلائنٹ کے ساتھ ہو، تو سرور کا لاگ اس کوشش کے لیے کچھ نہیں دکھائے گا، جو بذات خود معلوماتی ہے۔ تقسیم کی خرابی کا نہ ہونا مسئلے کو اسی کلائنٹ کی بات چیت تک محدود کرتا ہے اور بتاتا ہے کہ آگے کون سے کمانڈ چلائیں۔
Get-WinEvent -LogName System -MaxEvents 500 | Where-Object { $_.Id -eq 20167 }
Get-NetAdapter -IncludeHidden | Where-Object { $_.InterfaceDescription -like "WAN Miniport*" }سرور کی تقسیم کی حالت پڑھیں
RRAS کی طرف تصدیق کریں کہ کون سا طریقہ تقسیم واقعی ترتیب دیا گیا ہے، نہ کہ وہ جسے دستاویزات فرض کرتی ہیں۔ جامد ذخیرہ اور DHCP کے ذریعے بھیجی گئی ترتیب مختلف طریقوں سے ناکام ہوتی ہیں، اور اصلاح اسی کی ہے جو استعمال میں ہو۔ جامد ذخیرے میں خالی پتے گنیں اور فی صارف تقسیم تلاش کریں جو ایسی لیز رکھتی ہیں جسے کسی کو یاد نہیں کہ کب دی گئی، کیونکہ بڑا دکھنے والا ذخیرہ پوری طرح بھرا ہو سکتا ہے۔ DHCP میں جانچیں کہ ریلے سرور تک پہنچتا ہے اور حد میں خالی لیز ہیں۔
عام کلائنٹس سے ختم شدہ حد وہی 720 پیدا کرتی ہے جو غلط ترتیب شدہ ذخیرہ پیدا کرتا ہے، اور RRAS کنسول دونوں صورتوں میں بالکل صحت مند دکھے گا۔ ذخیرے کو چھوٹی حدود میں تقسیم کرنے کے وراثتی حل کی مزاحمت کریں: اصل مشورہ ایک منتظم کے نتیجے کا بیان تھا، اور یہ ایسی تقسیم خرابی کو درست نہیں کرتا جسے سرور کے اپنے واقعات براہ راست نام دے سکتے ہیں۔
کلائنٹ کے بندھنوں کو توڑے بغیر پڑھیں
اگر ثبوت کسی ایک کلائنٹ کی طرف اشارہ کریں، اسٹیک دوبارہ انسٹال کرنے کے بجائے پوشیدہ ایڈاپٹر کا معائنہ کریں۔ پہلا کمانڈ WAN Miniport انٹرفیس اور ان کے نام گنواتا ہے؛ دوسرا وہ نام لیتا ہے جو اس نے واپس کیا، نہ کہ کسی رہنما سے نقل کیا گیا نام۔
Get-NetAdapterBinding -Name "<name>" -IncludeHidden -AllBindingsفہرست کو پتے کے حل کے بندھن اور تیسرے فریق کے فلٹرز کے لیے پڑھیں۔ غیر فعال بندھن ایک نشانہ شدہ مرمت ہے، جبکہ فلٹر کی موجودگی اس سافٹ ویئر کے مالک سے سوال ہے نہ کہ سلامتی مصنوعات کو غیر فعال کرنے کی اجازت۔ تمام ایڈاپٹر حذف کرنا واحد اقدام ہے جو وہ ثبوت تباہ کرتا ہے جو خرابی کے لوٹنے پر آپ کو درکار ہوں گے۔
اصلاح کے بعد وہی پروفائل دوبارہ آزمائیں اور پھر دو کلائنٹ والا معاملہ دہرائیں اگر اصل علامت وہی تھی، کیونکہ کامیاب پہلا کنکشن وہ تقسیم مسئلہ چھپا دیتا ہے جو دوسرا کلائنٹ بے نقاب کرتا ہے۔ نوٹ کو چار خانوں میں رکھیں: کون سا کلائنٹ، کون سا بندھن، کون سا واقعہ اور کیا بدلا۔ ہر کوشش میں ایک تہہ تبدیل کریں، کیونکہ کلائنٹ کی اصلاح اور ذخیرے کی تبدیلی ایک ساتھ لاگو ہوں تو انہیں منسوب نہیں کیا جا سکتا، اور اگلی خرابی وہی ہونے کے باوجود نئی لگے گی۔