Rodar uma PSK da AWS VPN: qual túnel cai, e quando

O túnel cai no momento em que as duas pontas discordam sobre a chave pré-compartilhada, e permanece em baixo até os dois lados carregarem o novo valor. Essa parte é esperada: a AWS trata a mudança como uma interrupção do túnel selecionado, e o par não concluirá o IKE enquanto as chaves diferirem. O que surpreende as pessoas é a segunda metade. O outro túnel não absorve o tráfego sozinho, a menos que você tenha verificado que ele consegue carregá-lo. Rode nesta ordem e a interrupção fica dentro de um túnel.

O que acontece realmente quando a chave muda

ModifyVpnTunnelOptions reescreve as opções de um túnel, identificado pelo seu endereço IP externo. O túnel é derrubado e reconstruído, então IKE e IPsec negociam do zero com a chave nova. A AWS informa que a interrupção pode durar vários minutos, o que é tempo suficiente para um protocolo de roteamento notar. O outro túnel da mesma conexão não é afetado pela chamada.

Há um segundo efeito que vale conhecer antes de enviar qualquer coisa. A operação de alteração pega o conjunto completo de opções do túnel, então um campo que você omitir é reescrito com o valor padrão. Se você ajustou os tempos de vida da fase 1 ou da fase 2, ou as configurações de detecção de par morto, passe os valores atuais na mesma solicitação ou planeje restaurá-los depois.

Leia primeiro os valores atuais e depois altere um único campo. Essa sequência é toda a disciplina desta tarefa.

Combine primeiro o túnel da AWS com o par correto

O console rotula os túneis por ordem, e o seu dispositivo não usa esse rótulo. Identifique o túnel pelo endereço IP externo e combine-o com a seção de par no gateway do cliente. O túnel 1 numa configuração local não é prova de que você está editando o túnel que a AWS chama de túnel 1.

Comece pela própria conexão, que lista os dois túneis e a chave que cada um tem agora:

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

A chave retornada é a que está em uso agora. Compare-a com a configuração do par antes de mudar qualquer coisa, porque uma divergência que já existe explica um túnel que nunca foi estável.

Deixe primeiro o outro túnel carregar o tráfego

Dois túneis numa conexão não provam que o seu dispositivo configurou ambos, que os dois anunciam os prefixos de que você precisa ou que o tráfego passa entre eles. Verifique a negociação do túnel alternativo, as suas rotas e um fluxo real de aplicação nos dois sentidos. Com BGP, uma adjacência ativa é uma prova útil, mas não é o mesmo que confirmar os prefixos. Com roteamento estático, confirme como o gateway escolhe o caminho e o que faz quando o preferido desaparece.

Se o alternativo não conseguir carregar a carga de trabalho, agende a interrupção ou repare o túnel alternativo antes de tocar na chave. Uma luz de estado numa página do console não é promessa de serviço ininterrupto.

Rode um túnel e depois verifique com tráfego real

Com o caminho alternativo provado, a sequência é curta. Anote o endereço do túnel, o seu par e as configurações que não são segredo, e mantenha um caminho de gestão até ao gateway que não dependa do túnel que você está prestes a quebrar.

1. Atualize o par do gateway do cliente para o endereço externo escolhido, ou prepare a mudança para entrar em vigor segundos após a chamada à API.
2. Envie a chamada de alteração com a chave nova, mais os tempos de vida e os valores DPD atuais.
3. Aguarde o regresso do IKE e do IPsec e depois confirme as rotas e os prefixos necessários.
4. Passe um fluxo de aplicação representativo por esse túnel e observe os dois sentidos.

O túnel é inutilizável enquanto as pontas discordam e enquanto a AWS aplica a alteração, por isso a atualização do par tem de seguir imediatamente e não depois do almoço. Só quando o túnel alterado carregar tráfego real é que deve repetir o procedimento no outro.

Pare se a recuperação ou o roteamento continuarem incertos após o primeiro túnel. Dois túneis a meio funcionar são piores do que um que você sabe que funciona.

Quando a recuperação encrava, leia o lado IKE

Um túnel que continua em baixo depois de as duas pontas terem a chave nova é geralmente uma divergência de política que a rotação expôs e não criou. As propostas, a identidade enviada pelo par e os seletores de tráfego têm todos de concordar com o lado da AWS, e um valor que sobreviveu a um túnel estabelecido ainda pode ser rejeitado durante uma nova negociação. Leia o estado da negociação e a mensagem associada antes de mudar a chave uma segunda vez.

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

Se a alteração tiver de ser anulada, não restaure a chave antiga só porque funcionava antes. Trate uma chave comprometida como comprometida e corrija antes a negociação. Termine com os dois túneis verificados e o inventário de segredos atualizado, para que cada par registe que valor tem, e mantenha a documentação das opções de túnel da AWS junto ao runbook.