Ви натискаєте «Підключитися», і діалог відповідає майже миттєво: не вдалося ініціалізувати підсистему з'єднання. До шлюзу нічого не дійшло, тож на іншому боці немає ні обміну сертифікатами, ні облікових даних, ні вибору групи тунелів. Це означає, що журнали концентратора покажуть порожній сеанс, а служба підтримки попросить знімок екрана діалогу, який ніколи не містив нічого корисного. Працюйте натомість з кінцевою точкою, у фіксованому порядку, і зупиніться на першому кроці, який змінить результат.

Час — найцінніший доказ, який у вас є, і записати його нічого не коштує. Запишіть, чи помилка з'явилася до чи після запиту облікових даних і чи почалася вона після оновлення, оновлення Windows або нового агента безпеки. Ці три відповіді зазвичай удвічі скорочують список кандидатів ще до того, як ви торкнетеся будь-якого налаштування.

Прочитайте час, перш ніж щось змінювати

Три точки відмови виглядають однаково й такими не є. Якщо діалог з'являється в момент натискання «Підключитися», клієнт не зміг запустити власну інфраструктуру, і саме на це вказує це повідомлення. Якщо він з'являється після введення облікових даних, групи тунелів досягнуто, а проблема далі. Якщо тунель піднімається й потім падає, підсистема ініціалізувалася правильно, і ви ганяєтеся за зовсім іншою помилкою. Плутанина між цими трьома коштує півдня на перевстановлення, які не можуть допомогти.

Сюди належить лише перший випадок. Повідомлення формується до будь-якого мережевого рішення, тому неправильна адреса шлюзу, прострочений сертифікат або поганий пароль його не викличуть.

Крок 1: переконайтеся, що служба агента працює

Вікно, на яке ви натискаєте, — лише інтерфейс; робота відбувається в службі Cisco AnyConnect Secure Mobility Agent, зареєстрованій як vpnagent. Якщо ця служба зупинена або вимкнена, графічному інтерфейсу немає з ким розмовляти і він повідомляє саме про цей збій ініціалізації. Перевірте стан і тип запуску з командного рядка PowerShell з підвищеними правами:

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

Інсталятор, який поважав раніше заданий вручну тип запуску, — звичайна причина того, що служба виявляється вимкненою, тому перевірте StartType, а не просто натискайте «Запустити». Якщо служба запускається й зупиняється за секунди, прочитайте журнал System щодо записів Service Control Manager, перш ніж натискати «Виправити»:

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

Заблокований драйвер, файл у карантині або драйвер фільтра стороннього продукту безпеки назве себе в цих подіях. «Виправити» перевстановлює поверх того самого заблокованого файлу й нічого не змінює, тому журнал подій іде першим.

Крок 2: очистіть автономний стан, який повідомляє стек HTTP

Клієнт завантажує профіль і оцінює політику через компоненти HTTP Windows, тому прапорець автономної роботи в інтернет-налаштуваннях користувача може зламати ініціалізацію, хоча кожен браузер продовжує завантажувати сторінки. Перевірте значення безпосередньо:

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

Значення 1 означає, що стек WinINet повідомляє викликачам, що машина не має з'єднання; зазвичай цей стан задає пункт меню «Працювати автономно» в Internet Explorer або сценарій автоматизації. Поверніть його на 0, вийдіть і увійдіть знову та повторіть підключення, перш ніж змінювати щось інше.

Якщо ця машина дісталася вам у спадок і ви не можете сказати, чому прапорець було встановлено, занотуйте це в заявці. Щось інше на машині могло задати його навмисно, і він повернеться під час наступного входу.

Крок 3: звільніть віртуальний адаптер від Hyper-V або ICS

Дві ролі Windows можуть утримувати частини, потрібні клієнтові для створення адаптера. 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 і перевірте ще раз, перш ніж закрити заявку, бо обхідний шлях, який тихо вимикає віртуалізацію, скасує наступний адміністратор, який це помітить.

Якщо жоден із трьох кроків не зрушує помилку, припиніть змінювати кінцеву точку. Зберіть версію клієнта, стан служби, час із верхньої частини цієї сторінки й діагностичний пакет, який клієнт може створити, і передайте їх разом із точним порядком, який ви спробували. Цей пакет для наступного інженера цінніший за знімок екрана діалогу, і це єдиний артефакт, який показує, чи підсистема зазнала невдачі до чи після звернення до мережі.

Схожі статті