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 и това лесно се прочита погрешно като завръщане на същата неизправност.

Тествайте един вътрешен ресурс по име и една публична дестинация, за да не се сбърка счупен split тунел с поправен клиент.

Стъпка 4: направете поправката възпроизводима

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

Поправка, която съществува само в паметта на един инженер, е поправка, която се връща следващото тримесечие.

Ако лентата все още спира на 98% с изключен IPv6, бележката на доставчика вече не го обяснява и журналът е следващото ви доказателство. Спрете да лекувате симптома и се върнете към брояча на етапите.