Por qué reimportar un certificado de Client VPN exige un nuevo punto de enlace

Una conexión de Client VPN se rompe, el certificado en ACM se reemplaza y nada cambia. El objeto del certificado nunca fue lo que usaba el punto de enlace. Un punto de enlace guarda al crearse una asociación con un certificado, junto con la CA de cliente contra la que validará, el tipo de autenticación, las subredes y las reglas de autorización, y ninguna de esas asociaciones tiene una llamada de modificación que acepte un certificado de reemplazo. Sustituir los bytes detrás de un ARN es un cambio en el certificado, no en el punto de enlace que lo capturó.

El punto de enlace guarda referencias, no certificados

Merece la pena enunciar el mecanismo con precisión porque explica todo el fallo. create-client-vpn-endpoint toma el ARN de un certificado de servidor y el ARN de una cadena de certificados raíz de cliente, y el punto de enlace resultante conserva esas referencias junto con las opciones de autenticación como propiedades fijas. La superficie de la API no ofrece ninguna operación que cambie el certificado de servidor en un punto de enlace existente.

Puede confirmar la vinculación sin adivinar. aws ec2 describe-client-vpn-endpoints --client-vpn-endpoint-ids cvpn-endpoint-0123456789abcdef0 imprime el ARN del certificado, el ARN de la cadena raíz del cliente, el tipo de autenticación, el CIDR del cliente y las subredes asociadas, que es el conjunto completo de propiedades que tendría que reproducir. Ejecútelo antes y después de una reimportación y la salida no se mueve. Esa es la prueba de que la reimportación nunca iba a servir.

Por qué una reimportación no puede llegar al punto de enlace

Una reimportación escribe un cuerpo de certificado nuevo bajo un ARN existente. Es una operación legítima cuando un certificado está cerca de caducar, y ACM la aceptará siempre que la clave privada coincida y la cadena valide. Lo que no hace es volver a ejecutar la validación del momento de creación del punto de enlace, así que la asociación y el material que hay detrás siguen como estaban cuando se construyó el punto de enlace.

Por eso también el síntoma se lee como un fallo de red. El protocolo de enlace TLS falla o se reinicia antes de que la autorización llegue a evaluarse, así que los grupos de seguridad, las rutas y las reglas de autorización parecen inocentes, y lo son.

La cadena forma parte del certificado de cliente

La segunda mitad del fallo está en el certificado de cliente, y es más fácil de descartar. Un certificado de cliente debe importarse con la cadena que lo emitió, aunque el formulario de importación presente ese campo como opcional. Sin la cadena, el punto de enlace no puede construir una ruta desde el certificado de cliente hasta la CA raíz de cliente con la que se configuró, y la conexión termina en un reinicio suave que suena como un cortafuegos que descarta paquetes. openssl verify -CAfile root-ca.pem client.crt responde esa pregunta localmente en un segundo, y debería ser el primer comando que ejecute.

Reimportar con la cadena es una corrección real para esa mitad, y sigue sin ser suficiente por sí sola. Una vez que el objeto de ACM ha cambiado, el punto de enlace que conserva la asociación antigua es lo equivocado contra lo que seguir probando. Ambos pasos pertenecen a la misma reparación, por eso la corrección en dos partes no es una contradicción.

Recrear un punto de enlace es una migración

Crear un punto de enlace de reemplazo es una migración, no un reintento, y tratarlo como un reintento es como los equipos acaban con dos puntos de enlace a medio configurar. El punto de enlace nuevo recibe un ID nuevo y, salvo que lo haya planificado, un nombre DNS nuevo para cada usuario. Mantenga el perfil de cliente apuntando a un nombre en lugar de a una dirección, para que el cambio sea una modificación de registro y no una redistribución.

El orden que mantiene esto seguro es corto: cree el punto de enlace nuevo con el mismo CIDR, las mismas subredes y las mismas reglas de autorización, exporte un perfil nuevo con aws ec2 export-client-vpn-client-configuration y verifique con un usuario. Solo después baja el punto de enlace antiguo.

Retirar el punto de enlace antiguo tiene su propio orden. Revoque los certificados de cliente que pensaba retirar antes de borrarlo, porque un punto de enlace nuevo que todavía confía en la CA antigua sigue aceptando certificados que usted creía desaparecidos. Luego borre el punto de enlace antiguo y elimine sus reglas de autorización, para que un perfil obsoleto no pueda reconectarse a una red de destino que usted creía cerrada. Escriba el ID del punto de enlace antiguo y los identificadores de asociación en el registro de cambios, porque una migración comparada con la memoria es como un punto de enlace que funciona se reconstruye dos veces.

Ordene el diagnóstico

Separe tres fallos antes de cambiar cualquier configuración. El cliente no puede completar TLS, el cliente completa TLS y no está autorizado, o el cliente se conecta y no alcanza un destino. La asociación de certificado pertenece al primero, una regla de autorización que no cubre la dirección del cliente pertenece al segundo, y una ruta o un grupo de seguridad pertenece al tercero, donde recrear un punto de enlace casi siempre es el movimiento equivocado.

Un punto de enlace que funcionó durante meses y luego se detuvo, sin ningún cambio de certificado ni de política, es un caso aparte. Reconstruirlo con la misma configuración puede restaurar el servicio, pero eso es una razón para mantener la configuración reproducible, no una razón para reconstruirlo en cada incidente.

Mantenga cuatro cosas bajo control de versiones para que la próxima reconstrucción sea un diff y no una improvisación: los parámetros del punto de enlace, los ARN del certificado y de la cadena, las reglas de autorización y el CIDR del cliente. La documentación de autenticación de Client VPN enumera qué certificado desempeña qué papel, algo que conviene comprobar antes de suponer que un certificado es el problema. Si una reimportación no cambia nada y el punto de enlace sigue reiniciándose, la asociación es la sospechosa y la respuesta es un punto de enlace nuevo construido con los parámetros registrados. Si el punto de enlace sí recoge el objeto nuevo, la asociación ya era correcta y el fallo está en la cadena del cliente o en la capa de autorización.