Faire tourner une PSK AWS VPN : quel tunnel tombe, et quand

Le tunnel tombe à l'instant où les deux extrémités ne sont plus d'accord sur la clé pré-partagée, et il reste en panne tant que les deux côtés ne portent pas la nouvelle valeur. Cette partie est attendue : AWS traite le changement comme une interruption du tunnel sélectionné, et le pair ne terminera pas IKE tant que les clés diffèrent. Ce qui surprend, c'est la seconde moitié. L'autre tunnel n'absorbe pas le trafic de lui-même, sauf si vous avez vérifié qu'il peut le porter. Faites tourner dans cet ordre et la panne reste à l'intérieur d'un tunnel.

Ce qui se passe réellement quand la clé change

ModifyVpnTunnelOptions réécrit les options d'un tunnel, identifié par son adresse IP externe. Le tunnel est détruit puis reconstruit, donc IKE et IPsec négocient de zéro avec la nouvelle clé. AWS indique que l'interruption peut durer plusieurs minutes, ce qui suffit à un protocole de routage pour le remarquer. L'autre tunnel de la même connexion n'est pas touché par l'appel.

Il y a un second effet à connaître avant d'envoyer quoi que ce soit. L'opération de modification reprend l'ensemble complet des options du tunnel, donc un champ que vous omettez est réécrit avec sa valeur par défaut. Si vous avez ajusté les durées de vie de la phase 1 ou de la phase 2, ou les réglages de détection de pair mort, passez les valeurs actuelles dans la même requête ou prévoyez de les restaurer ensuite.

Lisez d'abord les valeurs actuelles, puis changez un seul champ. Cette séquence est toute la discipline de cette tâche.

Associez d'abord le tunnel AWS au bon pair

La console étiquette les tunnels par ordre, et votre équipement n'utilise pas cette étiquette. Identifiez le tunnel par son adresse IP externe et associez-le à la section de pair sur la passerelle client. Le tunnel 1 dans une configuration locale ne prouve pas que vous modifiez le tunnel qu'AWS appelle tunnel 1.

Partez de la connexion elle-même, qui liste les deux tunnels et la clé que chacun détient actuellement :

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

La clé renvoyée est celle utilisée en ce moment. Comparez-la à la configuration du pair avant de changer quoi que ce soit, car une divergence déjà présente explique un tunnel qui n'a jamais été stable.

Faites d'abord porter le trafic par l'autre tunnel

Deux tunnels dans une connexion ne prouvent pas que votre équipement a configuré les deux, que les deux annoncent les préfixes dont vous avez besoin, ni que le trafic circule entre eux. Vérifiez la négociation du tunnel de secours, ses routes et un flux applicatif réel dans les deux sens. Avec BGP, une adjacence active est une preuve utile, mais ce n'est pas la même chose que confirmer les préfixes. En routage statique, confirmez comment la passerelle choisit le chemin et ce qu'elle fait quand le chemin préféré disparaît.

Si le secours ne peut pas porter la charge, planifiez la panne ou réparez le tunnel de secours avant de toucher à la clé. Un voyant d'état sur une page de console n'est pas une promesse de service ininterrompu.

Faites tourner un tunnel, puis vérifiez avec du trafic réel

Une fois le chemin de secours prouvé, la séquence est courte. Notez l'adresse du tunnel, son pair et les réglages non secrets, et gardez un chemin d'administration vers la passerelle qui ne dépend pas du tunnel que vous êtes sur le point de casser.

1. Mettez à jour le pair de la passerelle client pour l'adresse externe choisie, ou préparez le changement pour qu'il s'applique quelques secondes après l'appel API.
2. Envoyez l'appel de modification avec la nouvelle clé, plus les durées de vie et les valeurs DPD actuelles.
3. Attendez le retour d'IKE et d'IPsec, puis confirmez les routes et les préfixes requis.
4. Faites passer un flux applicatif représentatif par ce tunnel et surveillez les deux sens.

Le tunnel est inutilisable tant que les extrémités ne sont pas d'accord et tant qu'AWS applique la modification, donc la mise à jour du pair doit suivre immédiatement, et non après le déjeuner. Ne répétez la procédure sur l'autre tunnel que lorsque le tunnel modifié porte du trafic réel.

Arrêtez-vous si la reprise ou le routage restent incertains après le premier tunnel. Deux tunnels à moitié fonctionnels valent moins qu'un seul dont vous savez qu'il fonctionne.

Quand la reprise bloque, lisez le côté IKE

Un tunnel qui reste en panne alors que les deux extrémités détiennent la nouvelle clé est généralement une divergence de politique que la rotation a révélée plutôt que créée. Les propositions, l'identité envoyée par le pair et les sélecteurs de trafic doivent tous s'accorder avec le côté AWS, et une valeur qui a survécu à un tunnel établi peut encore être rejetée lors d'une nouvelle négociation. Lisez l'état de la négociation et le message qui y est joint avant de changer la clé une seconde fois.

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

S'il faut annuler le changement, ne restaurez pas l'ancienne clé simplement parce qu'elle fonctionnait avant. Traitez une clé compromise comme compromise et corrigez plutôt la négociation. Terminez avec les deux tunnels vérifiés et l'inventaire des secrets à jour pour que chaque pair consigne la valeur qu'il détient, et gardez la documentation des options de tunnel AWS à côté du runbook.