خطای 720 VPN در ویندوز: مجموعه آدرس یا اتصال کلاینت؟
خطای 720 یعنی اتصال هرگز آدرس قابل استفاده‌ای دریافت نکرد. پیش از نصب دوباره آداپتور، خرابی‌های یک میزبان را از خرابی‌های بسیاری از میزبان‌ها جدا کنید.
خطای 720 پس از پذیرش اعتبارنامه‌ها ظاهر می‌شود، و به همین دلیل افراد را به فیلد رمز عبور برمی‌گرداند. اتصال به نقطه‌ای رسید که در آن درباره یک آدرس مذاکره می‌شود و آدرسی دریافت نکرد. دو خرابی بسیار متفاوت همان کادر گفتگو را تولید می‌کنند: سرور چیزی برای توزیع نداشت، یا همین کلاینت نتوانست مذاکره را کامل کند. جدا کردن این دو پیش از دست زدن به هر چیزی بیشترین بخش تعمیر است، و این تفکیک در صفحه عیب‌یابی مایکروسافت درباره خطای 720 مستند شده است.
آنچه کادر گفتگو نمی‌گوید
پیام شکستی در مذاکره PPP را توصیف می‌کند و عمداً مبهم است، زیرا کلاینت نمی‌تواند ببیند چرا سرور رد کرده است. این خطای اعتبارنامه نیست و اظهارنظری درباره رمزگذاری تونل هم نیست. یعنی آدرس یا پارامترهای مذاکره تحویل داده نشدند.
در سمت سرور، علت معمول تخصیص است: مجموعه استاتیک RRAS بدون آدرس آزاد، یا پیکربندی DHCP که محدوده آن تمام شده یا در دسترس نیست، دقیقاً همین نشانه را در هر کلاینتی که تلاش کند تولید می‌کند. در سمت کلاینت، علت معمول اتصال است. WAN Miniport که PPP را حمل می‌کند باید به اجزای درست متصل باشد، و یک اتصال غیرفعال یا فیلتر شبکه واردشده می‌تواند مذاکره را بدون هیچ مشکل قابل مشاهده دستگاه متوقف کند. این دو خانواده به شواهد متفاوتی نیاز دارند، و سریع‌ترین راه انتخاب میان آن‌ها شمردن تعداد کلاینت‌های آسیب‌دیده است.
اول جمعیت را جدا کنید، سپس مجموعه را
پیش از خواندن هر پیکربندی، کلاینت‌های آسیب‌دیده را بشمارید. خرابی که همه را یک‌جا می‌زند وضعیت سرور است، و خرابی که یک ماشین را میان شبکه‌ها دنبال می‌کند وضعیت کلاینت است. این شمارش یک پیام در کانال گفتگو هزینه دارد و یک بعدازظهر را ذخیره می‌کند.
| 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فهرست را از نظر اتصال حل آدرس و فیلترهای شخص ثالث بخوانید. اتصال غیرفعال یک تعمیر هدفمند است، در حالی که وجود فیلتر پرسشی از صاحب آن نرم‌افزار است و نه اجازه غیرفعال کردن یک محصول امنیتی. حذف همه آداپتورها تنها اقدامی است که شواهد لازم را در صورت بازگشت خرابی نابود می‌کند.
پس از اصلاح، همان پروفایل را دوباره امتحان کنید و سپس اگر نشانه اصلی همان بود مورد دو کلاینت را تکرار کنید، زیرا اتصال موفق اول مشکل تخصیصی را پنهان می‌کند که کلاینت دوم آشکار می‌کند. یادداشت را در چهار فیلد نگه دارید: کدام کلاینت، کدام اتصال، کدام رویداد و چه چیزی تغییر کرد. در هر تلاش یک لایه را تغییر دهید، زیرا اصلاح کلاینت و تغییر مجموعه اگر با هم اعمال شوند قابل نسبت‌دادن نیستند، و خرابی بعدی همان است ولی جدید به نظر می‌رسد.