Cloud VPN vers Cisco ASA : reconstruire après une divergence de proposition

NEGOTIATION_FAILURE sur un tunnel Cloud VPN avec un Cisco ASA à l'autre bout veut presque toujours dire une divergence de proposition ou de sélecteurs, et le premier fait utile est qu'aucune modification ne la corrigera. Cloud VPN fige la proposition IKE au moment où l'objet de tunnel est créé. Il n'existe aucun champ pour changer un algorithme sur place, donc la réparation consiste à supprimer puis recréer avec un point de départ consigné. Traitez-la comme une reconstruction et le travail devient une liste de vérification plutôt qu'un après-midi de suppositions.

Lisez l'échec avant de supprimer quoi que ce soit

Un échec de négociation est un problème de phase, et le journal du pair nomme généralement la phase. Un échec de la phase 1 signifie que les extrémités ne se sont pas accordées sur une proposition ou n'ont pas pu s'authentifier. Un échec de la phase 2 signifie que le tunnel est monté et que les sélecteurs protégés ne correspondaient pas. Ce sont des réparations différentes, et la ligne de journal vaut la peine d'être extraite avant que quelqu'un touche à une configuration.

L'échec écarte aussi des pistes. Ce n'est pas une route VPC, ni une règle de pare-feu sur l'interface du tunnel, ni un défaut de résolution de noms à l'intérieur du réseau. Les poursuivre produit des changements assurés qui ne peuvent pas modifier le résultat, et ils rendent la correction finale plus difficile à attribuer.

Capturez les deux configurations pendant qu'elles existent encore

Supprimer un tunnel prend une demi-minute et détruit la seule preuve dont vous disposiez. Avant cela, notez les sélecteurs local et distant, l'adresse du pair, qui détient le secret partagé, ainsi que la crypto map ou le profil IKEv2 de l'ASA. L'ASA répond à deux questions distinctes : ce qui est configuré et ce qui est actuellement monté :

show running-config crypto ikev2
show crypto ikev2 sa
show crypto ipsec sa | include local ident|remote ident|status

Côté Google, lisez l'objet de tunnel plutôt que le résumé de la console, car l'adresse du pair et les champs de sélecteur sont les valeurs que vous devez reproduire exactement :

gcloud compute vpn-tunnels describe tunnel-to-asa --region europe-west1 \
  --format="yaml(peerIp,localTrafficSelector,remoteTrafficSelector,ikeVersion,sharedSecret)"

Consignez ces valeurs dans le ticket avant la première suppression. La reconstruction ci-dessous ne fonctionne que parce que vous pouvez recréer le même objet avec une différence volontaire.

Les algorithmes sur lesquels un côté refuse de négocier

Cloud VPN ne choisit pas dans une gamme d'algorithmes IKEv1 comme le ferait un pair classique. Les paramètres de pair qu'il attend sont fixes : aes-cbc-128 pour le chiffrement, sha1-96 pour l'intégrité comme pour le PRF, groupe Diffie-Hellman 2, 36,600 secondes pour la phase 1 et 10,800 secondes pour la phase 2. La politique de l'ASA doit offrir exactement cet ensemble. Une seconde proposition sur l'ASA ne gêne pas tant que celle qui correspond figure aussi dans la liste.

IKEv2 laisse plus de marge aux deux côtés, mais les règles gardent la même forme : activez PFS, choisissez un groupe DH que le tunnel prend en charge et gardez la liste de propositions assez courte pour qu'une divergence soit évidente. Un pair ASA sur Cloud VPN implique aussi un routage statique, donc les préfixes protégés doivent être planifiés et listés plutôt que laissés à BGP.

Une durée de vie copiée depuis le modèle d'un autre fournisseur est le faux pas habituel ici. Google publie ces valeurs comme paramètres de pair obligatoires, alors appliquez-les ; une valeur plus courte n'est pas négociée à la hausse jusqu'à ce que veut l'ASA.

Supprimez, recréez et nettoyez l'ancien état

Supprimez le tunnel, pas la passerelle, et notez le nom que Cloud VPN attribue au remplacement, car les noms sont attribués et non réutilisés. Recréez-le avec les valeurs consignées et la même adresse de pair, puis ajoutez la proposition correspondante à la liste de politiques de l'ASA.

Nettoyez les associations de sécurité après la modification sur l'ASA et avant de lire le résultat. Un ASA peut continuer à proposer une politique périmée jusqu'à l'expiration de la SA en cours, si bien qu'une configuration correcte paraît cassée pendant toute la durée de l'ancienne durée de vie et que le veilleur conclut que la reconstruction a échoué alors qu'elle n'avait pas commencé :

clear crypto ikev2 sa
clear crypto ipsec sa

Vérifiez que la phase 1 monte avant de regarder la phase 2. Tant que la phase 1 est en bas, la proposition ou la clé pré-partagée est fausse, et le travail sur les sélecteurs n'y changera rien.

Les sélecteurs se répondent en miroir, puis les compteurs décident

La phase 2 ne fonctionne que lorsque les deux extrémités s'accordent sur les adresses protégées, et l'accord est en miroir et non partagé. Le sélecteur local de Google doit correspondre au sélecteur que l'ASA appelle distant, et le sélecteur distant de Google à ce que l'ASA appelle local. Un tunnel avec 0.0.0.0/0 d'un côté et un seul sous-réseau de l'autre passe la phase 1 puis échoue en phase 2 avec la même erreur d'en-tête. Aucun côté ne peut élargir la liste de l'autre.

Pour les sélecteurs basés sur des politiques, listez chaque paire de préfixes et gardez la liste dans le ticket. Un sous-réseau ajouté plus tard sur site exige une modification aux deux extrémités, car une nouvelle route sur l'ASA n'élargit pas un sélecteur, et le résultat est un tunnel monté qui ne fait passer le trafic que pour les préfixes présents le premier jour.

Terminez par un seul flux d'hôte à hôte et lisez les compteurs d'octets des deux côtés. Des compteurs qui montent sur l'ASA tout en restant plats sur Google signifient généralement que la réponse sort par une autre interface, ou que le sélecteur ne couvre pas le préfixe de retour. Consignez les algorithmes, les durées de vie, les sélecteurs et le nouveau nom du tunnel, car le prochain changement de proposition répète cette reconstruction et ces valeurs en font une tâche courte.