VPN do Windows não conecta? Combine o código com o log de eventos

Na sexta-feira funcionava. Na segunda, o mesmo cliente Windows responde com uma caixa de diálogo dizendo que a tentativa de conexão falhou, e a frase abaixo é uma que você já viu para uma dúzia de problemas sem relação. Essa caixa de diálogo é o fim de uma cadeia, não o começo. O Windows esconde o estágio em que a tentativa realmente morreu, e duas pequenas evidências o nomeiam: o código numérico de resultado e um evento RasClient daquele mesmo minuto. Esta é a ordem que uso — fixe a tentativa, leia o código, extraia o evento e depois altere exatamente uma camada.

O texto da caixa de diálogo é o último passo, não a causa

A frase que você lê é escolhida depois que a tentativa já se desenrolou. "A conexão foi encerrada pelo computador remoto antes de a conexão ser estabelecida" aparece quando um servidor desliga no meio da negociação, quando o IPsec falhou antes de seu nome de usuário ser enviado, e quando uma política recusou o túnel de imediato. Três donos diferentes, uma frase. Trate a redação como uma classe de sintoma e não deixe que ela dirija nada até o código concordar com ela.

O que ainda dá para fixar é a própria tentativa. Anote o nome da conexão, o tipo de túnel guardado no perfil — PPTP, L2TP/IPsec, SSTP ou IKEv2 —, a hora até o segundo e o código. Se não tiver certeza de qual protocolo realmente rodou, abra %APPDATA%\Microsoft\Network\Connections\Pbk\rasphone.pbk e leia a entrada em vez de confiar na memória; um perfil reutilizado para um novo protocolo mantém o antigo nome de exibição.

Leia o número antes de ler as palavras

Os códigos caem em três estágios, e o estágio importa mais que a redação exata: uma troca de autenticação alcançada e recusada, um servidor que nunca respondeu, ou uma negociação que desabou depois que o enlace subiu. 691 é o primeiro tipo — a verificação de credenciais rodou e falhou, seja por senha errada, conta bloqueada ou expirada, ou um protocolo de autenticação que o servidor não aceita. 812 também é uma recusa, mas com credenciais válidas: uma política no servidor de acesso remoto decidiu contra você. A Microsoft mantém a lista de códigos de erro de conexão discada e VPN canônica, e vale ler ali o seu número antes de procurar o texto da mensagem.

809 é a classe oposta: nada voltou. Isso é um problema de caminho — TCP 443 filtrado para SSTP, GRE bloqueado para PPTP, UDP 500 e 4500 ou ESP descartados para a passagem de IPsec. Uma senha nova não corrige isso, e um certificado novo também não. 720 significa que o enlace subiu e o PPP nunca terminou de negociar, o que aponta para uma incompatibilidade de protocolo ou um servidor que não conseguiu atribuir um endereço. 789, ou 13801 no IKEv2, é identidade dentro do IPsec: um certificado cujo sujeito não corresponde ao nome que você disca, uma cadeia não confiável, ou uma chave pré-compartilhada que difere entre as duas pontas.

Extraia o evento RasClient daquele mesmo minuto

No Visualizador de Eventos, Windows Logs > Application filtrado pela origem RasClient é o primeiro lugar onde olhar. O artigo da Microsoft sobre o erro 720 aponta para o evento 20227 desse log. O mesmo provedor emite outros identificadores para outros resultados, então leia a mensagem e o código de resultado embutido nela em vez de tratar o ID como o diagnóstico; uma caixa genérica mais um 20227 carregando 720 já é uma história bem mais estreita.

Do PowerShell, sem clicar pela interface gráfica:

Get-WinEvent -FilterHashtable @{
  LogName      = 'Application'
  ProviderName = 'RasClient'
  StartTime    = (Get-Date).AddMinutes(-15)
} | Format-List TimeCreated, Id, Message

Um resultado vazio é informativo. Normalmente significa que a discagem nunca foi longe o bastante para o RAS registrar algo, ou que o software que falhou não é o cliente nativo de jeito nenhum — clientes de terceiros mantêm o próprio diagnóstico e muitas vezes não escrevem nada no log Application. Verifique o log do fornecedor antes de concluir que o registro de eventos está quebrado.

Construa uma linha do tempo em vez de um monte de eventos

Laços de nova tentativa fabricam ruído. Cinco reconexões automáticas deixam um aglomerado de eventos, e a tentação é lê-los como uma única sequência com uma única causa. São cinco tentativas separadas, e só algumas chegaram a um servidor. Pegue uma janela de dois ou três minutos, um nome de conexão, e liste cada evento com o próprio código antes de interpretar qualquer coisa.

Depois pergunte onde a tentativa parou. Quando o gateway ou o backend de autenticação não guarda nenhum registro para aquele carimbo de tempo, o cliente nunca o alcançou, e você está diante de um problema de alcance. Quando o backend mostra uma requisição e uma recusa, a decisão foi tomada ali, e vale a classe de credenciais ou de política. Compare os relógios antes de comparar os horários: clientes informam a hora local, muitos gateways registram em UTC, e um deslocamento fará um par perfeitamente correlacionado parecer sem relação.

Para uma captura repetível, disque pela linha de comando e deixe que ela imprima o resultado:

rasdial "Office VPN"
rasdial "Office VPN" /disconnect

O console mostra o número que a interface esconde atrás de um texto amigável, e executá-lo duas vezes diz se o código é estável ou intermitente.

O que cada estágio diz para você mudar

Nomear o estágio só é útil se ele encolher o conjunto de mudanças para uma camada:

• 691 — autenticação: o método EAP que o cliente oferece contra o que o servidor aceita, estado da conta, expiração da senha, permissão de acesso discado.
• 812 — política do servidor: a política de acesso remoto ou a regra NPS que corresponde a este usuário e a esta janela de tempo.
• 809 — alcance: regras de firewall no caminho, NAT e passagem de protocolo, a porta de que o tipo de túnel escolhido precisa.
• 720 — negociação PPP: incompatibilidade de protocolo de autenticação, atribuição de endereço, um ajuste PPP do lado do servidor.
• 789 / 13801 — identidade IPsec: sujeito do certificado contra o nome que você disca, cadeia de confiança, chave pré-compartilhada.

Mude uma dessas coisas, teste de novo o mesmo perfil e anote o código novo. Um código diferente depois de uma mudança é progresso, não contradição: você moveu a falha para um estágio posterior, e é assim que se parece consertar um aperto de mãos de várias etapas. O que você não deveria fazer é alterar o firewall, o certificado e a senha numa única sessão e depois dar o crédito ao que veio por último.

Compartilhe as evidências, não o ambiente

As mensagens de evento são mais ricas do que parecem. Elas carregam o nome da conexão, a conta, muitas vezes o nome ou o endereço interno do gateway, e às vezes uma impressão digital de certificado. Guarde o original onde ele pertence, e construa uma cópia editada separada para qualquer outra pessoa; redigitar a linha do tempo de memória perde exatamente os detalhes que a tornam útil.

Uma passagem que será trabalhada precisa de cinco campos: o código, o estágio a que pertence, o cliente e o tipo de túnel, o carimbo de tempo com o seu fuso horário, e se o gateway viu a requisição. Todo o resto é opcional. Com esses cinco, a próxima pessoa consegue distinguir uma discussão de credenciais de uma de roteamento sem repetir a investigação.

Antes de fechar qualquer coisa, repita a tentativa no mesmo perfil e confirme onde o código cai agora. Um sucesso encerra; uma falha diferente significa que o estágio original está corrigido e você tem o próximo nas mãos.