Corrigir o erro do AnyConnect „falha ao inicializar o subsistema de conexão“

Você clica em Conectar e a caixa de diálogo responde quase na hora: falha ao inicializar o subsistema de conexão. Nada chegou ao gateway, então não há troca de certificados, nem credencial, nem seleção de grupo de túnel do outro lado. Isso significa que os registros do concentrador mostrarão uma sessão vazia e que o suporte pedirá uma captura de tela de uma caixa que nunca conteve nada útil. Trabalhe no endpoint, numa ordem fixa, e pare no primeiro passo que mudar o resultado.

O momento é a evidência mais valiosa que você tem, e registrá-lo não custa nada. Anote se o erro apareceu antes ou depois da solicitação de credenciais e se começou depois de uma atualização, de uma atualização do Windows ou de um novo agente de segurança. Essas três respostas costumam reduzir pela metade a lista de candidatos antes de você tocar em qualquer configuração.

Leia o momento antes de mudar qualquer coisa

Três pontos de falha parecem iguais e não são. Se a caixa aparece no instante em que você pressiona Conectar, o cliente não conseguiu iniciar a própria infraestrutura, e é para isso que esta mensagem aponta. Se aparece depois de você digitar as credenciais, o grupo de túnel foi alcançado e o problema está mais adiante. Se o túnel sobe e depois cai, o subsistema foi inicializado corretamente e você está atrás de um bug completamente diferente. Confundir os três desperdiça uma tarde em reinstalações que não podem ajudar.

Só o primeiro caso pertence aqui. A mensagem é gerada antes de qualquer decisão de rede, portanto um endereço de gateway errado, um certificado expirado ou uma senha ruim não vão produzi-la.

Passo 1: confirme que o serviço do agente está em execução

A janela em que você clica é apenas a frente; o trabalho acontece no serviço Cisco AnyConnect Secure Mobility Agent, registrado como vpnagent. Se esse serviço estiver parado ou desativado, a interface gráfica não tem com quem falar e relata exatamente esta falha de inicialização. Verifique o estado e o tipo de início em um prompt do PowerShell elevado:

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

Um instalador que respeitou um tipo de início manual anterior é a razão habitual de isso acabar desativado, então verifique StartType em vez de apenas pressionar Iniciar. Se o serviço iniciar e parar em segundos, leia o log do Sistema em busca de entradas do Service Control Manager antes de clicar em Reparar:

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

Um driver bloqueado, um arquivo em quarentena ou um driver de filtro de um produto de segurança de terceiros vai se nomear nesses eventos. Reparar reinstala sobre o mesmo arquivo bloqueado e não muda nada, por isso o log de eventos vem primeiro.

Passo 2: limpe o estado offline que a pilha HTTP relata

O cliente baixa o perfil e avalia políticas pelos componentes HTTP do Windows, então um sinalizador offline definido nas configurações de Internet do usuário pode quebrar a inicialização enquanto todos os navegadores continuam carregando páginas. Verifique o valor diretamente:

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

Um valor de 1 significa que a pilha WinINet diz aos chamadores que a máquina não tem conexão; esse estado costuma ser definido pelo item de menu Trabalhar offline do Internet Explorer ou por um script de automação. Defina-o de volta para 0, saia e entre novamente, e repita a conexão antes de mudar qualquer outra coisa.

Se você herdou esta máquina e não sabe dizer por que o sinalizador foi definido, anote isso no chamado. Outra coisa na máquina pode tê-lo definido de propósito, e ele voltará no próximo logon.

Passo 3: libere o adaptador virtual do Hyper-V ou do ICS

Duas funções do Windows podem reter as peças de que o cliente precisa para criar o adaptador. O Hyper-V é a primeira: com os serviços do comutador virtual em execução, a criação do adaptador pode falhar de maneiras que se manifestam como este erro. Parar os serviços é um diagnóstico, não uma correção:

Get-Service vmms, vmcompute | Stop-Service
Get-NetAdapter | Where-Object InterfaceDescription -like "*Hyper-V*"

Se o cliente se conectar com esses serviços parados, o conflito está confirmado e agora você sabe o que negociar com o dono do host Hyper-V. Reinicie-os depois, a menos que a máquina não precise mais de virtualização.

O Compartilhamento de Conexão com a Internet é o segundo dono. Se uma conexão estiver sendo compartilhada, o cliente pode falhar antes mesmo de criar um túnel. Confirme com Get-Service SharedAccess e, se estiver em execução e definido como automático, procure nos adaptadores uma conexão compartilhada e desative o compartilhamento apenas naquele adaptador.

Há também uma explicação mais barata de descartar primeiro. Uma máquina sem nenhum acesso funcional à Internet costuma mostrar esta mensagem em vez de um erro de alcance, então confirme que Test-NetConnection para o endereço do gateway e para um host público são bem-sucedidos antes de culpar o cliente.

Verifique e depois reverta o que não era necessário

Verificação não é o escudo verde da bandeja. Confirme que o adaptador existe, tem endereço e passa tráfego: Get-NetAdapter -Name "Cisco AnyConnect*" deve mostrá-lo ativo, ipconfig /all deve mostrar o endereço atribuído e os servidores DNS, e uma requisição real a um nome interno deve ser resolvida pelo túnel e não pelo resolvedor local.

Mantenha uma lista curta de cada mudança, com o valor encontrado e o valor definido. Se a conexão funcionar após o terceiro passo, restaure os serviços do Hyper-V e teste novamente antes de fechar o chamado, porque uma gambiarra que desativa a virtualização em silêncio será desfeita pelo próximo administrador que perceber.

Se nenhum dos três passos mover o erro, pare de mudar o endpoint. Reúna a versão do cliente, o estado do serviço, o momento do topo desta página e o pacote de diagnóstico que o cliente consegue gerar, e entregue tudo com a ordem exata que você tentou. Esse pacote vale mais para o próximo engenheiro do que uma captura da caixa de diálogo, e é o único artefato que mostra se o subsistema falhou antes ou depois de tocar a rede.