Ruotare una PSK di AWS VPN: quale tunnel cade e quando

Il tunnel cade nel momento in cui le due estremità non concordano sulla chiave precondivisa, e resta giù finché entrambi i lati non portano il nuovo valore. Questa parte è attesa: AWS tratta la modifica come un'interruzione del tunnel selezionato, e il peer non completerà IKE finché le chiavi differiscono. Ciò che sorprende è la seconda metà. L'altro tunnel non assorbe il traffico da solo a meno che abbiate verificato che possa portarlo. Ruotate in questo ordine e l'interruzione resta dentro un solo tunnel.

Cosa succede davvero quando la chiave cambia

ModifyVpnTunnelOptions riscrive le opzioni di un tunnel, identificato dal suo indirizzo IP esterno. Il tunnel viene abbattuto e ricostruito, quindi IKE e IPsec negoziano da zero con la nuova chiave. AWS dichiara che l'interruzione può durare diversi minuti, abbastanza perché un protocollo di routing se ne accorga. L'altro tunnel della stessa connessione non è toccato dalla chiamata.

C'è un secondo effetto da conoscere prima di inviare qualsiasi cosa. L'operazione di modifica prende l'intero insieme di opzioni del tunnel, quindi un campo che omettete viene riscritto con il suo valore predefinito. Se avevate regolato le durate della fase 1 o della fase 2, o le impostazioni di rilevamento del peer morto, passate i valori attuali nella stessa richiesta o pianificate di ripristinarli dopo.

Leggete prima i valori attuali, poi cambiate un solo campo. Questa sequenza è tutta la disciplina di questo compito.

Abbinate prima il tunnel AWS al peer giusto

La console etichetta i tunnel in base all'ordine, e il vostro dispositivo non usa quell'etichetta. Identificate il tunnel dal suo indirizzo IP esterno e abbinatelo alla sezione peer sul gateway cliente. Il tunnel 1 in una configurazione locale non è prova che stiate modificando il tunnel che AWS chiama tunnel 1.

Partite dalla connessione stessa, che elenca entrambi i tunnel e la chiave che ciascuno detiene ora:

aws ec2 describe-vpn-connections --vpn-connection-ids vpn-0123456789abcdef0 \
  --query "VpnConnections[0].Options.TunnelOptions[].[OutsideIpAddress,PreSharedKey]"

La chiave restituita è quella in uso in questo momento. Confrontatela con la configurazione del peer prima di cambiare qualsiasi cosa, perché una discrepanza già esistente spiega un tunnel che non è mai stato stabile.

Fate prima portare il traffico all'altro tunnel

Due tunnel in una connessione non provano che il vostro dispositivo li abbia configurati entrambi, che entrambi annuncino i prefissi che vi servono o che il traffico passi tra loro. Verificate la negoziazione del tunnel alternativo, le sue rotte e un flusso applicativo reale in entrambe le direzioni. Con BGP, un'adiacenza attiva è una prova utile ma non equivale a confermare i prefissi. Con routing statico, confermate come il gateway sceglie il percorso e cosa fa quando quello preferito scompare.

Se l'alternativa non può portare il carico, pianificate l'interruzione o riparate il tunnel alternativo prima di toccare la chiave. Una spia di stato su una pagina della console non è una promessa di servizio ininterrotto.

Ruotate un tunnel, poi verificate con traffico reale

Una volta dimostrato il percorso alternativo, la sequenza è breve. Annotate l'indirizzo del tunnel, il suo peer e le impostazioni non segrete, e mantenete un percorso di gestione verso il gateway che non dipenda dal tunnel che state per rompere.

1. Aggiornate il peer del gateway cliente per l'indirizzo esterno scelto, oppure preparate la modifica perché si applichi pochi secondi dopo la chiamata API.
2. Inviate la chiamata di modifica con la nuova chiave più le durate e i valori DPD attuali.
3. Aspettate che IKE e IPsec tornino, poi confermate le rotte e i prefissi richiesti.
4. Fate passare un flusso applicativo rappresentativo da quel tunnel e osservate entrambe le direzioni.

Il tunnel è inutilizzabile finché le estremità non concordano e finché AWS applica la modifica, quindi l'aggiornamento del peer deve seguire subito, non dopo pranzo. Solo quando il tunnel modificato porta traffico reale dovreste ripetere la procedura sull'altro.

Fermatevi se il ripristino o il routing sono ancora incerti dopo il primo tunnel. Due tunnel a metà funzionanti sono peggio di uno che sapete funzionare.

Quando il ripristino si blocca, leggete il lato IKE

Un tunnel che resta giù dopo che entrambe le estremità hanno la nuova chiave è di solito una discrepanza di policy che la rotazione ha rivelato, non creato. Le proposte, l'identità che il peer invia e i selettori di traffico devono tutti concordare con il lato AWS, e un valore che ha superato un tunnel consolidato può comunque essere rifiutato durante una nuova negoziazione. Leggete lo stato della negoziazione e il messaggio allegato prima di cambiare la chiave una seconda volta.

aws ec2 describe-vpn-connections --vpn-connection-ids vpn-0123456789abcdef0 \
  --query "VpnConnections[0].VgwTelemetry[].[OutsideIpAddress,Status,StatusMessage]"

Se il cambiamento va annullato, non ripristinate la vecchia chiave solo perché funzionava prima. Trattate una chiave compromessa come compromessa e correggete invece la negoziazione. Chiudete con entrambi i tunnel verificati e l'inventario dei segreti aggiornato perché ogni peer registri quale valore detiene, e tenete la documentazione sulle opzioni del tunnel AWS accanto al runbook.