Perché reimportare un certificato Client VPN richiede un nuovo endpoint
Un endpoint Client VPN lega il proprio certificato alla creazione. Reimportare l’oggetto ACM non cambia quel legame, quindi il ripristino richiede un nuovo endpoint.
Una connessione Client VPN cade, il certificato in ACM viene sostituito e nulla cambia. L’oggetto certificato non è mai stato ciò che l’endpoint usava. Un endpoint memorizza alla creazione un’associazione a un certificato, insieme alla CA client contro cui convaliderà, al tipo di autenticazione, alle sottoreti e alle regole di autorizzazione, e nessuna di queste associazioni ha una chiamata di modifica che accetti un certificato sostitutivo. Sostituire i byte dietro un ARN è un cambiamento del certificato, non dell’endpoint che lo ha catturato.
L’endpoint memorizza riferimenti, non certificati
Vale la pena enunciare il meccanismo con precisione perché spiega l’intero guasto. create-client-vpn-endpoint prende un ARN di certificato server e un ARN di catena di certificati radice client, e l’endpoint risultante conserva quei riferimenti insieme alle opzioni di autenticazione come proprietà fisse. La superficie dell’API non offre alcuna operazione che scambi il certificato server su un endpoint esistente.
Puoi confermare l’associazione senza indovinare. aws ec2 describe-client-vpn-endpoints --client-vpn-endpoint-ids cvpn-endpoint-0123456789abcdef0 stampa l’ARN del certificato, l’ARN della catena radice client, il tipo di autenticazione, il CIDR client e le sottoreti associate, cioè l’insieme completo delle proprietà che dovresti riprodurre. Eseguilo prima e dopo una reimportazione e l’output non si muove. È la prova che la reimportazione non avrebbe mai aiutato.
Perché una reimportazione non può raggiungere l’endpoint
Una reimportazione scrive un nuovo corpo di certificato sotto un ARN esistente. È un’operazione legittima quando un certificato è vicino alla scadenza, e ACM la accetterà finché la chiave privata corrisponde e la catena convalida. Ciò che non fa è rieseguire la convalida del momento di creazione dell’endpoint, quindi l’associazione e il materiale dietro restano com’erano quando l’endpoint è stato costruito.
Ecco perché il sintomo si legge come un guasto di rete. La stretta di mano TLS fallisce o si resetta prima ancora che l’autorizzazione venga valutata, quindi i gruppi di sicurezza, le rotte e le regole di autorizzazione sembrano tutti innocenti, e lo sono.
La catena fa parte del certificato client
La seconda metà del guasto è nel certificato client, ed è più facile liquidarla. Un certificato client deve essere importato con la catena che lo ha emesso, anche se il modulo di importazione presenta quel campo come facoltativo. Senza la catena l’endpoint non può costruire un percorso dal certificato client alla CA radice client con cui è stato configurato, e la connessione finisce in un reset morbido che suona come un firewall che scarta pacchetti. openssl verify -CAfile root-ca.pem client.crt risponde a quella domanda localmente in un secondo, e dovrebbe essere il primo comando che esegui.
Reimportare con la catena è una correzione reale per quella metà, e da sola non basta ancora. Una volta che l’oggetto ACM è cambiato, l’endpoint che conserva la vecchia associazione è la cosa sbagliata su cui continuare a testare. Entrambi i passaggi appartengono alla stessa riparazione, per questo la correzione in due parti non è una contraddizione.
Ricreare un endpoint è una migrazione
Creare un endpoint sostitutivo è una migrazione, non un nuovo tentativo, e trattarlo come un nuovo tentativo è il modo in cui i team finiscono con due endpoint a metà configurazione. Il nuovo endpoint ottiene un nuovo ID e, se non l’hai pianificato, un nuovo nome DNS per ogni utente. Tieni il profilo client puntato a un nome invece che a un indirizzo, così lo scambio diventa una modifica di record e non una ridistribuzione.
L’ordine che tiene al sicuro tutto questo è breve: crea il nuovo endpoint con lo stesso CIDR, le stesse sottoreti e le stesse regole di autorizzazione, esporta un profilo fresco con aws ec2 export-client-vpn-client-configuration, e verifica con un utente. Solo dopo l’endpoint vecchio viene dismesso.
La dismissione dell’endpoint vecchio ha un suo ordine. Revoca i certificati client che intendevi ritirare prima di eliminarlo, perché un nuovo endpoint che si fida ancora della vecchia CA continua ad accettare certificati che credevi spariti. Poi elimina l’endpoint vecchio e rimuovi le sue regole di autorizzazione, così un profilo obsoleto non può riconnettersi a una rete di destinazione che credevi chiusa. Scrivi l’ID dell’endpoint vecchio e gli identificatori di associazione nel registro delle modifiche, perché una migrazione confrontata con la memoria è il modo in cui un endpoint funzionante viene ricostruito due volte.
Ordina la diagnosi
Separa tre guasti prima di cambiare qualsiasi configurazione. Il client non riesce a completare TLS, il client completa TLS e non è autorizzato, oppure il client si connette e non raggiunge una destinazione. L’associazione del certificato appartiene al primo, una regola di autorizzazione che non copre l’indirizzo del client appartiene al secondo, e una rotta o un gruppo di sicurezza appartiene al terzo, dove ricreare un endpoint è quasi sempre la mossa sbagliata.
Un endpoint che ha funzionato per mesi e poi si è fermato, senza alcun cambiamento di certificato o di policy, è un caso a sé. Ricostruirlo con impostazioni identiche può ripristinare il servizio, ma è una ragione per mantenere la configurazione riproducibile, non una ragione per ricostruire a ogni incidente.
Tieni quattro cose sotto controllo di versione perché la prossima ricostruzione sia un diff e non un’improvvisazione: i parametri dell’endpoint, gli ARN del certificato e della catena, le regole di autorizzazione e il CIDR client. La documentazione sull’autenticazione di Client VPN elenca quale certificato svolge quale ruolo, cosa che vale la pena controllare prima di dare per scontato che un certificato sia il problema. Se una reimportazione non cambia nulla e l’endpoint continua a resettarsi, l’associazione è la sospetta e la risposta è un nuovo endpoint costruito dai parametri registrati. Se l’endpoint riprende davvero il nuovo oggetto, l’associazione era già corretta e il guasto sta nella catena client o nel livello di autorizzazione.