Um usuário não consegue entrar na VPN: um diagnóstico ordenado

Quando uma pessoa não consegue conectar-se enquanto o resto da equipe continua trabalhando, a pergunta útil não é o que está quebrado, mas qual camada não entrou em acordo. O login é uma cadeia: o cliente inicia, o gateway responde, uma identidade é afirmada, um segundo fator é satisfeito, a política é avaliada, e só então o tráfego flui. Uma quebra em qualquer ponto dessa cadeia chega até vocês como a mesma frase do usuário, então o primeiro trabalho é encontrar o elo que realmente falhou.

Tratem o relato como ponto de partida e não como diagnóstico. As verificações abaixo vão da mais barata para a mais cara, e cada uma foi escrita para encerrar a investigação quando falha.

Fixem o estágio e o carimbo de tempo

Anotem quatro coisas antes de tocar em qualquer configuração: o cliente e sua versão, a redação exata na tela, o minuto da tentativa e a rede em que a pessoa estava. A redação carrega informação real, porque credenciais rejeitadas, um gateway que não responde e um login concluído que ainda não consegue abrir uma página interna são três problemas diferentes com três responsáveis diferentes. Observem se o cliente gerou uma linha de log local, já que um cliente que nunca enviou um pacote não tem nada a acrescentar a uma busca do lado do servidor. Com o carimbo de tempo registrado, cada consulta posterior vira uma busca e não uma caçada.

Parem de adivinhar senhas neste ponto. Onde a conta tem limite de novas tentativas, uma rajada de tentativas rápidas pode bloqueá-la e acrescentar uma segunda falha artificial sobre a real. Registrem quantas tentativas já foram feitas, para que um bloqueio não seja confundido depois com um sintoma novo. Uma conta bloqueada também tira de vocês a capacidade de distinguir uma senha errada de uma política rejeitada, já que ambas chegam como recusa.

Leiam o evento de identidade daquela única tentativa

Peçam ao administrador que extraia o registro de autenticação que corresponde ao minuto anotado. Em uma implantação do Windows NPS, o guia de solução de problemas do NPS da Microsoft documenta o evento de rejeição 6273 junto com o código de motivo que o acompanha, e isso normalmente separa um usuário desconhecido, credenciais ruins, uma divergência de política e uma chamada derrubada por um motivo não relacionado.

Um resultado vazio também é informação. Se nada chegou ao serviço de identidade, a tentativa morreu antes: um endereço de gateway obsoleto no perfil, um ouvinte que o cliente não alcança, ou um host desativado enquanto o perfil continuava vivo. Se o registro existe e informa sucesso, as credenciais não são o problema e a discussão passa para a autorização ou para o roteamento atrás do gateway. Esses dois resultados apontam em direções opostas, por isso a busca nos logs precisa acontecer antes que alguém reinstale um cliente.

Guardem o código de motivo no chamado. Esse único campo transforma a próxima ocorrência em uma consulta de cinco minutos em vez de uma investigação repetida. Combinem-no com a versão do cliente, porque um código que aparece em uma compilação é outra conversa que um que aparece em todas as compilações.

Mudem uma condição por vez, dentro da política

A tentação é reinstalar o cliente, redefinir a senha e mover o notebook para outra rede em uma única passada. Isso às vezes corrige o sintoma e sempre destrói a evidência. Escolham em vez disso uma única troca permitida: a mesma pessoa em um segundo dispositivo inscrito, ou uma identidade de teste aprovada no mesmo dispositivo. Cada troca responde exatamente a uma pergunta, então um sucesso estreita a falha para o lado que vocês mudaram em vez de culpar a VPN inteira.

Não peçam emprestadas as credenciais de um colega para essa comparação. Usem uma identidade de teste pelo processo suportado, e nunca copiem uma chave de dispositivo nem pulem a inscrição porque seria mais rápido. Onde a política proíbe totalmente uma troca, essa restrição faz parte do sistema em teste e pertence ao registro, não a uma solução alternativa.

Confirmem o reparo no caminho original

Quando o elo quebrado é identificado, reparem apenas esse elo e repitam a tentativa original: mesma pessoa, mesmo dispositivo, mesma rede, mesma aplicação. Uma conta de teste que se conecta pela VLAN de administração prova que o gateway está vivo, e não prova nada sobre a manhã de terça-feira do usuário. Peçam ao usuário que execute a ação que falhou e não uma mais simples, pois um ping bem-sucedido diz pouco sobre um compartilhamento de arquivos rejeitado.

Fechem o chamado com o que foi descartado e o que mudou. Essa nota é a diferença entre um resgate pontual e algo que o próximo engenheiro de plantão poderá reutilizar.