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:

alto rendimiento, idealmente cerca de la velocidad del cable
Arquitectura descentralizada en malla: esto es para asegurarse de que un elemento central no ralentice el rendimiento (por ejemplo, un concentrador VPN)
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)
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.

— Madeja
fuente

SO, equipo de gama baja? ¿Qué rendimiento espera mantener después de realizar el cifrado a nivel de gigabit? De ninguna manera: le sugiero que busque un host más profesional o elimine la parte de cifrado.

— TomTom

@tomtom, según el documento de rendimiento criptográfico de Intel, el rendimiento de cifrado para AES-128-CBC es de 4,52 ciclos por byte, lo que significa que 100 MB / s consumirían ~ 450 MHz de un solo núcleo. El descifrado es considerablemente menos costoso. Por lo tanto, a menos que los problemas específicos de la implementación estén reduciendo el rendimiento, debería funcionar para cargas que no necesitan el máximo rendimiento de la CPU y el máximo rendimiento de la red al mismo tiempo .

— the-wabbit

¿Por qué quieres GCM? IPSEC no es susceptible a los ataques de TLS, por lo que considerar usar GCM para solucionar las debilidades de TLS en los modos CBC es un punto discutible.

— the-wabbit

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.

— EEAA
fuente

Secundo la idea de usar el modo de transporte IPSEC para esto. Sin embargo, usar PSK con OpenSWAN podría no ser la mejor de todas las configuraciones. Linux ya viene con una implementación nativa de IPSEC y un demonio de codificación (mapache), me apegaría a eso a menos que exista un requisito específico que KAME / racoon no cubra.

— the-wabbit

¡Muchas gracias! Combinando su consejo, utilicé la implementación nativa de IPsec con racoon. Primero probé en máquinas pequeñas de un solo núcleo, y el rendimiento aumentó en un 50% y la latencia se redujo a aproximadamente un 60%. Lo confirmaré en los nodos de Haswell la próxima semana y aceptaré la respuesta entonces. Sin embargo, necesito saber si AES-GCM es compatible con el núcleo y cómo enviarlo a IPsec.

— Hank

@ syneticon-dj - solo curiosidad ... ¿por qué no openswan? Todavía usa los bits ip xfrm del kernel para IPsec, pero usa plutón como su demonio IKE de espacio de usuario en lugar de mapache. No estoy abogando por que OpenSwan sea el mejor que existe: es todo lo que he usado y, si hay mejores opciones, quiero avanzar en esa dirección.

— EEAA

Probablemente se reduzca a preferencias personales, pero siempre tuve problemas con la falta de elegancia de los archivos de configuración Free- / OpenSWAN y la implementación de enrutamiento completamente fea. Me gusta mucho la parte dinámica racoonctlque se parece mucho a lo que los enrutadores comerciales permiten en sus controles IPSEC. KAME se siente más completamente diseñado, mientras que OpenSWAN se siente remendado.

— the-wabbit

@ syneticon-dj, ¿te gustaría dar más detalles sobre esto? ¿Quiere decir que puede enrutar varias redes a través de un enlace IPSec sin la necesidad de varias configuraciones SA, como ahora sucede con Openswan?

— rsuarez