Comment faire démarrer un tunnel Site-to-Site VPN par AWS
L'action de démarrage et l'action de temporisation DPD répondent à des questions différentes. Réglez celle qui fait initier AWS, puis vérifiez l'adresse du pair et la route de l'application.
Par défaut, un VPN Site-to-Site AWS attend que le customer gateway démarre la négociation. Ce défaut est un réglage, pas une loi, et le réglage s'appelle Startup action. Avant d'y toucher, séparez deux questions qui se confondent en permanence : qui établit le tunnel, et si les paquets qui vous intéressent ont une route à travers lui. Seule la première se trouve dans les options du tunnel.
Séparez l'action de démarrage de l'action de temporisation DPD
Deux options par tunnel régissent deux événements différents, et régler l'une ne dit rien de l'autre.
| Event | Option | Useful values |
|---|---|---|
| A new or modified VPN connection needs a tunnel | Startup action | add waits for the peer; start asks AWS to initiate |
| Dead peer detection times out | DPD timeout action | clear ends the session, restart reinitiates, none does nothing |
Si AWS doit monter un tunnel nouveau ou modifié, choisissez start. Si AWS doit aussi relancer la négociation après une temporisation DPD, configurez restart pour cet événement séparément. Aucune des deux options n'est une politique de réessai de l'application, et aucune n'est un intervalle de renouvellement de clé : DPD vérifie si le pair est vivant, tandis que le renouvellement remplace les security associations d'un tunnel actif.
Une application qui expire alors que le tunnel signale encore up souffre d'un problème de chemin de données. Raccourcir la temporisation DPD n'y remédiera pas et peut ajouter de l'agitation que vous devrez expliquer plus tard.
Vérifiez qu'AWS a où envoyer la négociation
L'initiation côté AWS ne fonctionne qu'avec IKEv2, et AWS a besoin de l'adresse publique du customer gateway pour savoir où envoyer la proposition. Le cas qui fait mal est une ressource customer gateway authentifiée par certificat créée sans adresse : la documentation AWS décrit la création d'une nouvelle ressource customer gateway avec l'adresse, puis la modification de la connexion VPN pour qu'elle pointe vers elle.
Un certificat prouve qui est le pair. Il ne dit pas à AWS où se trouve le pair, et ce sont deux exigences différentes. C'est pourquoi le remède est une nouvelle ressource customer gateway et non un nouveau certificat. Remplacer le certificat laisse AWS avec la même destination manquante.
Si le customer gateway se trouve derrière NAT, AWS a aussi besoin d'un responder identity configuré, IDr, pour que l'identité du pair corresponde à ce que l'appareil attend. Confirmez cette valeur et le chemin du pare-feu qui admet le trafic IKE avant d'accuser l'option que vous venez de changer. Choisir start ne peut pas faire accepter une proposition à un pair injoignable ou mal identifié.
Appliquez le changement à un seul tunnel et attendez-vous à une interruption
Une connexion VPN possède deux tunnels aux options indépendantes, alors confirmez celui que vous modifiez par son adresse extérieure. AWS permet de modifier un tunnel à la fois, et la connectivité sur le tunnel choisi peut être interrompue pendant plusieurs minutes.
- Sélectionnez la connexion Site-to-Site VPN et ouvrez Modify VPN tunnel options.
- Choisissez le tunnel par son adresse IP extérieure et confirmez sa version IKE et la ressource customer gateway.
- Réglez les actions de démarrage et DPD que vous voulez réellement, puis enregistrez pendant une fenêtre que vous maîtrisez.
- Confirmez que le tunnel modifié s'établit et vérifiez l'autre tunnel et le routage avant le changement suivant.
Un comportement mérite attention avant la maintenance. Avec l'initiation AWS activée, il n'y a pas de temporisation : AWS essaie jusqu'à ce que le tunnel monte, et il relance lorsque le customer gateway envoie un message delete-SA. Si vous coupez le pair volontairement, AWS continuera de frapper et les journaux du pair le montreront.
Vérifiez le chemin de l'application, pas seulement l'état du tunnel
Un tunnel qui signale up n'est pas la même chose qu'une requête qui fonctionne. Une fonction Lambda attachée à un VPC a encore besoin d'une route subnet vers le préfixe du client, de règles security group et network ACL qui autorisent le trafic, d'une résolution de noms qui renvoie la bonne adresse et d' un chemin de retour côté client.
Testez une fois avec une vraie requête depuis le contexte de l'application, puis lisez les flow logs en cas d'échec. Le trafic keepalive est une option légitime quand l'initiation AWS est désactivée et qu'un tunnel inactif a besoin de paquets pour rester debout, mais cela doit être une décision de surveillance que vous pouvez nommer, pas une boucle ping inexpliquée boulonnée à une fonction.
Choisissez d'abord qui établit le tunnel, puis diagnostiquez la panne restante à sa propre couche. La documentation AWS sur l'initiation couvre les exigences d'adresse, d'identité et de réessai plus en détail que les indications de la console.