openswan problème de routage pour plusieurs sous-réseaux

Lorsque vous utilisez leftsubnets vous devez utiliser rightsubnets , pas rightsubnet . Comme indiqué sur le site http://linux.die.net/man/5/ipsec.conf :

Si les deux a leftsubnets= y rightsubnets= est défini, toutes les combinaisons de tunnels de sous-réseau seront instanciées.

Cela est dû à une erreur dans la manière dont l'implémentation d'IPSec par AWS gère les SPI (Security Parameters Indices). Vous trouverez des informations détaillées à ce sujet sur le site site web de libreswan mais le résultat est que libreswan traite les deux plages en établissant deux tunnels (dans votre cas, probablement aws-vpc/1x1 y aws-vpc/1x2 ). OpenSWAN et StrongSWAN font de même.

Chacun de ces tunnels possède sa propre SA (association de sécurité), identifiée par une paire de SPI, l'une pour le trafic que vous envoyez (votre SPI) et l'autre pour le trafic qu'Amazon envoie (leur SPI). Amazon, bien qu'ayant établi son SPI #1 pour le tunnel qui se présente en premier, remplace avec SPI #2 lorsque le deuxième tunnel est mis en place (au lieu de garder SPI #1 pour le premier tunnel, et d'utiliser SPI #2 uniquement pour le deuxième tunnel, comme cela devrait être le cas). Le trafic est envoyé à AWS par le tunnel 1 en utilisant votre SPI #1, mais Amazon crypte les réponses avec leur SPI #2, ce qui entraîne naturellement l'échec du décryptage du trafic de votre côté.

C'est pourquoi le premier tunnel ne fonctionne que pendant une très courte période, jusqu'à ce que le deuxième tunnel apparaisse. Si, ultérieurement, vous forcez la régénération des SPI pour le tunnel 1, il commencera à fonctionner, mais le nouveau SPI #1 d'Amazon remplacera l'ancien SPI pour le tunnel 2, et le tunnel 2 cessera de fonctionner au moment où le tunnel 1 reprendra du service.

J'ai rencontré ce problème à deux reprises, à quelques années d'intervalle, et plus récemment hier, et je ne pense donc pas qu'AWS soit en mesure de le résoudre. Cela ne semble pas affecter les implémentations commerciales d'IPSec (sinon AWS l'aurait déjà corrigé). deviner parce qu'ils n'ont pas vraiment le concept de tunnels entre sous-réseaux, mais se contentent d'agréger un tas de tunnels hôte-hôte partageant tous les mêmes SPI. Il ne s'agit toutefois que d'une supposition.

Éditer : bizarrement, grâce à la semaine passée à travailler sur ce sujet pour un client qui avait un bon contrat de support AWS, j'ai maintenant confirmé ce que libreswan avait dit à propos de la dernière SPI remplaçant incorrectement toutes les SPI antérieures. Amazon a également confirmé qu'ils font cela, et que l'un d'entre eux a été mis en place. vpn- ne peut, selon eux, prendre en charge qu'une seule paire de SPI. Ils conseillent de configurer le réseau S/WAN de manière à ce qu'un seul tunnel soit créé, puis d'acheminer le trafic vers des destinations particulières par l'intermédiaire de ce tunnel.

Heureusement, libreswan prend désormais en charge cette fonctionnalité, à partir de la version 3.18, à condition que vous disposiez d'un noyau Linux raisonnablement récent. Je peux confirmer que CentOS 7 répond à ces deux critères.

Leur compte-rendu détaillé est le suivant sur leur wiki mais le résultat est que vous établissez un tunnel avec des plages de sources et de destinations très larges ( 0.0.0.0/0 ) à l'aide de l'interface tunnel virtuelle Linux ( vti ), puis indiquer à libreswan de ne pas mettre en place de routage sur ce périphérique ( vti-routing=no ). Vous pouvez ensuite choisir les destinations à atteindre via ce tunnel à l'aide de simples instructions d'acheminement ( ip route add 10.0.0.0/8 dev vti01 ).

Cela fonctionne en production. Il supporte même plusieurs tunnels simultanés, des tunnels ultérieurs utilisant des mark= y vti-interface= les options de configuration. Amazon prend également en charge l'association d'un VPN à une passerelle de transit (TGW), à laquelle de nombreux VPN de la même région AWS peuvent à leur tour être associés, de sorte que vous n'avez réellement besoin que d'un seul VPN par région AWS, ce qui est évolutif.

Essayez d'utiliser :

leftsubnets={10.43.4.0/24,10.43.6.0/24,}

au lieu de :

leftsubnets={10.43.4.0/24 10.43.6.0/24}

Note : Ajouter deux virgules. Après le premier et le dernier.