رفع خطای AnyConnect در مقدار‌دهی اولیه زیرسیستم اتصال

روی اتصال کلیک می‌کنید و کادر گفتگو تقریباً فوراً پاسخ می‌دهد: مقدار‌دهی اولیه زیرسیستم اتصال ناموفق بود. هیچ چیز به دروازه نرسید، پس نه تبادل گواهی هست، نه اعتبارنامه، و نه انتخاب گروه تونل در طرف دیگر. این یعنی گزارش‌های متمرکزکننده یک نشست خالی نشان می‌دهند و میز پشتیبانی اسکرین‌شاتی از کادری می‌خواهد که هرگز چیز مفیدی نداشته است. در عوض روی نقطه پایانی و به ترتیب ثابت کار کنید و در نخستین گامی که نتیجه را تغییر می‌دهد بایستید.

زمان ارزشمندترین شواهدی است که دارید و ثبت آن هیچ هزینه‌ای ندارد. بنویسید که خطا پیش از درخواست اعتبارنامه یا پس از آن ظاهر شد و آیا پس از یک ارتقا، به‌روزرسانی Windows یا عامل امنیتی جدید شروع شد. این سه پاسخ معمولاً فهرست کاندیدها را پیش از آنکه به تنظیمی دست بزنید نصف می‌کند.

پیش از تغییر هر چیز، زمان را بخوانید

سه نقطه خرابی شبیه هم به نظر می‌رسند و یکی نیستند. اگر کادر همان لحظه‌ای که اتصال را می‌زنید ظاهر شود، کلاینت نتوانسته زیرساخت خودش را راه بیندازد و این پیام به همین اشاره دارد. اگر پس از وارد کردن اعتبارنامه ظاهر شود، گروه تونل پیدا شده و مشکل جلوتر است. اگر تونل بالا بیاید و بعد بیفتد، زیرسیستم درست مقدار‌دهی شده و شما دنبال باگ کاملاً دیگری می‌گردید. اشتباه گرفتن این سه، یک بعدازظهر را صرف نصب‌های مجددی می‌کند که کمکی نمی‌کنند.

فقط حالت اول به اینجا مربوط است. پیام پیش از هر تصمیم شبکه‌ای تولید می‌شود، پس نشانی دروازه اشتباه، گواهی منقضی یا گذرواژه بد آن را تولید نمی‌کند.

گام 1: تأیید کنید که سرویس عامل در حال اجراست

پنجره‌ای که روی آن کلیک می‌کنید یک رابط جلویی است؛ کار در سرویس Cisco AnyConnect Secure Mobility Agent انجام می‌شود که با نام vpnagent ثبت شده است. اگر آن سرویس متوقف یا غیرفعال باشد، رابط گرافیکی کسی را برای صحبت ندارد و دقیقاً همین خطای مقدار‌دهی اولیه را گزارش می‌دهد. وضعیت و نوع راه‌اندازی را از یک خط فرمان PowerShell با دسترسی بالا بررسی کنید:

Get-Service vpnagent | Select-Object Name, Status, StartType
sc.exe qc vpnagent
net start vpnagent

نصب‌کننده‌ای که نوع راه‌اندازی دستی قبلی را رعایت کرده، دلیل معمول غیرفعال ماندن آن است، پس به‌جای فقط زدن Start، StartType را بررسی کنید. اگر سرویس ظرف چند ثانیه شروع و متوقف شود، پیش از کلیک روی Repair، گزارش System را برای ورودی‌های Service Control Manager بخوانید:

Get-WinEvent -FilterHashtable @{LogName="System"; ProviderName="Service Control Manager"} -MaxEvents 40

درایور مسدود، فایل قرنطینه‌شده یا درایور فیلتری از یک محصول امنیتی شخص ثالث در آن رویدادها خودش را نام می‌برد. Repair روی همان فایل مسدود دوباره نصب می‌کند و چیزی را تغییر نمی‌دهد، به همین دلیل گزارش رویدادها اول می‌آید.

گام 2: وضعیت آفلاینی را که پشته HTTP گزارش می‌کند پاک کنید

کلاینت نمایه خود را دانلود می‌کند و سیاست را از طریق اجزای HTTP ویندوز ارزیابی می‌کند، بنابراین پرچم آفلاینی که در تنظیمات اینترنت کاربر تنظیم شده می‌تواند مقدار‌دهی اولیه را بشکند در حالی که هر مرورگری هنوز صفحه‌ها را بار می‌کند. مقدار را مستقیم بررسی کنید:

