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, заметка поставщика больше этого не объясняет, и журнал — ваше следующее доказательство. Перестаньте лечить симптом и вернитесь к счётчику этапов.