Rotar una PSK d'AWS VPN: quin túnel cau i quan

El túnel cau en el moment que els dos extrems no es posen d'acord sobre la clau prèviament compartida, i es manté caigut fins que tots dos costats porten el valor nou. Aquesta part és esperada: AWS tracta el canvi com una interrupció del túnel seleccionat, i el peer no acabarà IKE mentre les claus difereixin. El que sorprèn la gent és la segona meitat. L'altre túnel no absorbeix el trànsit per si sol tret que hàgiu comprovat que el pot portar. Roteu en aquest ordre i la interrupció es queda dins d'un túnel.

Què passa realment quan canvia la clau

ModifyVpnTunnelOptions reescriu les opcions d'un túnel, identificat per la seva adreça IP exterior. El túnel es desmunta i es reconstrueix, així que IKE i IPsec negocien des de zero amb la clau nova. AWS indica que la interrupció pot durar uns quants minuts, cosa prou llarga perquè un protocol d'encaminament la noti. L'altre túnel de la mateixa connexió no es toca amb la crida.

Hi ha un segon efecte que val la pena conèixer abans d'enviar res. L'operació de modificació pren el conjunt complet d'opcions del túnel, així que un camp que deixeu fora es reescriu amb el seu valor per defecte. Si havíeu ajustat les durades de la fase 1 o la fase 2, o la configuració de detecció de peer mort, passeu els valors actuals a la mateixa sol·licitud o planifiqueu restaurar-los després.

Primer llegiu els valors actuals i després canvieu un sol camp. Aquesta seqüència és tota la disciplina d'aquesta tasca.

Primer feu coincidir el túnel d'AWS amb el peer correcte

La consola etiqueta els túnels per ordre, i el vostre dispositiu no fa servir aquesta etiqueta. Identifiqueu el túnel per la seva adreça IP exterior i feu-lo coincidir amb la secció de peer de la passarel·la de client. El túnel 1 en una configuració local no és prova que estigueu editant el túnel que AWS anomena túnel 1.

Comenceu per la connexió mateixa, que llista tots dos túnels i la clau que cadascun té ara:

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

La clau que torna és la que s'utilitza ara mateix. Compareu-la amb la configuració del peer abans de canviar res, perquè una discrepància que ja existeix explica un túnel que mai no va ser estable.

Primer feu que l'altre túnel porti el trànsit

Dos túnels en una connexió no proven que el vostre dispositiu tingui tots dos configurats, que tots dos anunciïn els prefixos que necessiteu o que el trànsit es mogui entre ells. Comproveu la negociació del túnel alternatiu, les seves rutes i un flux d'aplicació real en tots dos sentits. Amb BGP, una adjacència activa és una evidència útil, però no és el mateix que confirmar els prefixos. Amb encaminament estàtic, confirmeu com la passarel·la tria el camí i què fa quan el preferit desapareix.

Si l'alternativa no pot portar la càrrega de treball, programeu la interrupció o reparau el túnel alternatiu abans de tocar la clau. Un llum d'estat en una pàgina de la consola no és una promesa de servei ininterromput.

Roteu un túnel i després verifiqueu amb trànsit real

Amb el camí alternatiu demostrat, la seqüència és curta. Anoteu l'adreça del túnel, el seu peer i la configuració no secreta, i manteniu un camí de gestió cap a la passarel·la que no depengui del túnel que esteu a punt de trencar.

1. Actualitzeu el peer de la passarel·la de client per a l'adreça exterior seleccionada, o prepareu el canvi perquè arribi segons després de la crida a l'API.
2. Envieu la crida de modificació amb la clau nova més les durades i els valors DPD actuals.
3. Espereu que IKE i IPsec tornin, i després confirmeu les rutes i els prefixos necessaris.
4. Feu passar un flux d'aplicació representatiu per aquest túnel i observeu tots dos sentits.

El túnel no és utilitzable mentre els extrems no es posen d'acord i mentre AWS aplica la modificació, així que l'actualització del peer ha de seguir immediatament, no després de dinar. Només quan el túnel canviat porti trànsit real hauríeu de repetir el procediment a l'altre.

Atureu-vos si la recuperació o l'encaminament encara són incerts després del primer túnel. Dos túnels mig funcionals són pitjor que un que sabeu que funciona.

Quan la recuperació s'encalli, llegiu el costat IKE

Un túnel que continua caigut després que tots dos extrems tinguin la clau nova sol ser una discrepància de política que la rotació va exposar, no crear. Les propostes, la identitat que envia el peer i els selectors de trànsit han de coincidir amb el costat d'AWS, i un valor que va sobreviure a un túnel establert encara es pot rebutjar durant una negociació nova. Llegiu l'estat de la negociació i el missatge que hi va adjunt abans de canviar la clau per segona vegada.

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

Si el canvi s'ha de desfer, no restaureu la clau antiga només perquè abans funcionava. Tracteu una clau compromesa com a compromesa i repareu la negociació en lloc d'això. Acabeu amb tots dos túnels verificats i l'inventari de secrets actualitzat perquè cada peer registri quin valor té, i tingueu la documentació d'opcions de túnel d'AWS al costat del runbook.