Cal activar els registres de túnel d’AWS VPN en un túnel actiu?

Activar els registres d’activitat del túnel per a una VPN de lloc a lloc és un canvi petit que pot fer caure el túnel que està mesurant. AWS adverteix que activar el registre en un túnel existent el pot interrompre durant diversos minuts, així que la pregunta interessant no és com girar el senyal sinó en quin túnel girar-lo i quan. Tres condicions decideixen l’ordre: si l’altre túnel porta realment les rutes, si necessiteu esdeveniments de servei o esdeveniments BGP, i si el canvi passa per la consola o per l’API d’opcions del túnel. Equivoqueu-vos i acabareu amb una interrupció o amb un grup de registres ple de no-res.

Tres condicions decideixen l’ordre

Comenceu per la identitat d’allò que canvieu. Necessiteu l’ID de connexió VPN, la regió i l’adreça IP exterior del túnel concret, perquè cada paràmetre de registre d’aquesta funció és per túnel i no per connexió. Un canvi aplicat a l’adreça exterior equivocada és un canvi en un túnel que ningú no depurava.

La destinació és un grup de registres de CloudWatch a la mateixa regió, amb la retenció i la política d’accés que realment voleu. AWS recomana el prefix /aws/vendedlogs/ per a aquests grups perquè evita els límits de mida de la política de recursos que els noms senzills poden trobar. Un nom com /aws/vendedlogs/vpn/branch-a-activity només és il·lustratiu; el que importa és que el grup existeixi, que el rol de lliurament hi pugui escriure i que tots dos els gestioni qui posseeix la configuració de la VPN. El nom no atorga permisos, i un grup creat sense la política de lliurament produeix silenci en lloc d’un error.

Primera condició: un túnel redundant que realment porti trànsit

Aquesta és la condició que els equips salten. Dos túnels configurats no són prova que l’aplicació tingui un camí alternatiu utilitzable.

Abans de tocar un túnel, confirmeu que l’altre porta les rutes que importen: reviseu la taula d’encaminament del costat de la passarel·la del client i confirmeu que l’aplicació pot realment fer la commutació per error. La finestra d’interrupció d’AWS és de minuts, no de segons, i un túnel que només existeix sobre el paper converteix un canvi de diagnòstic en una caiguda. Si el camí redundant no està provat, programeu el canvi amb la mateixa cura que qualsevol altre canvi d’encaminament en lloc de tractar el registre com a passiu. Instrumenteu el túnel el comportament del qual intenteu explicar, no el que és més fàcil d’assolir.

Segona condició: registre d’activitat o registre BGP

Aquesta decideix què podreu llegir realment. Els registres d’activitat cobreixen esdeveniments de servei com les transicions d’estat d’IKE i IPsec i els missatges DPD, que és el que voleu quan el túnel no s’aixeca o no para de renovar claus. Els registres BGP són un flux separat amb els seus propis controls i responen una pregunta diferent: si les rutes es van intercanviar i retirar com s’esperava.

Activar el senyal d’activitat no és una petició per a tots els fluxos que el servei pot emetre. Si la sospita és l’encaminament, activeu tots dos; si la sospita és la negociació de la fase 1 o la fase 2, el flux d’activitat és el que ho mostrarà.

Cap dels dos fluxos no és una captura de paquets, i aquesta distinció resol més tiquets del que hauria. Els registres d’activitat i BGP us diuen què va fer el servei amb el túnel i la sessió, no què hi va enviar la vostra aplicació. Recórrer als registres del túnel per depurar un temps d’espera de l’aplicació és un error de categoria, i normalment costa una finestra d’interrupció abans que ningú ho noti. Trieu primer la pregunta, després el flux que la pot respondre.

Tercera condició: canvi per consola o API d’opcions del túnel

Si una persona fa un canvi puntual, el camí per la consola va bé: VPC console, Site-to-Site VPN connections, seleccioneu la connexió, Actions, Modify VPN tunnel options, trieu l’IP exterior, activeu Tunnel activity log, trieu el grup i el format de sortida, deseu dins de la finestra. Si la VPN es gestiona com a codi, el mateix clic és una deriva que reconciliareu més tard.

Per a l’automatització, la part de registre d’activitat de les opcions del túnel té una forma fixa: LogOptions que conté CloudWatchLogOptions amb LogEnabled, LogGroupArn i LogOutputFormat. Aquest bloc és un fragment, no una petició; modify-vpn-tunnel-options encara necessita l’ID de connexió i l’IP exterior del túnel, i la resta de paràmetres del túnel els ha de preservar qui posseeix la plantilla. El registre BGP fa servir les seves pròpies claus BgpLogEnabled, BgpLogGroupArn i BgpLogOutputFormat a la mateixa estructura. Torneu a llegir el canvi amb describe-vpn-connections en lloc de confiar que la crida s’ha aplicat.

Què us poden dir i què no els registres

Quan el primer túnel estigui fet i el camí previst estigui disponible, repetiu la mateixa seqüència controlada per al segon túnel si també necessiteu els seus registres. Un túnel a la vegada és tot el sentit.

Els registres arriben en fluxos identificats per la connexió i l’adreça exterior del túnel, així que correlacioneu amb aquesta identitat en lloc d’esperar que l’historial aparegui retroactivament. No existeix res abans del canvi, i cap espera no omple el buit. Si necessiteu una línia base, captureu l’estat actual del túnel i la taula d’encaminament abans del canvi perquè hi hagi alguna cosa amb què comparar.

Manteniu el grup de registres, la seva retenció, els seus permisos de lliurament i el bloc d’opcions del túnel al mateix inventari que la mateixa VPN, perquè són una sola configuració repartida en quatre llocs. El procediment d’AWS per activar els registres documenta el flux de treball per túnel i el seu avís d’interrupció, i val la pena llegir-lo abans del canvi i no després. Després verifiqueu per ordre: el túnel ha tornat, els registres apareixen al flux esperat i els registres responen la pregunta per la qual vau obrir el tiquet. Si el tercer falla, el problema era l’elecció del flux i no el registre.