FortiClient зависає на 98%: вимкніть IPv6 на цьому адаптері

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

Чотири кроки, і перший — читати журнал, а не смугу.

Що насправді повідомляє лічильник 98%

Відсоток — це власний лічильник етапів клієнта, а не міра пропускної здатності. Зависання на тому самому числі при кожній спробі означає, що клієнт доходить до певного етапу й чекає; тому повільне з'єднання й завислий клієнт виглядають у журналі по-різному. Проблема з обліковими даними надрукувала б помилку облікових даних замість тихої паузи.

Fortinet задокументувала цей симптом щодо однієї причини з боку клієнта: IPv6 увімкнено на адаптері, який використовує клієнт. Тому налаштування адаптера — перше, що слід перевірити, а не універсальне пояснення кожного SSL-VPN зависання.

Крок 1: прочитайте журнал раніше за смугу

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

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

Крок 2: обмежте зміну IPv6 одним адаптером

Зміна стосується адаптера, а не машини. У властивостях адаптера Windows це означає зняти Internet Protocol Version 6 (TCP/IPv6) на конкретному інтерфейсі, а з оболонки це Disable-NetAdapterBinding -Name "Ethernet 2" -ComponentID ms_tcpip6. Підтвердьте стан за допомогою Get-NetAdapterBinding -ComponentID ms_tcpip6 перед повторним підключенням. Потім підключіться знову й подивіться, чи смуга проходить 98%, а не зупиняється на ньому.

Спочатку обмежте область, потім перевіряйте. Глобальне вимкнення IPv6 — більша зміна, ніж вимагає питання, і воно зачіпає служби, які ви не збиралися чіпати.

Крок 3: перевірте, що приховувало зависання

Тунель, який підключається, — не тунель, який працює. Перевірте адресу, призначену клієнтом, маршрути, встановлені профілем, і розв'язання імен для одного внутрішнього хоста: Resolve-DnsName files.corp.example. У клієнта, який підключається й нічого не розв'язує, проблема з DNS, і це легко прочитати неправильно як повернення тієї самої несправності.

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

Крок 4: зробіть виправлення повторюваним

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

Виправлення, яке існує лише в пам'яті одного інженера, — це виправлення, яке повернеться наступного кварталу.

Якщо смуга все одно зупиняється на 98% із вимкненим IPv6, примітка постачальника цього вже не пояснює, і журнал — ваш наступний доказ. Перестаньте лікувати симптом і поверніться до лічильника етапів.