Deves ativar os registos de túnel da AWS VPN num túnel ativo?

Ativar os registos de atividade do túnel para uma VPN de site para site é uma alteração pequena que pode derrubar o túnel que está a medir. A AWS avisa que ativar o registo num túnel existente o pode interromper durante vários minutos, por isso a pergunta interessante não é como virar o sinalizador, mas em que túnel o virar e quando. Três condições decidem a ordem: se o outro túnel transporta mesmo as rotas, se precisas de eventos de serviço ou de eventos BGP, e se a alteração passa pela consola ou pela API de opções do túnel. Se errares isto, acabas com uma interrupção ou com um grupo de registos cheio de nada.

Três condições decidem a ordem

Começa pela identidade do que estás a alterar. Precisas do ID de ligação VPN, da região e do endereço IP externo do túnel específico, porque cada definição de registo nesta funcionalidade é por túnel e não por ligação. Uma alteração aplicada ao endereço externo errado é uma alteração num túnel que ninguém estava a depurar.

O destino é um grupo de registos do CloudWatch na mesma região, com a retenção e a política de acesso que realmente queres. A AWS recomenda o prefixo /aws/vendedlogs/ para estes grupos porque evita os limites de tamanho de política de recursos com que os nomes simples podem esbarrar. Um nome como /aws/vendedlogs/vpn/branch-a-activity é apenas ilustrativo; o que importa é que o grupo exista, que a função de entrega consiga escrever nele e que ambos sejam geridos por quem detém a configuração da VPN. O nome não concede permissões, e um grupo criado sem a política de entrega produz silêncio em vez de erro.

Condição um: um túnel redundante que realmente transporte tráfego

Esta é a condição que as equipas saltam. Dois túneis configurados não são prova de que a aplicação tenha um caminho alternativo utilizável.

Antes de tocar num túnel, confirma que o outro transporta as rotas que importam: verifica a tabela de encaminhamento do lado do gateway do cliente e confirma que a aplicação consegue mesmo comutar. A janela de interrupção da AWS é de minutos, não de segundos, e um túnel que só existe no papel transforma uma alteração de diagnóstico numa queda. Se o caminho redundante não estiver provado, agenda a alteração com o mesmo cuidado de qualquer outra alteração de encaminhamento, em vez de tratar o registo como passivo. Instrumenta o túnel cujo comportamento tentas explicar, não o que é mais fácil de alcançar.

Condição dois: registo de atividade ou registo BGP

Esta decide o que vais realmente conseguir ler. Os registos de atividade cobrem eventos de serviço como as transições de estado IKE e IPsec e as mensagens DPD, que é o que queres quando o túnel não levanta ou não pára de renovar chaves. Os registos BGP são um fluxo separado com os seus próprios controlos, e respondem a uma pergunta diferente: se as rotas foram trocadas e retiradas como esperado.

Ativar o sinalizador de atividade não é um pedido para todos os fluxos que o serviço pode emitir. Se a suspeita é o encaminhamento, ativa ambos; se a suspeita é a negociação da fase 1 ou da fase 2, o fluxo de atividade é o que o mostrará.

Nenhum dos fluxos é uma captura de pacotes, e essa distinção resolve mais bilhetes do que devia. Os registos de atividade e BGP dizem-te o que o serviço fez com o túnel e a sessão, não o que a tua aplicação enviou por ele. Recorrer aos registos do túnel para depurar um tempo limite da aplicação é um erro de categoria, e normalmente custa uma janela de interrupção antes de alguém reparar. Escolhe primeiro a pergunta, depois o fluxo que a consegue responder.

Condição três: alteração pela consola ou pela API de opções do túnel

Se uma pessoa faz uma alteração pontual, o caminho pela consola está bem: VPC console, Site-to-Site VPN connections, seleciona a ligação, Actions, Modify VPN tunnel options, escolhe o IP externo, ativa Tunnel activity log, escolhe o grupo e o formato de saída, guarda dentro da janela. Se a VPN for gerida como código, o mesmo clique é uma deriva que vais reconciliar mais tarde.

Para automação, a parte de registo de atividade das opções do túnel tem uma forma fixa: LogOptions que contém CloudWatchLogOptions com LogEnabled, LogGroupArn e LogOutputFormat. Esse bloco é um fragmento, não um pedido; modify-vpn-tunnel-options continua a precisar do ID de ligação e do IP externo do túnel, e as restantes definições do túnel têm de ser preservadas por quem detém o modelo. O registo BGP usa as suas próprias chaves BgpLogEnabled, BgpLogGroupArn e BgpLogOutputFormat na mesma estrutura. Relê a alteração com describe-vpn-connections em vez de confiar que a chamada foi aplicada.

O que os registos podem e não podem dizer-te

Quando o primeiro túnel estiver feito e o caminho previsto estiver disponível, repete a mesma sequência controlada para o segundo túnel se também precisares dos registos dele. Um túnel de cada vez é todo o sentido.

Os registos chegam em fluxos identificados pela ligação e pelo endereço externo do túnel, por isso correlaciona com essa identidade em vez de esperar que o histórico apareça retroativamente. Nada antes da alteração existe, e nenhuma espera preenche a lacuna. Se precisares de uma linha de base, captura o estado atual do túnel e a tabela de encaminhamento antes da alteração para haver algo com que comparar.

Mantém o grupo de registos, a sua retenção, as suas permissões de entrega e o bloco de opções do túnel no mesmo inventário que a própria VPN, porque são uma só configuração espalhada por quatro sítios. O procedimento da AWS para ativar registos documenta o fluxo de trabalho por túnel e o seu aviso de interrupção, e vale a pena lê-lo antes da alteração e não depois. Depois verifica por ordem: o túnel voltou, os registos aparecem no fluxo esperado e os registos respondem à pergunta pela qual abriste o bilhete. Se o terceiro falhar, o problema foi a escolha do fluxo e não o registo.