Deberías activar os rexistros de túnel de AWS VPN nun túnel activo?

Activar os rexistros de actividade do túnel para unha VPN de sitio a sitio é un cambio pequeno que pode derrubar o túnel que está a medir. AWS advirte de que activar o rexistro nun túnel existente pode interrompelo durante varios minutos, así que a pregunta interesante non é como xirar a bandeira senón en que túnel xirala e cando. Tres condicións deciden a orde: se o outro túnel transporta realmente as rutas, se necesitas eventos de servizo ou eventos BGP, e se o cambio pasa pola consola ou pola API de opcións do túnel. Se te equivocas, acabarás cunha interrupción ou cun grupo de rexistros cheo de nada.

Tres condicións deciden a orde

Empeza pola identidade do que estás a cambiar. Necesitas o ID de conexión VPN, a rexión e o enderezo IP exterior do túnel concreto, porque cada axuste de rexistro desta función é por túnel e non por conexión. Un cambio aplicado ao enderezo exterior equivocado é un cambio nun túnel que ninguén estaba depurando.

O destino é un grupo de rexistros de CloudWatch na mesma rexión, coa retención e a política de acceso que realmente queres. AWS recomenda o prefixo /aws/vendedlogs/ para estes grupos porque evita os límites de tamaño de política de recursos cos que os nomes simples poden atoparse. Un nome como /aws/vendedlogs/vpn/branch-a-activity é só ilustrativo; o que importa é que o grupo exista, que o rol de entrega poida escribir nel e que ambos os xestione quen posúe a configuración da VPN. O nome non concede permisos, e un grupo creado sen a política de entrega produce silencio en lugar dun erro.

Condición un: un túnel redundante que realmente leve tráfico

Esta é a condición que os equipos adoitan saltar. Dous túneles configurados non son proba de que a aplicación teña unha ruta alternativa utilizábel.

Antes de tocar un túnel, confirma que o outro leva as rutas que importan: revisa a táboa de enrutamento do lado da pasarela do cliente e confirma que a aplicación pode realmente conmutar por erro. A xanela de interrupción de AWS é de minutos, non de segundos, e un túnel que só existe sobre o papel converte un cambio de diagnóstico nunha caída. Se a ruta redundante non está probada, programa o cambio co mesmo coidado que calquera outro cambio de enrutamento en lugar de tratar o rexistro como pasivo. Instrumenta o túnel cuxo comportamento tentas explicar, non o que é máis doado de acadar.

Condición dous: rexistro de actividade ou rexistro BGP

Esta decide que vas poder ler realmente. Os rexistros de actividade cobren eventos de servizo como as transicións de estado de IKE e IPsec e as mensaxes DPD, que é o que queres cando o túnel non levanta ou non para de renovar claves. Os rexistros BGP son un fluxo á parte cos seus propios controis, e responden a unha pregunta distinta: se as rutas se intercambiaron e retiraron como se esperaba.

Activar a bandeira de actividade non é unha petición para todos os fluxos que o servizo pode emitir. Se a sospeita é o enrutamento, activa ambos; se a sospeita é a negociación da fase 1 ou da fase 2, o fluxo de actividade é o que o mostrará.

Ningún dos dous fluxos é unha captura de paquetes, e esa distinción resolve máis tickets do que debería. Os rexistros de actividade e BGP dinche que fixo o servizo co túnel e coa sesión, non que enviou a túa aplicación a través del. Recorrer aos rexistros do túnel para depurar un tempo de espera da aplicación é un erro de categoría, e normalmente custa unha xanela de interrupción antes de que ninguén o note. Escolle primeiro a pregunta, despois o fluxo que a pode responder.

Condición tres: cambio por consola ou API de opcións do túnel

Se unha persoa fai un cambio puntual, o camiño pola consola está ben: VPC console, Site-to-Site VPN connections, selecciona a conexión, Actions, Modify VPN tunnel options, escolle a IP exterior, activa Tunnel activity log, escolle o grupo e o formato de saída, garda dentro da xanela. Se a VPN se xestiona como código, o mesmo clic é unha deriva que reconciliarás máis tarde.

Para a automatización, a parte de rexistro de actividade das opcións do túnel ten unha forma fixa: LogOptions que contén CloudWatchLogOptions con LogEnabled, LogGroupArn e LogOutputFormat. Ese bloque é un fragmento, non unha petición; modify-vpn-tunnel-options aínda necesita o ID de conexión e a IP exterior do túnel, e o resto de axustes do túnel debe preservalos quen posúe o modelo. O rexistro BGP usa as súas propias claves BgpLogEnabled, BgpLogGroupArn e BgpLogOutputFormat na mesma estrutura. Volve ler o cambio con describe-vpn-connections en lugar de confiar en que a chamada se aplicou.

Que poden e que non poden dicirche os rexistros

Cando o primeiro túnel estea feito e a ruta prevista estea dispoñible, repite a mesma secuencia controlada para o segundo túnel se tamén necesitas os seus rexistros. Un túnel de cada vez é todo o sentido.

Os rexistros chegan en fluxos identificados pola conexión e o enderezo exterior do túnel, así que correlaciona con esa identidade en lugar de esperar que o historial apareza retroactivamente. Nada antes do cambio existe, e ningunha espera enche o oco. Se necesitas unha liña base, captura o estado actual do túnel e a táboa de enrutamento antes do cambio para que haxa algo co que comparar.

Mantén o grupo de rexistros, a súa retención, os seus permisos de entrega e o bloque de opcións do túnel no mesmo inventario que a propia VPN, porque son unha soa configuración repartida en catro sitios. O procedemento de AWS para activar os rexistros documenta o fluxo de traballo por túnel e o seu aviso de interrupción, e paga a pena lelo antes do cambio e non despois. Despois verifica por orde: o túnel volveu, os rexistros aparecen no fluxo esperado e os rexistros responden a pregunta pola que abriches o ticket. Se o terceiro falla, o problema era a elección do fluxo e non o rexistro.