VPN de malla de alto rendimiento para conectar hosts de centros de datos

Estamos alquilando varios hosts en un centro de datos público. El centro de datos no ofrece VLAN privadas; Todos los hosts reciben una (o más) direcciones IPv4 / IPv6 públicas. Los hosts vienen con CPU muy modernas (Haswell quad-core, 3.4GHz) y tienen enlaces ascendentes Gbit. Las diferentes áreas (habitaciones? Pisos? Edificios?) Del centro de datos están interconectadas con, por lo que puedo decir, enlaces Gbit o 500Mbit. Nuestros anfitriones están ejecutando debian wheezy. Actualmente estamos ejecutando un poco más de 10 hosts, con la expectativa de crecimiento en el futuro cercano.

Estoy buscando una manera de hacer que todos los hosts se comuniquen entre sí, de forma segura y confidencial. La capa 3 está bien, la capa 2 está bien (pero no es necesario). Como no tengo acceso a las VLAN, tendrá que ser una VPN de algún tipo.

Qué es importante para mi:

1. alto rendimiento, idealmente cerca de la velocidad del cable
2. Arquitectura descentralizada en malla: esto es para asegurarse de que un elemento central no ralentice el rendimiento (por ejemplo, un concentrador VPN)
3. La huella de la CPU no es excesiva (dados los conjuntos de cifrado AESNI y GCM, espero que esto no sea un requisito ridículo)
4. facilidad de uso operacional; no es demasiado complicado de configurar; la red puede crecer sin perder conexiones establecidas

Actualmente estamos usando tinc . Marca [2] y [4], pero solo alcanzo unos 600Mbit / s (simplex) de una velocidad de cable de 960Mbit / s, y pierdo un núcleo por completo. Además, tinc 1.1, actualmente en desarrollo, aún no es multiproceso, por lo que estoy atascado con el rendimiento de un solo núcleo.

IPSec tradicional está fuera de discusión, ya que requiere un elemento central, o una carga de túneles sh * t para configurar (para lograr [2]). IPsec con cifrado oportunista sería una solución, pero no estoy seguro de que alguna vez se haya convertido en un código de producción estable.

Me he encontrado hoy con tcpcrypt . Excepto por la autenticación faltante, parece lo que quiero. La implementación del espacio de usuario huele lento, pero también lo son todas las otras VPN. Y hablan de una implementación de kernel. Todavía no lo he probado, y estoy interesado en cómo se comporta re [1] y [3].

¿Qué otras opciones hay? ¿Qué están haciendo las personas que no están en AWS?

Información adicional

Estoy interesado en GCM, con la esperanza de que reduzca la huella de la CPU. Consulte el documento de Intel sobre el tema . Cuando habló con uno de los desarrolladores de tinc, explicó que incluso usando AESNI para el cifrado, el HMAC (por ejemplo, SHA-1) sigue siendo muy costoso a la velocidad de Gbit.

Actualización final

IPsec en modo de transporte funciona perfectamente y hace exactamente lo que quiero. Después de mucha evaluación, he elegido Openswan sobre ipsec-tools, simplemente porque es compatible con AES-GCM. En las CPU Haswell mido aproximadamente 910-920Mbit / seg de rendimiento simplex con aproximadamente 8-9% de carga de CPU de uno kworkerd.

Lo que no quieres es una VPN. Lo que sí quiere es IPsec, pero no en modo túnel. Por el contrario, desea IPsec en modo de transporte .

En esta configuración, cada host se comunica directamente con sus pares, y solo las cargas de paquetes se cifran, dejando los encabezados IP en su lugar. De esta manera, no necesita hacer gimnasia de enrutamiento para que las cosas funcionen.

Sí, necesitará una sección de conexión IPsec para cada host (a menos que sus hosts estén agrupados en una subred, en cuyo caso puede hacerlo a través de un bloque CIDR), pero su sistema de administración de configuración puede generarlos fácilmente mediante programación.

No preguntó sobre los detalles de configuración, pero si necesita algunos indicadores (no hay tanta información sólida sobre el modo de transporte), puede consultar esta publicación de blog que escribí recientemente.