خطای 868 با نشانی IP؟ ویندوز ابتدا چه چیزی را تفکیک می‌کند
پنجره می‌گوید جست‌وجو شکست خورده است، در حالی که نمایه عددی به نظر می‌رسد. فیلد واقعی نمایه را بخوانید، سپس مشکل نام را از یک باگ قدیمی اتصال دوباره جدا کنید.
پنجره گزارش می‌دهد که نام سرور قابل تفکیک نبود، و فیلد نمایه‌ای که به آن خیره شده‌اید یک نشانی است. این ترکیب تناقض نیست: کلاینت چیز دیگری جز مقداری که فکر می‌کنید می‌خواند را تفکیک می‌کند. پیش از آنکه نتیجه بگیرید DNS خراب است، مشخص کنید واقعاً به چه چیزی وصل می‌شود. ترتیب گام‌های خود کلاینت نشان می‌دهد کجا را باید بررسی کنید.
کلاینت پیش از شماره‌گیری، یک نام را تفکیک می‌کند
اتصال بومی VPN ویندوز نمایه خود را می‌خواند، نشانی سرور را تفکیک می‌کند، تونل را آغاز می‌کند و تنها پس از آن احراز هویت می‌کند. خطای 868 به گام دوم تعلق دارد. چون گام‌های بعدی هرگز اجرا نمی‌شوند، پنجره می‌تواند شبیه مشکل اعتبارنامه به نظر برسد، در حالی که جست‌وجو ابتدا شکست خورده است.
این ترتیب مفید است، زیرا لایه‌ای را که باید بررسی شود تنگ‌تر می‌کند. وقتی همان نمایه از یک شبکه کار می‌کند و از شبکه‌ای دیگر شکست می‌خورد، تفاوت معمولاً در تفکیک نام است، نه در نوع تونل یا حساب. جست‌وجو را در جایی آزمایش کنید که شکست رخ می‌دهد، نه جایی که نمایه ساخته شده است.
کدام نام، وقتی فیلد نشانی نشان می‌دهد
به‌جای نام نمایشی، مقدار ذخیره‌شده را بخوانید. برچسب اتصال، نشانی سرور آن نیست، و دو ورودی با برچسب‌های مشابه شما را دنبال ورودی اشتباه می‌فرستند:
Get-VpnConnection -Name "Work VPN" |
Select-Object Name, ServerAddress, TunnelTypeاگر نمایه برای همه کاربران ساخته شده است، آن دامنه را هم با این گزینه بپرسید: -AllUserConnection. سپس دقیقاً همان مقداری را که فرمان چاپ کرد، از شبکه‌ای که شکست در آن رخ می‌دهد تفکیک کنید. از دروازه‌ای که اپراتور مستند کرده است استفاده کنید، نه نام داخلی برنامه را که فقط پس از بالا آمدن تونل تفکیک می‌شود. آن پرس‌وجوی دوم به دلیلی قابل انتظار شکست می‌خورد و هیچ چیزی درباره اتصال به شما نمی‌گوید:
Resolve-DnsName vpn.example.comوقتی مقدار ذخیره‌شده واقعاً عددی است، دومین جایی را جست‌وجو کنید که کلاینت نامی می‌خواند. پیکربندی EAP می‌تواند به یک سرور ارجاع دهد، نمایه‌ای که از ابزار دیگری وارد شده می‌تواند مقدار خودش را داشته باشد، و نصب‌کننده قبلی می‌تواند یک ورودی تکراری باقی بگذارد. فیلد پنجره همیشه تنها ورودی نیست.
الگوی اتصال دوباره در ویندوز 7
رشته‌ای که پشت این خطا است ماشین‌هایی را توصیف می‌کند که یک بار متصل شدند و سپس در تلاشی بعدی با 868 شکست خوردند، بدون آنکه چیزی در نمایه تغییر کرده باشد. مشارکت‌کنندگان گزارش دادند که راه‌اندازی دوباره سرویس Remote Access Connection Manager یا خروج و ورود دوباره، اتصال را موقتاً بازمی‌گرداند. این‌ها راه‌حل‌های موقت‌اند، نه علت ریشه‌ای اثبات‌شده.
آن الگو را فرضیه‌ای جداگانه در نظر بگیرید. راه‌اندازی دوباره وضعیت کلاینت را بازنشانی می‌کند، پس موفقیت موقت پس از آن ثابت نمی‌کند که رکورد DNS اشتباه بوده است:
| Observation | Points toward | What to do next |
|---|---|---|
| Fails from one network, works from another | Name resolution on that path | Resolve the stored name from both networks |
| Fails after a disconnect, works after service restart | Client state, not DNS | Record the sequence for the vendor |
| Fails only on a newly provisioned machine | Profile content or scope | Compare ServerAddress and TunnelType |
جدول را مجموعه‌ای از مشاهدات متمایزکننده بخوانید، نه تشخیص. ردیف اول مشکل نام است، دومی وضعیت کلاینت، و سومی نمایه‌ای که هرگز درست نبوده است. هر یک به فردی متفاوت و اصلاحی متفاوت می‌رسد.
چه چیزی برای مدیر جمع‌آوری کنید
نام نمایه، نشانی ذخیره‌شده، نوع تونل، شبکه‌ای که کلاینت در آن بود، و اینکه آیا شکست پس از قطع اتصال رخ داده است را بنویسید. این ثبت، شکست واقعی جست‌وجو را از رفتار تاریخی اتصال دوباره جدا می‌کند بدون آنکه کسی نیاز به حدس زدن داشته باشد. گزارش رویداد کلاینت را هم در زمان تلاش نگه دارید.
راه‌حل موقت نسخه‌های قدیمی شواهدی است بر اینکه این رفتار وجود داشته، نه وعده‌ای بر اینکه همان راه‌اندازی دوباره سرویس یک ماشین امروزی را درست می‌کند. جایگزین کردن یک نام میزبان مستند با یک نشانی صریح هم تعمیر نیست.
برخی نمایه‌ها هویت سروری را انتظار دارند که با نام پیکربندی‌شده مطابقت داشته باشد، بنابراین یک راه‌حل عددی می‌تواند یک خطا را با خطای دیگر عوض کند. اگر نام باید بماند، مسیر تفکیک را درست کنید نه متن نمایه را. در هر حال، ثبت کنید چه چیزی را تغییر دادید و چرا.