A troca IKEv2 funciona, depois a autenticação falha: onde procurar

Um cliente que recebe uma resposta IKEv2 provou que o gateway é alcançável, que ambos os lados podem negociar uma proposta e que a troca de chaves inicial foi concluída. Não provou que alguém esteja autenticado. A troca seguinte transporta identidades, certificados ou EAP, e é aí que a conexão normalmente para. Ler qual dessas verificações falhou é todo o diagnóstico, e a mensagem de erro sozinha raramente o diz.

Verificação 1: leia o estágio, não a mensagem

Uma rejeição pode vir de três lugares: o cliente recusando a identidade do servidor, o gateway recusando a prova do cliente e um serviço de autenticação externo recusando a conta.

Cada uma produz uma linha de log diferente em uma máquina diferente, e cada uma tem uma correção diferente. Uma rejeição do certificado do servidor no lado do cliente é um problema de confiança ou de nomenclatura no cliente; uma rejeição do certificado do cliente no lado do gateway é um problema de confiança no gateway; uma falha de EAP é um problema de conta ou de backend. A mensagem que você vê costuma ser o resumo do cliente de um desses casos, e é por isso que o log do gateway importa tanto quanto o do cliente.

Verificação 2: qual identidade foi verificada

Um cliente pode recusar o certificado do servidor ou a identidade esperada antes que qualquer credencial de usuário seja oferecida, e um endereço de servidor que funciona não substitui essa verificação. O identificador que o cliente espera deve corresponder ao que o gateway apresenta, o que é um fato de configuração e não um fato de rede.

Em termos de strongSwan, isso é rightid no cliente e a identidade do próprio gateway do outro lado, e uma divergência falha antes mesmo de se discutir EAP.

O gateway, separadamente, pode recusar o certificado do cliente, sua prova de chave ou a autenticação da conta, e esses três não são intercambiáveis. Redefinir a senha de um usuário não renova um certificado de dispositivo, e reinstalar um certificado de dispositivo não corrige uma identidade de servidor errada. Para falhas de certificado, verifique primeiro o relógio, depois a cadeia de confiança e por fim o identificador esperado; um cliente cujo relógio está alguns minutos adiantado falha numa verificação de validade que parece uma falha de confiança. swanctl --list-certs nas duas pontas mostra o que cada lado realmente possui.

Verificação 3: se o EAP estiver em jogo

O cliente e o servidor precisam concordar com um método suportado, e o backend precisa aceitar a identidade fornecida.

Um nome de usuário pode precisar de um sufixo de domínio ou de um formato de conta específico exigido pela implantação, e o formato é documentado e não adivinhável. Fornecer os campos documentados pelo operador é mais rápido do que tentar variações, e evita um segundo problema: tentativas repetidas podem provocar o bloqueio da conta, que então esconde o estágio original atrás de uma nova falha. Se o método for EAP-MSCHAPv2 contra um diretório, a falha pode pertencer ao diretório e não à VPN.

Não teste problemas de identidade desativando as verificações de identidade. Isso transforma uma falha diagnosticável em não diagnosticável e deixa a conexão mais fraca do que antes.

Verificação 4: o que acontece após um login bem-sucedido

Quando o IKE_AUTH termina, a negociação do CHILD_SA decide quais seletores de tráfego são instalados, e é aí que uma conexão pode ter sucesso e mesmo assim não passar nada.

Um login recém-funcional muitas vezes revela um problema de seletor ou de rota que antes estava escondido atrás da falha de autenticação. Se o túnel sobe e um aplicativo ainda não alcança o destino, olhe os seletores e as rotas negociados em vez da identidade outra vez. Mudar as configurações de identidade nesse momento mira o estágio errado e normalmente quebra um login que funciona. Confirme com swanctl --list-sas, que mostra os filhos e seus seletores separadamente do IKE SA.

Verificação 5: o que entregar ao suporte

Uma linha do tempo higienizada e a rejeição precisa valem mais do que uma exportação de diagnóstico completa, e a exportação pode conter chaves privadas ou credenciais que você não deveria compartilhar.

Registre a hora com o fuso horário, as versões do cliente e do gateway, o método, a string de identidade oferecida em vez da senha e o estágio exato que a rejeitou. A documentação de configuração IKEv2 do strongSwan descreve as configurações de identidade e EAP que determinam esses resultados, e é a referência a ler antes de mudar um campo. Depois mude uma coisa e teste novamente uma conexão nova, porque uma sessão em cache falará da configuração antiga.