État de Cloud VPN : lisez l’état de la ressource avant le journal IKE

Un tunnel Cloud VPN exécute deux cycles de vie à la fois, et ils ne sont pas sur la même horloge. La ressource doit être allouée et configurée avant de pouvoir négocier, et le protocole a ensuite sa propre séquence de messages IKE. Un champ d’état peut signaler le premier sans rien dire d’utile sur le second. Les lire comme une seule chose, c’est ainsi qu’une divergence de clé se retrouve accusée d’un retard de provisionnement.

Commencez par un objet tunnel et une fenêtre de temps.

Deux cycles de vie, un objet tunnel

Le cycle de vie de la ressource, c’est le fournisseur qui prépare le tunnel : adresses, configuration, capacité. Le cycle de vie du protocole commence dès que les deux pairs disposent d’assez de configuration pour échanger IKE_SA_INIT, puis IKE_AUTH, puis des associations de sécurité enfants. Un tunnel encore dans la première phase n’a pas échoué à l’authentification, car l’authentification n’a pas encore été tentée.

Cette distinction, c’est tout le problème. Le reste, c’est comment l’observer sans fusionner des messages sans rapport.

Lisez l’objet, pas le résumé de la console

Demandez à l’API les deux champs qui comptent et rien d’autre, pour que la réponse reste assez petite pour être lue à trois heures du matin : gcloud compute vpn-tunnels describe NAME --region REGION --format="yaml(status,detailedStatus)". Le champ status nomme l’étape du cycle de vie, et detailedStatus porte la raison lisible qui y est attachée. Un vidage complet de la configuration répond à d’autres questions et se colle plus difficilement dans un ticket. Les appels en lecture seule comme celui-ci ne peuvent pas modifier le tunnel, ce qui compte tant que l’incident est encore en cours.

Notez l’horodatage de l’appel à côté des valeurs, car les deux champs bougent.

ALLOCATING_RESOURCES n’est pas une divergence de clé

Quand le tunnel signale ALLOCATING_RESOURCES, le fournisseur assemble encore l’objet. Une divergence de clé prépartagée ne peut pas s’observer à cette étape, et un port du pair bloqué n’est pas davantage prouvé. Ce que vous pouvez vérifier, c’est le message détaillé, si le projet et le service semblent sains et si la configuration du tunnel est assez complète pour que le pair puisse être contacté. Remplacer le secret maintenant modifie une valeur qui n’a jamais été testée.

Attendez que l’état bouge avant de conclure quoi que ce soit sur la configuration.

ESTABLISHED, c’est le début des contrôles d’accès

Un tunnel établi signifie que l’IKE est terminé, pas que le trafic circule. Confirmez les routes que porte le tunnel et, lorsqu’un Cloud Router intervient, confirmez la session BGP et les préfixes qu’il a appris. Testez ensuite un échange applicatif autorisé, car une règle de pare-feu ou une route manquante peut bloquer le trafic à travers un tunnel parfaitement sain. Chacun de ces points est une observation distincte avec une correction distincte.

L’état vous dit quelle question poser ensuite. Il ne répond jamais à la question d’accès à votre place.

Corrélez un objet et une fenêtre de temps

Un ancien échec d’authentification dans le journal appartient à une tentative antérieure, sauf si son horodatage tombe dans la fenêtre que vous étudiez. Récupérez les journaux de la ressource tunnel pour les mêmes minutes que l’état que vous avez noté, et gardez les identifiants ensemble. Un événement IKE plus tardif peut montrer que la négociation a commencé alors que le message de console que vous fixez est déjà périmé.

Si le tunnel se rétablit avant que vous ayez collecté quoi que ce soit, dites-le. Une cause indéterminée est un meilleur compte rendu qu’une histoire assurée assemblée à partir de lignes sans rapport.

L’étape suivante a toujours la même forme : un objet, une fenêtre, une étape. Tout ce qui est plus large est un résumé, pas un diagnostic.