Limites de Cloud VPN que vous ne pouvez pas régler : durée de vie IKE et NAT du pair

Donnez à l’équipement distant une durée de vie de phase 1 de 24 heures et le tunnel Cloud VPN reste en panne, même si tout côté Google est correctement configuré. Le pair propose une valeur que le répondeur n’acceptera pas, donc la négociation échoue purement et simplement ou redémarre sans fin. Cloud VPN plafonne la phase 1 à 36,000 secondes, soit dix heures, et ce plafond n’est pas un réglage que vous pouvez relever. La modification appartient à l’équipement distant.

Le pair demande, le répondeur décide

IKE est un exercice d’appariement entre deux jeux de propositions. Le tunnel ne se forme que là où les jeux se recoupent dans les bornes que le répondeur accepte, et c’est pourquoi une durée hors plage ne produit aucun tunnel partiel. L’erreur courante est de traiter la configuration du pair comme une liste de souhaits plutôt que comme une proposition. Une intersection vide laisse le tunnel en panne, quel que soit le bien-fondé du routage et des sélecteurs.

Lisez l’état du tunnel lui-même avant d’ouvrir un incident, car l’état détaillé nomme généralement la phase qui a échoué :

gcloud compute vpn-tunnels describe office-tunnel \
  --region europe-west1 \
  --format="value(status,detailedStatus)"

Comparez ce qui revient avec l’ensemble pris en charge pour votre type de passerelle et votre version d’IKE, et notez les deux sélecteurs de trafic pendant que vous y êtes. Une divergence de sélecteur donne le même symptôme de tunnel en panne qu’une divergence d’algorithme, et contrairement à l’algorithme, c’est à vous de corriger celle-là.

36,000 secondes, c’est le plafond

La phase 1 s’arrête à 36,000 secondes. Un équipement réglé sur 86,400 demande quelque chose que le répondeur n’acceptera jamais, et réessayer ne le fera pas changer d’avis. Ramenez la proposition distante dans la plage et la même configuration s’établit ; l’asymétrie est toute la leçon, puisque vous pouvez abaisser votre valeur et non relever celle de Google.

Écrivez la valeur choisie dans les notes de conception. Sinon, l’ingénieur suivant refait l’expérience des 24 heures et se heurte au même mur.

L’ensemble pris en charge est publié par type de passerelle et version d’IKE dans la présentation de Cloud VPN, alors lisez la section correspondant à votre topologie plutôt qu’un guide IKE général.

Un tunnel qui tombe selon un horaire

La phase 2 se comporte différemment : quand les deux extrémités ne sont pas d’accord, le renouvellement des clés suit l’intervalle le plus court. Un pair qui traite la divergence comme fatale laisse tomber le tunnel à la place, si bien qu’une divergence peut ressembler à deux pannes sans rapport. Surveillez le rythme de renouvellement des clés, pas seulement la première connexion. Un tunnel qui monte puis retombe à cadence régulière est plus souvent une divergence de durée de vie qu’un défaut de routage.

Corrélez ces horodatages de chute avec les journaux du pair avant de modifier quoi que ce soit, car un changement de sélecteur ou de route peut imiter le même rythme. Si la cadence correspond au minuteur de phase 2, la cause est trouvée sans toucher à une proposition.

Les suites viennent du type de passerelle

Les suites de chiffrement et d’intégrité ne sont pas un profil par tunnel que vous modifiez comme strongSwan le permet. Vous les choisissez par type de passerelle et version d’IKE, et chercher un profil qui n’existe pas coûte un après-midi.

Un équipement ancien qui n’offre rien dans l’ensemble pris en charge laisse deux voies honnêtes : remplacer l’équipement, ou terminer sur une passerelle logicielle que vous contrôlez et router de là vers le VPC. Tout le reste est un contournement qui échouera à la prochaine revue.

Une adresse externe par équipement

L’adresse externe du pair doit correspondre un-pour-un à son adresse interne. Un pool PAT surchargé ne peut pas fonctionner, car plusieurs hôtes derrière une seule adresse publique ne laissent au répondeur aucun moyen de les démultiplexer. Là où plusieurs hôtes doivent partager une adresse, le tunnel doit se terminer quelque part qui puisse les distinguer.

Gardez aussi cette adresse externe stable. Déplacez l’équipement derrière un autre NAT et l’association casse alors que chaque proposition correspond toujours. Il vaut la peine de noter quelles valeurs sont à Google et lesquelles sont à vous : les durées de vie, les suites et le NAT un-pour-un sont fixes de leur côté, tandis que les propositions, les sélecteurs, le routage et les priorités BGP sont les vôtres.