FortiClient trava nos 98%: desative o IPv6 nesse adaptador

A barra chega aos 98%, o cliente fica ali, e reescrever a palavra-passe não muda nada. Essa é a pista útil: o cliente já aceitou o certificado do gateway, enviou as credenciais e recebeu uma configuração de túnel. O que falta é levantar o adaptador virtual e confirmar que o túnel transporta tráfego. Quando esse último passo nunca termina, a falha é local, e nenhuma quantidade de credenciais reescritas chega até ela.

Quatro passos, e o primeiro é ler o registo em vez da barra.

O que o contador dos 98% relata na verdade

A percentagem é o contador de fases do próprio cliente, não uma medida de débito. Um travamento no mesmo número em cada tentativa significa que o cliente chega a uma fase específica e espera; é por isso que uma ligação lenta e um cliente preso aparecem diferentes no registo. Um problema de credenciais imprimiria um erro de credenciais em vez de uma pausa silenciosa.

A Fortinet documentou este sintoma face a uma causa do lado do cliente: IPv6 ativado no adaptador que o cliente utiliza. Isso faz da definição do adaptador a primeira coisa a testar, não uma explicação universal para cada SSL-VPN travamento.

Passo 1: leia o registo antes da barra

Antes de mudar qualquer coisa, capture as linhas imediatamente antes do travamento. Está a procurar se o adaptador de túnel foi criado, se foi atribuído um endereço e se o cliente desistiu de esperar por uma família de endereços. Um travamento noutra percentagem é outra fase com o seu próprio diagnóstico, e um aviso de certificado ou um endereço de gateway errado produz a sua própria mensagem em vez de uma espera silenciosa. Anote a data e hora, porque a tentativa seguinte acrescenta outro bloco ao mesmo ficheiro.

Se o registo mostrar um login concluído seguido de nada, está na configuração local e o adaptador é um suspeito legítimo.

Passo 2: limite a alteração de IPv6 a um só adaptador

A alteração pertence ao adaptador, não à máquina. Nas propriedades do adaptador do Windows isso significa desmarcar Internet Protocol Version 6 (TCP/IPv6) na interface específica, e a partir de uma shell é Disable-NetAdapterBinding -Name "Ethernet 2" -ComponentID ms_tcpip6. Confirme o estado com Get-NetAdapterBinding -ComponentID ms_tcpip6 antes de voltar a ligar. Depois volte a ligar e veja se a barra passa dos 98% em vez de parar aí.

Primeiro delimite o âmbito, depois teste. Desativar o IPv6 globalmente é uma alteração maior do que a questão exige e afeta serviços que não pretendia tocar.

Passo 3: verifique o que o travamento escondia

Um túnel que liga não é um túnel que funciona. Verifique o endereço atribuído pelo cliente, as rotas instaladas pelo perfil e a resolução de nomes para um anfitrião interno: Resolve-DnsName files.corp.example. Um cliente que liga e não resolve nada tem um problema de DNS, e isso é fácil de ler mal como o regresso da mesma falha.

Teste um recurso interno por nome e um destino público, para que um túnel dividido avariado não seja confundido com um cliente reparado.

Passo 4: torne a correção repetível

Se a definição tiver de chegar a uma frota, coloque-a no pacote de implementação ou na configuração do adaptador em vez de num passo manual repetido em cada portátil. Registe no ticket que o travamento nos 98% estava ligado ao IPv6 na interface de rede, e anote o que mais no anfitrião dependia do IPv6 antes de alguém o voltar a ativar para corrigir algo não relacionado.

Uma correção que só existe na memória de um engenheiro é uma correção que regressa no trimestre seguinte.

Se a barra ainda para nos 98% com o IPv6 desativado, a nota do fornecedor já não o explica e o registo é a sua próxima prova. Deixe de tratar o sintoma e volte ao contador de fases.