Rotar unha PSK de AWS VPN: que túnel cae e cando

O túnel cae no momento en que os dous extremos non coinciden sobre a clave precompartida, e segue caído ata que ambos os lados leven o valor novo. Esa parte é esperable: AWS trata o cambio como unha interrupción do túnel seleccionado, e o par non rematará IKE mentres as claves difiran. O que sorprende á xente é a segunda metade. O outro túnel non absorbe o tráfico por si só a menos que comprobase que pode levalo. Rote nesta orde e a interrupción queda dentro dun túnel.

Que ocorre realmente cando cambia a clave

ModifyVpnTunnelOptions reescribe as opcións dun túnel, identificado polo seu enderezo IP exterior. O túnel derrúbase e reconstrúese, así que IKE e IPsec negocian desde cero coa clave nova. AWS indica que a interrupción pode durar varios minutos, o suficiente para que un protocolo de encamiñamento o note. O outro túnel da mesma conexión non se ve afectado pola chamada.

Hai un segundo efecto que convén coñecer antes de enviar nada. A operación de modificación toma o conxunto completo de opcións do túnel, así que un campo que omita reescríbese co seu valor predeterminado. Se axustara as duracións da fase 1 ou da fase 2, ou os axustes de detección de par morto, pase os valores actuais na mesma solicitude ou planifique restauralos despois.

Lea primeiro os valores actuais e logo cambie un só campo. Esa secuencia é toda a disciplina desta tarefa.

Emparexe primeiro o túnel de AWS co par correcto

A consola etiqueta os túneles por orde, e o seu dispositivo non usa esa etiqueta. Identifique o túnel polo seu enderezo IP exterior e faga que coincida coa sección de par na pasarela de cliente. O túnel 1 nunha configuración local non é proba de que estea editando o túnel que AWS chama túnel 1.

Comece pola propia conexión, que enumera ambos os túneles e a clave que cada un ten agora:

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

A clave que devolve é a que se usa agora mesmo. Compárea coa configuración do par antes de cambiar nada, porque unha discrepancia que xa existe explica un túnel que nunca foi estable.

Faga primeiro que o outro túnel leve o tráfico

Dous túneles nunha conexión non demostran que o seu dispositivo teña ambos configurados, que ambos anuncien os prefixos que necesita ou que o tráfico se mova entre eles. Comprobe a negociación do túnel alternativo, as súas rutas e un fluxo de aplicación real en ambos os sentidos. Con BGP, unha adxacencia activa é unha proba útil, pero non é o mesmo que confirmar os prefixos. Con encamiñamento estático, confirme como escolle a ruta a pasarela e que fai cando desaparece a preferida.

Se o alternativo non pode levar a carga de traballo, programe a interrupción ou repare o túnel alternativo antes de tocar a clave. Unha luz de estado nunha páxina da consola non é unha promesa de servizo ininterrompido.

Rote un túnel e logo verifique con tráfico real

Coa ruta alternativa demostrada, a secuencia é curta. Anote o enderezo do túnel, o seu par e os axustes non secretos, e manteña unha ruta de xestión cara á pasarela que non dependa do túnel que está a piques de romper.

1. Actualice o par da pasarela de cliente para o enderezo exterior seleccionado, ou prepare o cambio para que chegue segundos despois da chamada á API.
2. Enhvíe a chamada de modificación coa clave nova máis as duracións e os valores DPD actuais.
3. Espere a que volvan IKE e IPsec e logo confirme as rutas e os prefixos necesarios.
4. Pase un fluxo de aplicación representativo por ese túnel e observe ambos os sentidos.

O túnel non é utilizábel mentres os extremos non coinciden e mentres AWS aplica a modificación, así que a actualización do par debe seguir de inmediato e non despois de xantar. Só cando o túnel cambiado leve tráfico real debería repetir o procedemento no outro.

Détase se a recuperación ou o encamiñamento seguen sendo incertos tras o primeiro túnel. Dous túneles a medio funcionar son peores que un que sabe que funciona.

Cando a recuperación se atasca, lea o lado IKE

Un túnel que segue caído despois de que ambos os extremos teñan a clave nova adoita ser unha discrepancia de política que a rotación expuxo, non creou. As propostas, a identidade que envía o par e os selectores de tráfico deben coincidir co lado de AWS, e un valor que sobreviviu a un túnel establecido aínda pode rexeitarse durante unha negociación nova. Lea o estado da negociación e a mensaxe adxunta antes de cambiar a clave por segunda vez.

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

Se hai que desfacer o cambio, non restaure a clave antiga só porque antes funcionaba. Trate unha clave comprometida como comprometida e arranxe a negociación no seu lugar. Termine con ambos os túneles verificados e o inventario de segredos actualizado para que cada par rexistre que valor ten, e manteña a documentación de opcións de túnel de AWS xunto ao runbook.