Get-ItemProperty "HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings" -Name GlobalUserOffline

مقدار 1 یعنی پشته WinINet به فراخوان‌ها می‌گوید دستگاه اتصالی ندارد؛ این وضعیت معمولاً با گزینه منوی Work Offline در Internet Explorer یا با یک اسکریپت خودکارسازی تنظیم می‌شود. آن را به 0 برگردانید، خارج و دوباره وارد شوید و پیش از تغییر هر چیز دیگری اتصال را دوباره امتحان کنید.

اگر این دستگاه را به ارث برده‌اید و نمی‌دانید چرا پرچم تنظیم شده، آن را در تیکت یادداشت کنید. چیز دیگری روی دستگاه ممکن است عمداً آن را تنظیم کرده باشد و در ورود بعدی برمی‌گردد.

گام 3: آداپتور مجازی را از Hyper-V یا ICS آزاد کنید

دو نقش ویندوز می‌توانند قطعاتی را که کلاینت برای ساخت آداپتورش لازم دارد نگه دارند. Hyper-V اولی است: وقتی سرویس‌های سوئیچ مجازی در حال اجرا هستند، ساخت آداپتور می‌تواند به شکل‌هایی شکست بخورد که به‌صورت این خطا ظاهر می‌شوند. توقف سرویس‌ها یک تشخیص است، نه یک رفع:

Get-Service vmms, vmcompute | Stop-Service
Get-NetAdapter | Where-Object InterfaceDescription -like "*Hyper-V*"

اگر کلاینت با سرویس‌های متوقف‌شده وصل شود، تضاد تأیید می‌شود و اکنون می‌دانید با مالک میزبان Hyper-V بر سر چه چیزی مذاکره کنید. بعد از آن دوباره راه‌اندازی‌شان کنید مگر اینکه دستگاه دیگر به مجازی‌سازی نیاز نداشته باشد.

اشتراک‌گذاری اتصال اینترنت مالک دوم است. اگر اتصالی به اشتراک گذاشته شود، کلاینت ممکن است پیش از آنکه حتی تونلی بسازد شکست بخورد. با Get-Service SharedAccess تأیید کنید و اگر در حال اجرا و روی خودکار است، آداپتورها را برای یافتن اتصال اشتراکی بررسی کنید و اشتراک‌گذاری را فقط روی همان آداپتور خاموش کنید.

یک توضیح ارزان‌تر هم هست که باید اول کنار گذاشته شود. دستگاهی که هیچ دسترسی کارآمدی به اینترنت ندارد غالباً این پیام را به جای خطای دسترس‌پذیری نشان می‌دهد، پس پیش از سرزنش کلاینت تأیید کنید که Test-NetConnection به نشانی دروازه و به یک میزبان عمومی هر دو موفق باشند.

تأیید کنید، سپس آنچه لازم نداشتید را برگردانید

تأیید، سپر سبز در سینی سیستم نیست. تأیید کنید که آداپتور وجود دارد، نشانی دارد و ترافیک را عبور می‌دهد: Get-NetAdapter -Name "Cisco AnyConnect*" باید آن را فعال نشان دهد، ipconfig /all باید نشانی تخصیص‌یافته و سرورهای DNS را نشان دهد، و یک درخواست واقعی به یک نام داخلی باید از طریق تونل حل شود نه از طریق حل‌کننده محلی.

فهرست کوتاهی از هر تغییر نگه دارید، با مقداری که یافتید و مقداری که تنظیم کردید. اگر اتصال پس از گام سوم کار کرد، سرویس‌های Hyper-V را بازگردانید و پیش از بستن تیکت دوباره آزمایش کنید، زیرا راه‌حل موقتی که بی‌صدا مجازی‌سازی را غیرفعال می‌کند توسط مدیر بعدی که متوجه شود لغو خواهد شد.

اگر هیچ‌یک از سه گام خطا را جابه‌جا نکرد، تغییر نقطه پایانی را متوقف کنید. نسخه کلاینت، وضعیت سرویس، زمان از بالای این صفحه و بسته تشخیصی‌ای که کلاینت می‌تواند بسازد را جمع کنید و همراه با ترتیب دقیقی که امتحان کردید تحویل دهید. آن بسته برای مهندس بعدی ارزشمندتر از اسکرین‌شات کادر گفتگوست و تنها شیئی است که نشان می‌دهد زیرسیستم پیش از تماس با شبکه شکست خورده یا پس از آن.