CIDR local et distant dans AWS VPN : quel côté est lequel ?

Vous ouvrez les options Site-to-Site VPN, voyez deux champs CIDR nommés local et distant, et vous tendez vers l'adresse que vous considérez comme locale : le VPC. C'est l'inverse de ce que l'API veut dire. Dans les options de connexion, LocalIpv4NetworkCidr désigne le côté passerelle client et RemoteIpv4NetworkCidr le côté AWS, car la connexion se construit depuis la passerelle client. La console ne le dit jamais tout haut, et rien ne rejette une inversion qui paraît plausible.

Partez de l'appel API, pas du libellé de la console

Lisez la référence des options de connexion une fois, en entier, et remarquez que chaque option est écrite du point de vue de la passerelle client. Ce n'est pas un hasard de nommage. Le tunnel est décrit tel qu'il apparaît à l'équipement qui le termine de votre côté, donc local désigne le réseau derrière votre passerelle et distant le réseau derrière la passerelle AWS. Les champs IPv4 comme IPv6 suivent la même règle.

Écrivez les deux libellés sur un post-it avant de saisir quoi que ce soit : côté client, côté AWS. Puis faites correspondre vos adresses à ces libellés.

Un exemple travaillé avec les rôles attachés

Supposons que le préfixe local soit 10.20.0.0/16 et le préfixe du VPC 10.60.0.0/16. Les options se lisent exactement comme les rôles le suggèrent, avec la plage locale dans le champ local :

{
  "LocalIpv4NetworkCidr": "10.20.0.0/16",
  "RemoteIpv4NetworkCidr": "10.60.0.0/16"
}

Donnez maintenant la même paire à la personne qui configure l'équipement pair et regardez le piège se refermer. Sur beaucoup de pare-feu, local désigne l'interface sur laquelle le tunnel se termine et distant l'extrémité opposée, ce qui est la correspondance inverse pour le côté AWS. Les deux personnes peuvent avoir raison et produire malgré tout un tunnel qui ne s'établit jamais, parce que les deux vocabulaires décrivent des extrémités différentes.

Refaites l'exercice sur papier dans la terminologie du pair, avec les deux CIDR et les deux libellés, avant de toucher au moindre équipement.

Les valeurs par défaut ne sont pas un choix de conception

La même référence indique 0.0.0.0/0 comme valeur par défaut pour les deux champs IPv4, avec des valeurs analogues pour IPv6. Voir ces valeurs dans une connexion existante indique que le champ n'a jamais été restreint, et non qu'une sortie internet a été configurée. La distribution des routes, la table de routage du sous-réseau et les contrôles de sécurité décident toujours de ce qui peut réellement traverser ; les valeurs CIDR décrivent seulement quelles plages le tunnel accepte de sélectionner.

Remplacer une valeur plus étroite par la valeur par défaut n'est donc pas une astuce de compatibilité à appliquer quand un tunnel se comporte mal. Cela élargit le sélecteur et laisse toutes les autres couches exactement comme elles étaient.

L'équipement pair utilise l'autre point de vue

Une fois le côté AWS clair, la configuration du pair est là où se concentre le reste de la confusion. Un équipement qui demande un réseau local et un réseau distant décrit sa propre interface comme locale : votre plage VPC va donc dans son champ distant et votre plage locale dans son champ local. S'il demande plutôt des sélecteurs de trafic par paires, vous écrivez explicitement les deux sens et les libellés importent moins que l'appariement.

Lisez l'aide des champs de l'équipement plutôt que le nom des champs. Les constructeurs réutilisent les deux mêmes mots pour trois concepts différents.

Vérifiez ensuite l'état du tunnel pour les deux phases, car un sélecteur incohérent apparaît généralement comme un échec de la seconde phase tandis que la première reste tranquillement établie.

Changez les options comme un changement, pas comme une documentation

Modifier les options de connexion d'un VPN en service peut interrompre le service : traitez donc l'opération comme une maintenance, avec une fenêtre, une valeur de retour arrière et une note indiquant qui est concerné. Relevez d'abord les options actuelles, y compris les deux champs CIDR et les options du tunnel, pour qu'un retour soit un collage et non une reconstruction.

Après le changement, vérifiez depuis le côté AWS et depuis le pair : une source de chaque plage joignant une destination de l'autre, dans les deux sens. Un seul ping depuis un côté ne prouve qu'un seul sélecteur.

Mettez ensuite à jour la documentation de la connexion en écrivant les rôles, pour que la personne suivante n'ait pas à redécouvrir que local signifie votre côté.