Faut-il activer les journaux de tunnel AWS VPN sur un tunnel actif ?

Activer les journaux d’activité du tunnel pour un VPN de site à site est un petit changement qui peut faire tomber le tunnel qu’il mesure. AWS prévient que l’activation de la journalisation sur un tunnel existant peut l’interrompre pendant plusieurs minutes, aussi la question intéressante n’est pas comment basculer l’indicateur, mais sur quel tunnel le basculer et quand. Trois conditions décident de l’ordre : l’autre tunnel transporte-t-il réellement les routes, avez-vous besoin d’événements de service ou d’événements BGP, et le changement passe-t-il par la console ou par l’API des options de tunnel. Trompez-vous et vous terminerez soit avec une panne, soit avec un groupe de journaux plein de rien.

Trois conditions décident de l’ordre

Partez de l’identité de ce que vous modifiez. Il vous faut l’ID de connexion VPN, la région et l’adresse IP externe du tunnel concerné, car chaque réglage de journal de cette fonctionnalité est par tunnel et non par connexion. Un changement appliqué à la mauvaise adresse externe est un changement sur un tunnel que personne ne débogait.

La destination est un groupe de journaux CloudWatch dans la même région, avec la rétention et la politique d’accès que vous voulez réellement. AWS recommande le préfixe /aws/vendedlogs/ pour ces groupes, car il évite les limites de taille de politique de ressources que les noms simples peuvent rencontrer. Un nom comme /aws/vendedlogs/vpn/branch-a-activity n’est qu’illustratif ; l’important est que le groupe existe, que le rôle de livraison puisse y écrire et que les deux soient gérés par celui qui possède la configuration du VPN. Le nom n’accorde aucune permission, et un groupe créé sans la politique de livraison produit du silence plutôt qu’une erreur.

Première condition : un tunnel redondant qui porte vraiment du trafic

C’est la condition que les équipes sautent. Deux tunnels configurés ne prouvent pas que l’application dispose d’un chemin alternatif utilisable.

Avant de toucher à un tunnel, confirmez que l’autre porte les routes qui comptent : vérifiez la table de routage du côté de la passerelle client et confirmez que l’application peut réellement basculer. La fenêtre d’interruption d’AWS se compte en minutes, pas en secondes, et un tunnel qui n’existe que sur le papier transforme un changement de diagnostic en panne. Si le chemin redondant n’est pas prouvé, planifiez le changement avec le même soin que n’importe quel autre changement de routage au lieu de traiter la journalisation comme passive. Instrumentez le tunnel dont vous cherchez à expliquer le comportement, pas celui qui est plus facile d’accès.

Deuxième condition : journal d’activité ou journal BGP

Celle-ci décide de ce que vous pourrez réellement lire. Les enregistrements d’activité couvrent les événements de service tels que les transitions d’état IKE et IPsec et les messages DPD, ce que vous voulez lorsque le tunnel ne monte pas ou ne cesse de renouveler ses clés. Les enregistrements BGP sont un flux distinct avec ses propres contrôles, et ils répondent à une autre question : les routes ont-elles été échangées et retirées comme prévu.

Activer l’indicateur d’activité n’est pas une demande pour tous les flux que le service peut émettre. Si le soupçon porte sur le routage, activez les deux ; si le soupçon porte sur la négociation de la phase 1 ou de la phase 2, le flux d’activité est celui qui le montrera.

Aucun des deux flux n’est une capture de paquets, et cette distinction résout plus de tickets qu’elle ne devrait. Les enregistrements d’activité et BGP vous disent ce que le service a fait du tunnel et de la session, pas ce que votre application y a envoyé. Se tourner vers les journaux de tunnel pour déboguer un délai d’expiration d’application est une erreur de catégorie, et cela coûte généralement une fenêtre d’interruption avant que quiconque le remarque. Choisissez d’abord la question, puis le flux capable d’y répondre.

Troisième condition : changement par la console ou par l’API des options de tunnel

Si un humain effectue un changement ponctuel, le chemin par la console convient : VPC console, Site-to-Site VPN connections, sélectionnez la connexion, Actions, Modify VPN tunnel options, choisissez l’IP externe, activez Tunnel activity log, choisissez le groupe et le format de sortie, enregistrez dans la fenêtre. Si le VPN est géré comme du code, le même clic est une dérive que vous réconcilierez plus tard.

Pour l’automatisation, la partie journal d’activité des options de tunnel a une forme fixe : LogOptions contenant CloudWatchLogOptions avec LogEnabled, LogGroupArn et LogOutputFormat. Ce bloc est un fragment, pas une requête ; modify-vpn-tunnel-options a toujours besoin de l’ID de connexion et de l’IP externe du tunnel, et les autres réglages du tunnel doivent être préservés par celui qui possède le modèle. La journalisation BGP utilise ses propres clés BgpLogEnabled, BgpLogGroupArn et BgpLogOutputFormat dans la même structure. Relisez le changement avec describe-vpn-connections au lieu de croire que l’appel a été appliqué.

Ce que les enregistrements peuvent et ne peuvent pas vous dire

Une fois le premier tunnel terminé et le chemin prévu disponible, répétez la même séquence contrôlée pour le second tunnel si vous avez aussi besoin de ses journaux. Un tunnel à la fois, c’est tout l’intérêt.

Les enregistrements arrivent dans des flux identifiés par la connexion et l’adresse externe du tunnel, alors corrélez avec cette identité au lieu d’attendre que l’historique apparaisse rétroactivement. Rien avant le changement n’existe, et aucune attente ne comble le vide. Si vous avez besoin d’une base de référence, capturez l’état actuel du tunnel et la table de routage avant le changement pour avoir de quoi comparer.

Gardez le groupe de journaux, sa rétention, ses autorisations de livraison et le bloc d’options de tunnel dans le même inventaire que le VPN lui-même, car ils forment une seule configuration répartie sur quatre endroits. La procédure AWS d’activation des journaux documente le flux de travail par tunnel et son avertissement d’interruption, et elle vaut la peine d’être lue avant le changement plutôt qu’après. Vérifiez ensuite dans l’ordre : le tunnel est revenu, les enregistrements apparaissent dans le flux attendu et les enregistrements répondent à la question pour laquelle vous avez ouvert le ticket. Si le troisième échoue, le problème était le choix du flux et non la journalisation.