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:

1. haut débit, idéalement proche de la vitesse du fil
2. 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)
3. 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)
4. 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.

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.