Planeje configurações de IKEv2 que atendam a mais de um cliente

Um perfil que funciona em um desktop é um teste bem-sucedido de um cliente. Não é uma implantação multiplataforma, e tratá-lo como tal produz o padrão de suporte conhecido: o Windows se conecta, o celular falha na verificação de identidade e o notebook gerenciado se reconecta sempre que desperta. As diferenças são reais e em grande parte previsíveis, por isso o plano deve ser uma matriz e não uma captura de tela.

Primeiro decida o contrato de identidade

Documente a identidade do servidor, a confiança no certificado e o método de autenticação do cliente antes de discutir algoritmos. Esses três decidem se um cliente consegue autenticar, e são as partes que as plataformas expressam de forma diferente.

Verifique como cada plataforma nomeia o identificador esperado e como trata os nomes alternativos do sujeito. Um perfil que aceita um nome de servidor em um cliente pode rejeitar o mesmo certificado em outro porque o campo do identificador é preenchido com um valor diferente.

Depois escolha a interseção criptográfica

Compare as propostas que cada cliente compatível pode oferecer e escolha uma interseção moderna que o gateway também permita. Não ative uma lista legada superdimensionada para que um único dispositivo antigo se conecte, porque essa lista se torna o padrão do gateway para todos os que vierem depois. Anote por que cada opção legada ainda existe. Se ninguém conseguir nomear o dispositivo que precisa dela, não é um requisito.

Mantenha as definições de IKE e CHILD separadas no plano. Uma proposta aceitável para a troca IKE não é automaticamente aceitável para o tráfego protegido, e as duas são negociadas separadamente. Um gateway que aceita uma proposta em uma camada ainda pode recusá-la na outra, e o log mostrará uma falha que parece que a primeira camada funcionou.

Forneça credenciais por meio de um processo verificado e mantenha a senha do usuário, o segredo compartilhado e a chave privada do cliente em seus próprios campos. Tentativa e erro em caixas com nomes parecidos é o caminho pelo qual um teste que funciona se torna irreproduzível.

Teste o ciclo de vida, não o estado estável

Para cada cliente, teste a autenticação inicial, o aplicativo pretendido, a resolução de DNS e a cobertura de famílias de endereços. Depois exercite as partes que só aparecem mais tarde: renovação, suspensão e uma mudança de rede normal.

O suporte a MOBIKE e o comportamento de reautenticação podem diferir do resultado estável que você acabou de medir. Registre o evento e o estado da associação naquele momento, não apenas se a interface acaba parecendo conectada.

Defina o que o tráfego direto pode fazer enquanto a VPN não está disponível. É uma decisão de política separada de se o cliente se reconecta, e a maioria das implantações responde à segunda pergunta ignorando a primeira. Escreva a resposta nas notas de implantação ao lado dos nomes dos perfis. Alguém vai precisar dela durante uma interrupção e não terá tempo de reconstruí-la.

Use verificações de identidade do servidor quando uma plataforma discordar

Quando um perfil funciona em uma plataforma e outra rejeita o nome, compare o identificador que o cliente realmente enviou com os identificadores que o certificado carrega. Essa comparação resolve a maioria desses casos mais rápido do que mudar as listas de cifras.

Mantenha a matriz testada junto com a origem da configuração e o procedimento de atualização. Quando o suporte a um cliente antigo terminar, remova a exceção deliberadamente em vez de deixar configurações de compatibilidade mais fracas escondidas no gateway para a próxima auditoria encontrar. A documentação do strongSwan sobre IKEv2 é uma referência útil sobre como as trocas são configuradas.