Per què tornar a importar un certificat de Client VPN necessita un punt final nou

Una connexió de Client VPN es trenca, el certificat de l’ACM se substitueix i no canvia res. L’objecte del certificat mai no va ser el que feia servir el punt final. En crear-se, un punt final desa una associació amb un certificat, juntament amb el CA de client contra el qual validarà, el tipus d’autenticació, les subxarxes i les regles d’autorització, i cap d’aquestes associacions no té una crida de modificació que accepti un certificat de substitució. Substituir els bytes que hi ha darrere d’un ARN és un canvi en el certificat, no en el punt final que el va capturar.

El punt final desa referències, no certificats

Val la pena formular el mecanisme amb precisió perquè explica tota la fallada. create-client-vpn-endpoint pren l’ARN d’un certificat de servidor i l’ARN d’una cadena de certificats d’arrel de client, i el punt final resultant conserva aquestes referències juntament amb les opcions d’autenticació com a propietats fixes. La superfície de l’API no ofereix cap operació que canviï el certificat de servidor en un punt final existent.

Podeu confirmar la vinculació sense endevinar. aws ec2 describe-client-vpn-endpoints --client-vpn-endpoint-ids cvpn-endpoint-0123456789abcdef0 imprimeix l’ARN del certificat, l’ARN de la cadena d’arrel del client, el tipus d’autenticació, el CIDR del client i les subxarxes associades, que és el conjunt complet de propietats que hauríeu de reproduir. Executeu-lo abans i després d’una reimportació i la sortida no es mou. Aquesta és la prova que la reimportació no havia d’ajudar mai.

Per què una reimportació no pot arribar al punt final

Una reimportació escriu un cos de certificat nou sota un ARN existent. És una operació legítima quan un certificat és a prop del venciment, i l’ACM l’acceptarà sempre que la clau privada coincideixi i la cadena validi. El que no fa és tornar a executar la validació del moment de creació del punt final, així que l’associació i el material que hi ha al darrere queden com eren quan es va construir el punt final.

Per això mateix el símptoma sembla una fallada de xarxa. La negociació TLS falla o es reinicia abans que l’autorització arribi a avaluar-se, així que els grups de seguretat, les rutes i les regles d’autorització semblen innocents, i ho són.

La cadena forma part del certificat de client

La segona meitat de la fallada és al certificat de client, i és més fàcil de descartar. Un certificat de client s’ha d’importar amb la cadena que el va emetre, encara que el formulari d’importació presenti aquest camp com a opcional. Sense la cadena, el punt final no pot construir un camí des del certificat de client fins al CA d’arrel de client amb què es va configurar, i la connexió acaba en un reinici suau que sembla un tallafoc que descarta paquets. openssl verify -CAfile root-ca.pem client.crt respon aquesta pregunta localment en un segon, i hauria de ser la primera ordre que executeu.

Reimportar amb la cadena és una correcció real per a aquesta meitat, i encara no és suficient per si sola. Un cop l’objecte de l’ACM ha canviat, el punt final que conserva l’associació antiga és la cosa equivocada contra la qual continuar provant. Els dos passos pertanyen a la mateixa reparació, i per això la correcció en dues parts no és una contradicció.

Recrear un punt final és una migració

Crear un punt final de substitució és una migració, no un reintent, i tractar-ho com un reintent és com els equips acaben amb dos punts finals mig configurats. El punt final nou obté un ID nou i, si no ho heu planificat, un nom DNS nou per a cada usuari. Mantingueu el perfil de client apuntant a un nom en lloc d’una adreça, perquè el canvi sigui una modificació de registre i no una redistribució.

L’ordre que ho manté segur és curt: creeu el punt final nou amb el mateix CIDR, les mateixes subxarxes i les mateixes regles d’autorització, exporteu un perfil nou amb aws ec2 export-client-vpn-client-configuration i verifiqueu-ho amb un usuari. Només després baixa el punt final antic.

Retirar el punt final antic té el seu propi ordre. Revogueu els certificats de client que volíeu retirar abans d’esborrar-lo, perquè un punt final nou que encara confia en el CA antic continua acceptant certificats que crèieu desapareguts. Després esborreu el punt final antic i traieu-ne les regles d’autorització, perquè un perfil antic no es pugui tornar a connectar a una xarxa de destinació que crèieu tancada. Escriviu l’ID del punt final antic i els identificadors d’associació al registre de canvis, perquè una migració comparada amb la memòria és com un punt final que funciona es reconstrueix dues vegades.

Ordeneu el diagnòstic

Separeu tres fallades abans de canviar cap configuració. El client no pot completar TLS, el client completa TLS i no està autoritzat, o el client es connecta i no pot arribar a una destinació. L’associació de certificat pertany a la primera, una regla d’autorització que no cobreix l’adreça del client pertany a la segona, i una ruta o un grup de seguretat pertany a la tercera, on recrear un punt final és gairebé sempre el moviment equivocat.

Un punt final que va funcionar durant mesos i després es va aturar, sense cap canvi de certificat ni de política, és un cas a part. Reconstruir-lo amb la mateixa configuració pot restaurar el servei, però això és una raó per mantenir la configuració reproduïble, no una raó per reconstruir-lo a cada incident.

Mantingueu quatre coses sota control de versions perquè la propera reconstrucció sigui un diff i no una improvisació: els paràmetres del punt final, els ARN del certificat i de la cadena, les regles d’autorització i el CIDR del client. La documentació d’autenticació de Client VPN llista quin certificat fa quin paper, cosa que val la pena comprovar abans d’assumir que un certificat és el problema. Si una reimportació no canvia res i el punt final encara es reinicia, l’associació és la sospitosa i la resposta és un punt final nou construït amb els paràmetres registrats. Si el punt final sí que recull l’objecte nou, l’associació ja era correcta i la fallada és a la cadena del client o a la capa d’autorització.