strongSwan sur EC2 : faire router la charge de travail par le VPC

Le tunnel est monté, l'instance de passerelle peut joindre le réseau distant, et l'instance d'application juste à côté n'atteint rien. Rien n'est cassé. Le test qui a réussi provenait de l'hôte VPN, et il n'a jamais demandé si cet hôte pouvait transporter une autre adresse source à travers la même relation IPsec. Ce guide comble cette lacune en quatre étapes, dans l'ordre qui garde chaque échec visible.

Écrivez d'abord les quatre adresses

Chaque étape ci-dessous s'y réfère, alors renseignez-les pour votre propre compte avant de toucher à une table de routage.

VPC:             10.60.0.0/16
Gateway subnet:  10.60.1.0/24, gateway ENI address 10.60.1.10
Workload subnet: 10.60.2.0/24, application address 10.60.2.20
Remote network:  10.90.0.0/24

L'exemple suppose une connexion IPsec basée sur des politiques approuvée et fonctionnelle, ainsi qu'un flux qui préserve la source. Ce n'est pas un client d'accès distant NATé empruntant une adresse attribuée, et cette différence décide si les sélecteurs doivent changer.

Étape 1 : donner une route au sous-réseau de charge

La table de routage réellement associée au sous-réseau de charge a besoin d'un chemin vers le préfixe distant pointant vers l'interface réseau de la passerelle. Une route invitée installée à l'intérieur de l'instance n'est pas une entrée dans cette table de routage AWS, et aucune configuration strongSwan, aussi poussée soit-elle, n'en créera une.

Les recommandations d'AWS sur le routage par appliance décrivent les cibles d'interface réseau et l'exigence de vérification source/destination de l'instance qui transfère. Limitez ce changement de vérification au rôle de passerelle et laissez les instances d'application ordinaires tranquilles.

Ne remplacez pas la route locale du VPC ni chaque entrée existante pour faire de la place à un réseau approuvé. Inspectez ce qui est associé et actif plutôt que ce qu'affiche une page de console pour une table de routage que personne n'utilise. Deux tables qui se ressemblent peuvent avoir des associations différentes. Celle qui compte est celle à laquelle le sous-réseau de charge est rattaché.

Étape 2 : activer le transfert sur l'invité

sysctl -w net.ipv4.ip_forward=1
# persist in /etc/sysctl.d/ and re-apply after reboot

Le noyau doit transférer, et le pare-feu de l'hôte doit autoriser le transit. Ajoutez les règles de transfert prévues pour les préfixes de charge et distants au lieu de tout accepter, et confirmez que le sous-réseau de passerelle conserve une route de transport utilisable pour son propre trafic.

Les groupes de sécurité sont là où cette étape bloque généralement. Un intergiciel n'hérite pas du comportement de référence des groupes de sécurité de la communication directe entre instances, donc une règle copiée d'un exemple de Client VPN géré peut ne jamais correspondre. Vérifiez le groupe de sécurité et l'ACL de sous-réseau sur le chemin réel, dans les deux sens.

Étape 3 : élargir les sélecteurs aux vraies sources

Une politique qui ne couvre que 10.60.1.10/32 côté AWS explique un succès provenant de la passerelle sans couvrir 10.60.2.20. Une route vers la destination distante n'élargit pas un sélecteur de trafic, et c'est la seconde moitié de la même surprise.

swanctl --list-sas
# read the installed CHILD-SA local and remote traffic selectors

Si la conception retenue protège tout le VPC, les deux pairs doivent accepter 10.60.0.0/16 et 10.90.0.0/24. Si elle protège une seule charge, utilisez délibérément ce préfixe plus étroit. Dans tous les cas, inspectez la politique CHILD-SA installée, car une configuration que vous avez modifiée et un pair qui l'a restreinte autrement ne sont pas le même accord.

Le site distant doit aussi router les réponses des sources VPC préservées via la passerelle IPsec prévue. Conservez l'exemption NAT prise en charge pour le trafic protégé là où d'autres règles de NAT source existent ; traduire une charge non approuvée en une adresse d'hôte autorisée est un autre contrat d'identité, pas un raccourci vers l'accès voulu.

Étape 4 : vérifier, puis revenir en arrière si nécessaire

Testez depuis la charge elle-même avec une opération applicative autorisée et nouvelle, puis répétez avec une destination qui doit être exclue. Notez l'adresse source que voit le service distant et le chemin de retour qu'il utilise. Un ping de la passerelle ou un statut IKE vert n'est pas ce test.

Si la charge échoue encore alors que la passerelle fonctionne, remontez les étapes dans l'ordre : sélecteur, puis transfert et groupes de sécurité, puis la table de routage associée. Chacune a un symptôme distinct, et deviner saute celle qui est réellement en cause.

Le retour arrière inverse le même ordre. Supprimez la route du sous-réseau de charge en dernier, après avoir restauré les sélecteurs précédents, afin de ne pas laisser un sous-réseau pointer vers une passerelle qui ne protège plus ses sources. L'auto-hébergement peut servir plus que l'hôte de passerelle lorsque ces contrats tiennent, et le VPN Site-to-Site géré par AWS est un modèle d'exploitation différent où strongSwan peut se trouver du côté de la passerelle client.