Por que reimportar um certificado de Client VPN exige um novo endpoint

Uma conexão de Client VPN cai, o certificado no ACM é substituído e nada muda. O objeto do certificado nunca foi o que o ponto de extremidade usava. Um ponto de extremidade guarda na criação uma associação a um certificado, junto com a CA de cliente contra a qual validará, o tipo de autenticação, as sub-redes e as regras de autorização, e nenhuma dessas associações tem uma chamada de modificação que aceite um certificado substituto. Substituir os bytes por trás de um ARN é uma mudança no certificado, não no ponto de extremidade que o capturou.

O ponto de extremidade guarda referências, não certificados

Vale enunciar o mecanismo com precisão porque ele explica toda a falha. create-client-vpn-endpoint recebe um ARN de certificado de servidor e um ARN de cadeia de certificados raiz de cliente, e o ponto de extremidade resultante mantém essas referências mais as opções de autenticação como propriedades fixas. A API não oferece operação que troque o certificado de servidor em um ponto de extremidade existente.

Você pode confirmar a vinculação sem adivinhar. aws ec2 describe-client-vpn-endpoints --client-vpn-endpoint-ids cvpn-endpoint-0123456789abcdef0 imprime o ARN do certificado, o ARN da cadeia raiz do cliente, o tipo de autenticação, o CIDR do cliente e as sub-redes associadas, que é o conjunto completo de propriedades que você teria de reproduzir. Execute antes e depois de uma reimportação e a saída não se move. Essa é a prova de que a reimportação nunca ia ajudar.

Por que uma reimportação não alcança o ponto de extremidade

Uma reimportação grava um novo corpo de certificado sob um ARN existente. É uma operação legítima quando um certificado está perto de expirar, e o ACM a aceitará desde que a chave privada corresponda e a cadeia valide. O que ela não faz é rodar de novo a validação do momento de criação do ponto de extremidade, então a associação e o material por trás dela ficam como estavam quando o ponto de extremidade foi construído.

É por isso também que o sintoma soa como falha de rede. O handshake TLS falha ou reinicia antes de a autorização ser sequer avaliada, então grupos de segurança, rotas e regras de autorização parecem todos inocentes, e são.

A cadeia faz parte do certificado de cliente

A segunda metade da falha está no certificado de cliente, e é mais fácil de descartar. Um certificado de cliente precisa ser importado com a cadeia que o emitiu, mesmo que o formulário de importação mostre esse campo como opcional. Sem a cadeia, o ponto de extremidade não consegue construir um caminho do certificado de cliente até a CA raiz de cliente com que foi configurado, e a conexão termina em um reset suave que soa como um firewall derrubando pacotes. openssl verify -CAfile root-ca.pem client.crt responde a essa pergunta localmente em um segundo, e deveria ser o primeiro comando que você executa.

Reimportar com a cadeia é uma correção real para essa metade, e ainda assim não basta sozinha. Depois que o objeto no ACM mudou, o ponto de extremidade que mantém a associação antiga é a coisa errada contra a qual continuar testando. Os dois passos pertencem ao mesmo reparo, por isso a correção em duas partes não é contradição.

Recriar um ponto de extremidade é uma migração

Criar um ponto de extremidade substituto é uma migração, não uma nova tentativa, e tratá-lo como nova tentativa é como as equipes acabam com dois pontos de extremidade meio configurados. O novo ponto de extremidade recebe um novo ID e, a menos que você tenha planejado, um novo nome DNS para cada usuário. Mantenha o perfil de cliente apontando para um nome em vez de um endereço, para que a troca vire uma alteração de registro e não uma redistribuição.

A ordem que mantém isso seguro é curta: crie o novo ponto de extremidade com o mesmo CIDR, as mesmas sub-redes e as mesmas regras de autorização, exporte um perfil novo com aws ec2 export-client-vpn-client-configuration e verifique com um usuário. Só depois o ponto de extremidade antigo é retirado.

Retirar o ponto de extremidade antigo tem a sua própria ordem. Revogue os certificados de cliente que você pretendia retirar antes de apagá-lo, porque um ponto de extremidade novo que ainda confia na CA antiga continua aceitando certificados que você achava que tinham ido embora. Depois apague o ponto de extremidade antigo e remova as suas regras de autorização, para que um perfil desatualizado não consiga se reconectar a uma rede de destino que você achava fechada. Escreva o ID do ponto de extremidade antigo e os identificadores de associação no registro de mudanças, porque uma migração comparada com a memória é como um ponto de extremidade que funciona é reconstruído duas vezes.

Ordene o diagnóstico

Separe três falhas antes de mudar qualquer configuração. O cliente não consegue concluir o TLS, o cliente conclui o TLS e não está autorizado, ou o cliente conecta e não alcança um destino. A associação de certificado pertence à primeira, uma regra de autorização que não cobre o endereço do cliente pertence à segunda, e uma rota ou grupo de segurança pertence à terceira, onde recriar um ponto de extremidade é quase sempre o movimento errado.

Um ponto de extremidade que funcionou por meses e então parou, sem mudança de certificado ou política, é um caso à parte. Reconstruí-lo com configurações idênticas pode restaurar o serviço, mas isso é razão para manter a configuração reproduzível, não razão para reconstruir a cada incidente.

Mantenha quatro coisas sob controle de versão para que a próxima reconstrução seja um diff e não uma improvisação: os parâmetros do ponto de extremidade, os ARN do certificado e da cadeia, as regras de autorização e o CIDR do cliente. A documentação de autenticação do Client VPN lista qual certificado desempenha qual papel, algo que vale conferir antes de supor que um certificado é o problema. Se uma reimportação não muda nada e o ponto de extremidade continua reiniciando, a associação é a suspeita e a resposta é um ponto de extremidade novo construído com os parâmetros registrados. Se o ponto de extremidade de fato assume o novo objeto, a associação já estava correta e a falha está na cadeia do cliente ou na camada de autorização.