VPN maillé à haut débit pour connecter les hôtes du centre de données

Nous louons un certain nombre d'hôtes dans un centre de données public. Le centre de données ne propose pas de VLAN privés; tous les hôtes reçoivent une (ou plusieurs) adresses IPv4 / IPv6 publiques. Les hôtes sont livrés avec des processeurs très modernes (Haswell quad-core, 3,4 GHz) et ont des liaisons montantes Gbit. Les différentes zones (pièces? Étages? Bâtiments?) Du datacenter sont interconnectées avec - d'après ce que je peux en dire - des liaisons Gbit ou 500Mbit. Nos hôtes utilisent Debian Wheezy. Actuellement, nous exploitons un peu plus de 10 hôtes, avec une attente de croissance dans un proche avenir.

Je cherche un moyen pour que tous les hôtes communiquent entre eux, de manière sécurisée et confidentielle. La couche 3 est fine, la couche 2 est correcte (mais pas nécessaire). Étant donné que je n'ai pas accès aux VLAN, il faudra que ce soit un VPN en quelque sorte.

Qu'est-ce qui est important pour moi:

haut débit, idéalement proche de la vitesse du fil
architecture décentralisée et maillée - pour s'assurer que le débit n'est pas ralenti par un élément central (par exemple, un concentrateur VPN)
L'encombrement du processeur n'est pas excessif (compte tenu des suites de chiffrement AESNI et GCM, j'espère que ce n'est pas une exigence ridicule)
facilité d'utilisation opérationnelle; pas trop compliqué à installer; le réseau peut se développer sans perdre les connexions établies

Nous utilisons actuellement du tinc . Il coche [2] et [4], mais j'atteins seulement environ 600Mbit / s (simplex) d'une vitesse de fil de 960Mbit / s, et je perds complètement un noyau. De plus, tinc 1.1 - actuellement en développement - n'est pas encore multithread, donc je suis bloqué avec des performances à un seul cœur.

IPSec traditionnel est hors de question, car il nécessite un élément central, ou une charge de tunnels à configurer (pour atteindre [2]). IPsec avec chiffrement opportuniste serait une solution, mais je ne suis pas sûr qu'il ait jamais été transformé en code de production stable.

Je suis tombé sur tcpcrypt aujourd'hui. À l'exception de l'authentification manquante, cela ressemble à ce que je veux. L'implémentation de l'espace utilisateur sent lentement, mais il en va de même pour tous les autres VPN. Et ils parlent d'une implémentation du noyau. Je ne l'ai pas encore essayé et je suis curieux de savoir comment il se comporte entre [1] et [3].

Quelles autres options existe-t-il? Que font les gens qui ne sont pas sur AWS?

Information additionnelle

Je suis intéressé par GCM, en espérant qu'il réduira l'encombrement du processeur. Voir l'article d'Intel sur le sujet . En parlant à l'un des développeurs de tinc, il a expliqué que même en utilisant AESNI pour le cryptage, le HMAC (par exemple SHA-1) est toujours très cher à la vitesse Gbit.

Mise à jour finale

IPsec en mode transport fonctionne parfaitement et fait exactement ce que je veux. Après de nombreuses évaluations, j'ai choisi OpenSwan plutôt que les outils IPSec, simplement parce qu'il prend en charge AES-GCM. Sur les processeurs Haswell, je mesure environ 910-920Mbit / sec de débit simplex avec environ 8-9% de charge CPU d'un kworkerd.

— Hank
source

SO, équipement bas de gamme? Quelles performances espérez-vous conserver après avoir effectué le chiffrement au niveau gigabit? Pas question - je vous suggère de chercher un hôte plus professionnel ou de tuer la partie de cryptage.

— TomTom

@tomtom selon le papier de crypto-performance d' Intel, les performances de chiffrement pour AES-128-CBC sont de 4,52 cycles par octet, ce qui signifie que 100 Mo / s consommeraient jusqu'à ~ 450 MHz d'un seul cœur. Le déchiffrement est considérablement moins coûteux. Donc, à moins que des problèmes spécifiques à l'implémentation ne réduisent les performances, cela devrait fonctionner pour les charges qui n'ont pas besoin des performances CPU maximales et des performances réseau maximales en même temps .

— le-wabbit

pourquoi voudriez-vous GCM? L'IPSEC n'est pas sensible aux attaques de TLS, donc envisager d'utiliser GCM pour contourner les faiblesses de TLS dans les modes CBC est un point discutable.

— le-wabbit le

Ce que vous ne voulez pas, c'est un VPN. Ce que vous faites défaut est en effet IPsec, mais pas en mode tunnel. Vous voulez plutôt IPsec en mode transport .

Dans cette configuration, chaque hôte communique directement avec son homologue et seules les charges utiles des paquets sont chiffrées, laissant les en-têtes IP en place. De cette façon, vous n'avez pas besoin de faire de gymnastique de routage pour que les choses fonctionnent.

Oui, vous aurez besoin d'une strophe de connexion IPsec pour chaque hôte (sauf si vos hôtes sont regroupés dans un sous-réseau, auquel cas vous pouvez le faire via un bloc CIDR), mais ceux-ci peuvent facilement être générés par programme par votre système de gestion de configuration.

Vous n'avez pas demandé de détails sur la configuration, mais si vous avez besoin de quelques pointeurs (il n'y a pas beaucoup d'informations solides sur le mode de transport), vous pouvez vous référer à ce billet de blog que j'ai rédigé récemment.

— EEAA
source

J'appuie l'idée d'utiliser le mode de transport IPSEC pour cela. Cependant, l'utilisation de PSK avec OpenSWAN n'est peut-être pas la meilleure de toutes les configurations. Linux est déjà livré avec une implémentation IPSEC native et un démon de saisie (racoon), je m'en tiendrai à moins qu'il y ait une exigence spécifique non couverte par KAME / racoon.

— le-wabbit

Merci beaucoup! Combinant vos conseils, j'ai utilisé l'implémentation IPsec native avec racoon. J'ai d'abord testé sur de petites machines monocœur, et déjà le débit a augmenté de 50% et la latence a chuté à environ 60%. Je vais le confirmer sur les nœuds Haswell la semaine prochaine et j'accepterai alors la réponse. J'ai besoin de savoir si AES-GCM est pris en charge dans le noyau et comment le signaler à IPsec.

— Hank

@ syneticon-dj - juste curieux ... pourquoi pas openswan? Il utilise toujours les bits ip xfrm du noyau pour IPsec, mais utilise pluto comme démon IKE de son espace utilisateur au lieu de racoon. Je ne préconise pas que openswan soit le meilleur sur le marché - c'est tout ce que j'ai utilisé et s'il y a de meilleures options, je veux aller dans cette direction.

— EEAA

Cela se résume probablement à des préférences personnelles, mais j'ai toujours eu des problèmes avec l'inélégance des fichiers de configuration Free- / OpenSWAN et l'implémentation du routage tout à fait laide. J'aime beaucoup la partie dynamique racoonctlqui ressemble beaucoup à ce que les routeurs commerciaux permettent dans leurs contrôles IPSEC. KAME se sent plus bien conçu tandis qu'OpenSWAN se sent plutôt rafistolé.

— le-wabbit le

@ syneticon-dj, voudriez-vous développer cela? Voulez-vous dire que vous pouvez acheminer plusieurs réseaux via une liaison IPSec sans avoir besoin de plusieurs configurations SA, comme c'est le cas actuellement avec Openswan?

— rsuarez