IKEv1 com XAuth e OTP: o que cada prompt pede
Uma PSK de grupo, uma troca XAuth do usuário e um desafio OTP são três entradas diferentes. Relacione cada prompt ao seu dono antes de instalar outro cliente.
IKEv1 com PSK, XAuth e OTP não pede uma senha complicada única. Ele empilha uma chave compartilhada entre os pares, uma troca de usuário e um segundo fator cuja forma de solicitação é decidida pelo backend. Cada camada tem seu dono e sua própria mensagem de falha. Confundi-las leva as pessoas a digitar de novo um código de uso único em um campo que guarda um segredo de grupo.
Relacione cada prompt à camada que o solicita antes de instalar outro cliente ou redefinir uma credencial.
Três segredos, três donos
A chave pré-compartilhada pertence ao relacionamento entre pares e é configurada uma vez por quem administra as duas pontas. A credencial do usuário pertence ao backend de autenticação e é validada a cada login. O segundo fator pertence a um sistema de tokens cuja resposta muda a cada tentativa. Nenhum substitui o outro, e uma implantação que os trata como uma única senha falha na camada que ninguém documentou.
Anote três colunas: dono, tempo de vida e a mensagem de falha que cada um produz. Essa tabela é a ferramenta de diagnóstico, e não os nomes dos campos do cliente.
| Layer | Owner | Lifetime |
|---|---|---|
| Pre-shared key | Peer configuration | Until operators change it |
| XAuth credential | Authentication backend | Per session, per policy |
| One-time code | Token system | Single use |
PSK: do par, não da pessoa
Neste arranjo legado, a chave pré-compartilhada autentica o par de gateways, então o login do usuário nunca a substitui. É também o valor mais propenso a estar errado de um modo que gera um erro genérico de negociação em vez de um prompt. Quando o túnel falha antes de qualquer prompt do usuário aparecer, os suspeitos são a chave ou as propostas.
Uma credencial de usuário não conserta uma falha da primeira fase. Girá-la desperdiça a única credencial que você pode girar com segurança e reforça a teoria errada.
XAuth: a troca de usuário legada
O XAuth adiciona uma troca de autenticação de usuário sobre a autenticação de par do IKEv1, e o gateway decide qual backend a valida. Dependendo desse backend, a troca pode aceitar uma senha de diretório, uma credencial RADIUS ou uma resposta de token. A palavra XAuth nomeia o transporte da troca, não o tipo de credencial.
Verifique para qual backend o perfil do gateway aponta. Isso diz o que será pedido ao usuário e o que a redefinição de senha realmente altera, e nenhum dos dois aparece em um perfil de cliente.
OTP: o que o backend pedir
Algumas implantações pedem um código de uso único separado depois da senha, e outras definem um formato de entrada combinado com um separador documentado. Ambos existem, e o perfil à sua frente decide qual. Inventar uma concatenação porque funcionou em outro site é a maneira mais comum de queimar um token de registro. A documentação do próprio gateway é a única fonte que resolve isso.
Use o formato documentado com um cliente capaz de concluir a troca que o gateway oferece.
Onde a fronteira do cliente morde
A Fortinet documenta que o FortiClient 7.4.4 e versões posteriores não suportam mais IKEv1 para VPNs IPsec, o que é uma fronteira de produto e versão, não uma remoção universal, como registra a nota de compatibilidade do FortiClient. Outros clientes também não são intercambiáveis: OpenConnect e openfortivpn falam protocolos de gateway específicos, não perfis IKEv1 arbitrários. Verifique individualmente a versão de IKE, o modo PSK, o suporte a XAuth e o modelo de interação do cliente instalado. Um cliente que se conecta por outro método não provou o requisito original.
O IKEv1 está obsoleto, então uma nova implantação construída sobre um cliente antigo sem suporte é uma solução de vida curta. Peça ao dono do gateway um caminho de migração suportado, incluindo como o segundo fator será tratado lá.
Diagnosticar sem desativar o fator
Separe os estágios no log: negociação dos pares, troca de usuário, resultado do segundo fator e, depois, atribuição de endereço e rota. Registre o componente e o estágio em vez de testar o código em cada campo. Desativar o fator para um teste passar produz um túnel que não prova nada sobre a implantação.
Guarde os segredos de registro e a chave compartilhada em armazenamento protegido conforme o processo da organização. Um código de uso único em um arquivo permanente é um fator que deixou de ser fator.