Azure VPN Client: a plataforma VPN não iniciou a ligação

A linha de estado diz que a plataforma VPN não iniciou a ligação, o perfil importa sem queixas e o gateway está saudável para todos os outros. Essa mensagem descreve uma entrega dentro do Windows, não uma credencial rejeitada, por isso a ordem útil vai da mudança de estado mais barata para a mais destrutiva. Reimportar um perfil custa um minuto, reparar o pacote custa um reinício e repô-lo custa todos os perfis da máquina. Trabalhar na ordem errada destrói as provas de que precisa para distinguir esses casos.

Reimportar, reparar, repor: três custos diferentes

As três ações não são intermutáveis e só uma é reversível sem trabalho. Reimportar atualiza o perfil e mantém a instalação da aplicação. Reparar mantém os perfis importados e reescreve os ficheiros do pacote. Repor remove os perfis juntamente com o estado da aplicação, por isso depois volta a importar tudo.

Comece com uma transferência nova de azurevpnconfig.xml sempre que o gateway, o conjunto de endereços ou o método de autenticação tenham mudado. Um perfil que nomeia um gateway eliminado produz exatamente esta linha de estado, e nenhuma reparação do cliente corrige um ficheiro que aponta para algo que já não existe.

Antes de qualquer passo destrutivo, confirme que a aplicação pode ser executada em segundo plano: Definições, Aplicações, Aplicações instaladas, Azure VPN Client, Opções avançadas. Um cliente suspenso não consegue concluir a entrega da plataforma.

RasMan é o serviço ao qual o cliente entrega

O Remote Access Connection Manager transforma um pedido do cliente numa ligação Windows. Reinicie-o a partir de uma linha de comandos elevada com net stop rasman e depois net start rasman, e volte a ligar antes de alterar outra coisa.

Se isso restaurar a ligação, defina o tipo de arranque para que a correção sobreviva a um reinício: sc.exe config rasman start= delayed-auto. Um serviço que agora está a funcionar mas desativado no arranque reproduz a mesma falha amanhã de manhã.

Vigie um serviço que arranca e depois para sozinho. Esse padrão aponta para uma dependência ou uma política, e reiniciá-lo funcionará durante minutos, o que é pior do que uma falha limpa porque parece um problema de rede intermitente. Verifique o registo System para o nome do serviço à volta do momento da tentativa e confirme que as dependências também estão a funcionar.

Utilizador atual ou computador local: dois arquivos de certificados

Se o cliente abrir com uma lista de certificados vazia, a culpa não é do perfil nem do serviço. O cliente lê o arquivo pessoal do utilizador atual: abra certmgr.msc, expanda Certificates, Current User, Personal, Certificates e confirme que o certificado está lá com uma chave privada.

O arquivo do computador local aberto com certlm.msc é outro arquivo, e instalar lá não satisfaz um cliente que procura no arquivo do utilizador. Com autenticação por certificado, o gateway detém apenas a chave pública da raiz, e cada dispositivo precisa do seu próprio certificado emitido a partir dessa raiz. Um certificado copiado de outra máquina chega normalmente sem a sua chave privada, o que produz uma entrada que pode selecionar mas que ainda não consegue autenticar.

Um seletor vazio é um problema do arquivo, não do túnel.

Autenticação por certificado ou Azure AD: formas de falha diferentes

Para autenticação Azure AD, a configuração ponto a local precisa do URL do inquilino, do ID da aplicação Azure VPN Client como audiência e do emissor STS, com um administrador a conceder consentimento à aplicação Azure VPN. Guarde essa configuração, transfira o pacote novamente e importe o ficheiro novo em vez de reutilizar uma cópia antiga.

Confirme também que o conjunto de endereços do cliente não se sobrepõe à rede virtual nem a um intervalo local, e que o grupo de segurança de rede da máquina de destino permite o conjunto. Esses dois erros sobrevivem a qualquer reparação do lado do cliente.

Lado do portátil ou lado do gateway

Não julgue o túnel por uma verificação de endereço público. Uma ligação ponto a local não envia todo o tráfego de internet para o Azure, por isso um endereço público sem alterações é o esperado enquanto o túnel funciona corretamente. Em vez disso, teste um endereço privado dentro da rede virtual e leia as rotas efetivas na máquina.

Anote qual passo restaurou a ligação, a versão do cliente, a data de transferência do perfil e se foi um certificado ou o fornecedor de identidade que forneceu a credencial. Esse registo transforma a próxima ocorrência numa verificação de dois minutos e mostra se as falhas estão a deslocar-se para o gateway em vez de ficarem no portátil.

Ordem de trabalho: reimporte um perfil atual, reinicie o RasMan, permita a execução em segundo plano, repare o pacote e reponha apenas se o arquivo de certificados estiver confirmado intacto.