Ajouter un second LAN d'agence à un VPN site à site AWS n'exige pas une seconde association IPsec indépendante à l'intérieur de ce tunnel. La limite sur laquelle les gens trébuchent est réelle, mais plus étroite qu'elle n'en a l'air : AWS documente une paire IPsec SA unique par tunnel, une entrante et une sortante, et les deux tunnels d'une connexion reçoivent chacun leur propre paire. C'est une propriété du service, pas une règle selon laquelle IPsec protège un sous-réseau à la fois. La distinction compte surtout lorsqu'une passerelle client basée sur des politiques transforme chaque entrée de politique en sa propre association.

Commencez par la connexion, pas par la liste des LAN

Ouvrez la connexion dans la console et notez comment elle est routée. Une connexion statique porte les préfixes distants que vous avez déclarés. Une connexion BGP les apprend de la passerelle client.

Dans tous les cas, le tunnel est basé sur le routage. Ce qui y entre est décidé par les sélecteurs que votre équipement négocie, et non par le nombre de sous-réseaux que vous pouvez saisir dans un formulaire.

Surveillez ce que négocie la passerelle client

Un équipement basé sur des politiques peut transformer chaque entrée de politique en sa propre SA. Deux LAN signifient deux entrées, donc deux SA, et c'est là que la limite par tunnel commence à compter. Exigences de la passerelle client mettent précisément en garde contre ce comportement et suggèrent des règles consolidées sur ces équipements. Vérifiez les sélecteurs négociés plutôt que le nombre d'ACL sur la boîte.

L'équipement doit être configuré pour présenter les deux préfixes sous une seule politique, sinon l'extrémité distante ne peut tout simplement pas tenir le résultat.

Trois inventaires, tenus à part

Mélangez ces trois listes et chaque changement devient une supposition. Gardez-les en colonnes séparées et remplissez chacune pour votre propre réseau.

InventoryWhat belongs there
Required networks10.20.10.0/24 and 10.20.30.0/24, as presented after any deliberate translation
Protection agreementthe selectors the tunnel actually negotiated for those prefixes
Delivery and permissionVPC routes, return routes, security groups and any filtering

Seule la colonne du milieu est contrainte par la limite SA. La première colonne est un fait métier, et la troisième est ce qui fait fonctionner une application. Lisez les sélecteurs acceptés sur l'équipement plutôt que de déduire la couverture du nombre de lignes ACL que vous avez écrites.

Consolider sans élargir l'autorisation

Une route résumée est le moyen évident d'obtenir une seule entrée de politique, et c'est aussi ainsi qu'un ensemble protégé grandit discrètement. Un /20 qui couvre les deux /24 couvre aussi des adresses qu'aucune des deux agences n'utilise, et le tunnel les transportera volontiers. Si vous devez résumer, associez-le à un filtrage côté réception pour que l'espace supplémentaire soit refusé plutôt que simplement non annoncé. Un paquet refusé est une preuve. Une adresse non annoncée n'est qu'une absence de preuve.

Consolider la politique de protection, c'est modifier ce qui peut être chiffré. Ce n'est pas une autorisation d'accès et cela ne doit pas être traité comme telle.

Testez les deux LAN, puis conservez les deux tunnels

Après un changement coordonné, inspectez le périmètre de protection actif, puis exécutez une véritable application depuis chaque LAN. Le bon fonctionnement d'un sous-réseau ne prouve rien sur la couverture des sélecteurs du second, et encore moins sur son chemin de retour.

Conservez les deux tunnels dans la conception. Consolider la politique n'est pas une permission de supprimer la redondance, et un seul tunnel portant chaque LAN d'agence fait de la prochaine fenêtre de maintenance une panne.

Écrivez les sélecteurs négociés, les deux préfixes et les propriétaires de routes dans le même enregistrement de changement. Quand un troisième LAN arrive, cet enregistrement vous dit si vous ajoutez un sélecteur ou si vous repartez de zéro.

Articles similaires