Servicios VPN de Aclass: Conecta con tu empresa de forma segura

Es un hipervisor de red distribuido construido sobre una red global peer to peer criptográficamente segura. Proporciona capacidades avanzadas de virtualización y gestión de red a la par que un conmutador SDN empresarial, pero a través de redes de área local y amplia y conectando casi cualquier tipo de aplicación o dispositivo.

Este manual describe el diseño y el funcionamiento de Aclass Tier y sus servicios, aplicaciones y bibliotecas asociadas. Está dirigido a profesionales de TI, administradores de redes, expertos en seguridad de la información y desarrolladores.

La primera sección (2) de esta guía explica el diseño y funcionamiento de Aclass Tier a un alto nivel y está escrito para aquellos con al menos un conocimiento intermedio de temas como TCP / IP y redes Ethernet. No es una lectura obligatoria para la mayoría de los usuarios, pero entender cómo funcionan las cosas en detalle ayuda a aclarar todo lo demás y ayuda enormemente con la solución de problemas si algo va mal.

Las secciones restantes tratan de forma más concreta el despliegue y la administración.

El protocolo que utiliza Aclass Tier es original, aunque tiene aspectos similares a VXLAN e IPSec. Tiene dos capas conceptualmente separadas, pero estrechamente acopladas en el sentido del modelo OSI: VL1 y VL2. VL1 es la capa de transporte peer to peer subyacente, el «cable virtual», mientras que VL2 es una capa Ethernet emulada que proporciona a los sistemas operativos y a las aplicaciones un medio de comunicación familiar.

En las redes convencionales, L1 (capa 1 de OSI) se refiere a los cables CAT5/CAT6 reales o a los canales de radio inalámbricos por los que se transportan los datos y a los chips transceptores físicos que los modulan y demodulan. VL1 es una red peer to peer que hace lo mismo utilizando encriptación, autenticación y un montón de trucos de red para crear cables virtuales de forma dinámica según sea necesario.

Para lograrlo, VL1 se organiza como DNS. En la base de la red hay una colección de servidores raíz siempre presentes cuya función es similar a la de los servidores de nombres raíz DNS. Los servidores raíz ejecutan el mismo software que los puntos finales normales, pero residen en ubicaciones estables y rápidas de la red y se designan como tales mediante una definición de mundo. Las definiciones de mundo son de dos tipos: el planeta y una o varias lunas. El protocolo incluye un mecanismo seguro que permite actualizar las definiciones de mundo en banda si cambian las direcciones IP de los servidores raíz o las direcciones de Aclass Tier.

Actualmente Aclass utiliza servidores externos y cede servidores propios para la intercomunicación de redes VPN seguras. Hay doce servidores raíz organizados en dos clusters de seis miembros distribuidos por los principales continentes y múltiples proveedores de red. Casi todo el mundo tiene uno a menos de 100 ms de latencia de red de su ubicación.

Un nodo puede «orbitar» cualquier número de lunas. Una luna no es más que una forma cómoda de añadir servidores raíz definidos por el usuario al pool. Los usuarios pueden crear lunas para reducir la dependencia de la infraestructura de Aclass Tier o para ubicar los servidores raíz más cerca para un mejor rendimiento. Para el uso SDN local, se puede ubicar un clúster de servidores raíz dentro de un edificio o centro de datos para que Aclass Tier pueda seguir funcionando con normalidad si se pierde la conectividad a Internet.

Los nodos comienzan sin enlaces directos entre sí, sólo ascendentes a las raíces (planeta y lunas). Cada peer en VL1 posee una dirección global única de 40 bits (10 dígitos hexadecimales), pero a diferencia de las direcciones IP, se trata de identificadores criptográficos opacos que no codifican ninguna información de enrutamiento. Para comunicarse, los pares envían primero paquetes «hacia arriba» del árbol y, a medida que atraviesan la red, activan la creación oportunista de enlaces directos a lo largo del camino. El árbol intenta constantemente «colapsarse» para optimizarse al patrón de tráfico que transporta.

Dado que las raíces reenvían los paquetes, A y B pueden comunicarse instantáneamente. A y B intentan entonces establecer una conexión directa de igual a igual. Si esto tiene éxito, se consigue un enlace más rápido y de menor latencia. Llamamos a esto transporte desencadenado por la provisión de enlaces, ya que es el propio reenvío del paquete el que desencadena la red peer to peer para intentar la conexión directa.

VL1 nunca se rinde. Si no se puede establecer una ruta directa, la comunicación puede continuar a través de una retransmisión (más lenta). Los intentos de conexión directa continúan para siempre de forma periódica. VL1 también tiene otras características para establecer conectividad directa, incluyendo el descubrimiento de pares LAN, la predicción de puertos para atravesar NATs IPv4 simétricas, y la asignación explícita de puertos utilizando uPnP y/o NAT-PMP si estos están disponibles en la LAN física local.

En los dispositivos que ejecutan Aclass Tier, la identidad del nodo se almacena en identity.public e identity.secret en el directorio principal del servicio.

Cuando Aclass Tier se inicia por primera vez, genera una nueva identidad. A continuación, intenta anunciarla a la red. En el caso muy improbable de que la dirección única de 40 bits de la identidad esté ocupada, la descarta y genera otra.

Las identidades se reclaman por orden de llegada y actualmente caducan tras 60 días de inactividad. Si un dispositivo inactivo durante mucho tiempo regresa, puede volver a reclamar su identidad a menos que su dirección haya sido tomada mientras tanto (de nuevo, muy poco probable).

El algoritmo de derivación de direcciones utilizado para calcular las direcciones a partir de claves públicas impone una barrera de coste computacional contra la generación intencionada de una colisión. Actualmente se necesitarían aproximadamente 10.000 años de CPU para hacerlo (suponiendo, por ejemplo, un núcleo Intel de 3ghz). Esto es caro, pero no imposible, pero es sólo la primera línea de defensa. Después de generar una colisión, un atacante tendría que comprometer todos los nodos ascendentes, controladores de red y cualquier otra cosa que se haya comunicado recientemente con el nodo objetivo y reemplazar sus identidades almacenadas en caché.

Las direcciones de Aclass Tier son, una vez anunciadas y reclamadas, un método muy seguro de identificación única.

Cuando un nodo intenta enviar un mensaje a otro nodo cuya identidad no está almacenada en caché, envía una consulta whois a una raíz. Las raíces proporcionan una caché de identidad autorizada.

Si no sabes mucho sobre criptografía puedes saltarte esta sección. TL;DR: los paquetes están encriptados de extremo a extremo y no pueden ser leídos por las raíces o cualquier otra persona, y utilizamos criptografía moderna de 256 bits en las formas recomendadas por los criptógrafos profesionales que la crearon.

El cifrado de clave pública asimétrica es Curve25519/Ed25519, una variante de curva elíptica de 256 bits.

Cada paquete VL1 se cifra de extremo a extremo utilizando (a partir de la versión actual) Salsa20 de 256 bits y se autentica utilizando el algoritmo de autenticación de mensajes (MAC) Poly1305. MAC se calcula después del cifrado (encrypt-then-MAC) y la composición cifrado/MAC utilizada es idéntica a la implementación de referencia de NaCl.

A día de hoy no implementamos forward secrecy ni otras características criptográficas con estado en VL1. No lo hacemos en aras de la simplicidad, la fiabilidad y la huella de código, y porque el cambio frecuente de estado hace que características como la agrupación y la conmutación por error sean mucho más difíciles de implementar.

Es posible que implementemos el forward secrecy en el futuro. Para aquellos que quieran este nivel de seguridad hoy, recomendamos usar otros protocolos criptográficos como SSL o SSH sobre Aclass Tier. Estos protocolos suelen implementar el forward secrecy, pero su uso sobre Aclass Tier también proporciona el beneficio secundario de la defensa en profundidad. La mayor parte de la criptografía no se ve comprometida por un fallo en el cifrado, sino por errores en la implementación. Si utilizas dos transportes seguros, las probabilidades de que se descubra un fallo crítico en ambos al mismo tiempo son muy bajas. La sobrecarga de CPU del doble cifrado no es significativa para la mayoría de las cargas de trabajo.

Las rutas de confianza no impiden la comunicación con dispositivos de otros lugares, ya que el tráfico a través de otras rutas se cifrará y autenticará normalmente.

No recomendamos el uso de esta función a menos que realmente necesites el rendimiento y sepas lo que estás haciendo. También recomendamos pensar detenidamente antes de desactivar la seguridad de transporte en una red privada en la nube. Los proveedores de nube más grandes como Amazon y Azure tienden a proporcionar una buena segregación de red, pero muchos proveedores menos costosos ofrecen redes privadas que son «party lines» y no son mucho más seguras que la Internet abierta.

VL2 se construye sobre VL1 y se transporta a través de él, por lo que hereda el cifrado y la autenticación de extremos de VL1 y puede utilizar claves asimétricas de VL1 para firmar y verificar credenciales. VL1 también nos permite implementar VL2 sin preocuparnos por la topología de la red física subyacente. Los problemas de conectividad y eficiencia de enrutamiento son preocupaciones de VL1. Es importante entender que no existe ninguna relación entre las redes virtuales VL2 y las rutas VL1. Al igual que la multiplexación VLAN en una LAN cableada, dos nodos que comparten múltiples membresías de red en común sólo tendrán una ruta VL1 (cable virtual) entre ellos.

ID de red: 8056c2e21c123456
| |
| Número de red en el controlador
|
Dirección Aclass Tier del controlador

Cuando un nodo se une a una red o solicita una actualización de la configuración de red, envía un mensaje de consulta de configuración de red (a través de VL1) al controlador de la red. El controlador puede entonces utilizar la dirección VL1 del nodo para buscarlo en la red y enviarle los certificados, credenciales e información de configuración apropiados. Desde la perspectiva de las redes virtuales VL2, las direcciones VL1 de Aclass Tier pueden considerarse números de puerto en un enorme conmutador virtual a escala global.

Un malentendido común es confundir los controladores de red con los servidores raíz (planeta y lunas). Los servidores raíz son facilitadores de conexión que operan a nivel VL1. Los controladores de red son gestores de configuración y autoridades de certificación que pertenecen a VL2. Generalmente los servidores raíz no se unen o controlan redes virtuales y los controladores de red no son servidores raíz, aunque es posible que un nodo haga ambas cosas.

Es importante que los relojes del sistema de los controladores sean relativamente precisos (entre 30 y 60 segundos) y que estén protegidos contra la manipulación remota. Muchos proveedores de nube proporcionan fuentes de tiempo seguras, ya sea directamente a través del hipervisor o a través de servidores NTP dentro de sus redes.

Las credenciales sólo se emiten a sus propietarios y los nodos que desean comunicarse con otros nodos de la red las envían de igual a igual. Esto permite que las redes crezcan hasta tamaños enormes sin necesidad de que los nodos almacenen en caché un gran número de credenciales o consulten constantemente al controlador.

Cuando un nodo desea recibir multidifusiones para un grupo de multidifusión determinado, anuncia su pertenencia a este grupo a otros miembros de la red con la que se comunica y al controlador de red. Cuando un nodo desea enviar una multidifusión, consulta su caché de anuncios recientes y solicita periódicamente anuncios adicionales.

La multidifusión (Ethernet ff:ff:ff:ff:ff:ff) se trata como un grupo multidifusión al que se suscriben todos los miembros. Puede desactivarse a nivel de red para reducir el tráfico si no es necesario. El ARP IPv4 recibe un tratamiento especial (véase más adelante) y seguirá funcionando si se desactiva la difusión normal.

Las multidifusiones se propagan utilizando una simple replicación del lado del remitente. Esto coloca toda la carga de ancho de banda saliente para multidifusión en el remitente y minimiza la latencia de multidifusión. Las configuraciones de red contienen un límite de multidifusión en toda la red configurable en el controlador de red. Esto especifica el número máximo de otros nodos a los que cualquier nodo enviará una multidifusión. Si el número de destinatarios conocidos en un determinado grupo de multidifusión supera el límite de multidifusión, el remitente elige un subconjunto aleatorio.

No existe un límite global para los destinatarios de multidifusión, pero si se establece un límite de multidifusión muy alto en redes muy grandes, podría producirse una sobrecarga significativa del ancho de banda.

IPv4 ARP se basa en una simple difusión Ethernet y se escala pobremente en redes grandes o distribuidas. Para mejorar la escalabilidad de ARP, Aclass Tier genera un grupo de multidifusión único para cada dirección IPv4 detectada en su sistema y, a continuación, intercepta de forma transparente las consultas ARP y las envía únicamente al grupo correcto. Esto convierte ARP en un protocolo de unidifusión o multidifusión estrecha (como IPv6 NDP) y permite que ARP IPv4 funcione de forma fiable en redes de área extensa sin un consumo excesivo de ancho de banda. Una estrategia similar se aplica bajo el capó de una serie de conmutadores de empresa y routers WiFi diseñados para su despliegue en LAN extremadamente grandes. Este modo de emulación ARP es transparente para el sistema operativo y las capas de aplicación, pero significa que los rastreadores de paquetes no verán todas las consultas ARP en una red virtual de la forma en que normalmente lo hacen en redes LAN cableadas más pequeñas.

IPv6 utiliza un protocolo llamado NDP en lugar de ARP. Es similar en función y diseño, pero utiliza multidifusión estrecha en lugar de difusión para una escalabilidad superior en redes grandes. No obstante, este protocolo sigue imponiendo la latencia de una búsqueda multicast adicional cada vez que se contacta con una nueva dirección. Esto puede añadir cientos de milisegundos en una red de área extensa, o más si las latencias asociadas a la búsqueda de destinatarios pub/sub son significativas.

Las direcciones IPv6 son lo suficientemente grandes como para codificar fácilmente direcciones de Aclass Tier. Para un funcionamiento más rápido y un mejor escalado, hemos implementado varios modos especiales de direccionamiento IPv6 que permiten al nodo local emular NDP. Se trata de los esquemas de asignación de direcciones IPv6 rfc4193 y 6plane de Aclass Tier. Si estos esquemas de direccionamiento están habilitados en una red, los nodos interceptan localmente las consultas NDP salientes en busca de direcciones coincidentes y generan localmente respuestas NDP falsas.

Ambos modos reducen drásticamente la latencia de la conexión inicial entre los miembros de la red. 6plane explota además la emulación NDP para asignar de forma transparente un prefijo IPv6 /80 completo a cada nodo sin necesidad de que ninguno de ellos posea entradas adicionales en la tabla de enrutamiento. Esto está pensado para hosts de máquinas virtuales y contenedores que deseen autoasignar direcciones IPv6 a los invitados y resulta muy útil en redes backplane de arquitectura de microservicios.

Por último, la emulación NDP ofrece una ventaja en materia de seguridad. Las direcciones de Aclass Tier están autenticadas criptográficamente, y dado que las direcciones MAC Ethernet de las redes se calculan a partir de direcciones de Aclass Tier, éstas también son seguras. Por lo tanto, los modos de direccionamiento IPv6 emulados por NDP no son vulnerables a la suplantación de respuesta NDP.

Las direcciones IPv6 normales no emuladas por NDP (incluyendo direcciones link-local) pueden coexistir con esquemas de direccionamiento emulados por NDP. Cualquier consulta NDP que no coincida con direcciones emuladas NDP se envía a través de multidifusión normal.

Para actuar como puente, un miembro de la red debe ser designado como tal por el controlador. Esto es por razones de seguridad, ya que a los miembros normales de la red no se les permite enviar tráfico desde ningún otro origen que no sea su dirección MAC. Los puentes designados también reciben un tratamiento especial por parte del algoritmo de multidifusión, que les solicita de forma más agresiva y directa suscripciones a grupos y les replica todo el tráfico de difusión y las solicitudes ARP. Como resultado, los nodos puente experimentan una sobrecarga de ancho de banda de multidifusión ligeramente superior.

El bridging se ha probado ampliamente en Linux utilizando el puente nativo del kernel Linux, que gestiona limpiamente los desajustes de MTU de la red. Existen informes de terceros sobre el funcionamiento del bridging en otras plataformas. Los detalles de la configuración del bridging, incluyendo cómo bloquear selectivamente tráfico como DHCP que puede no ser deseado a través del puente, están más allá del alcance de este manual.

Por otro lado, las reglas se hacen cumplir, por lo que es posible implementar una red pública de propósito especial que sólo permita el acceso a unas pocas cosas o que sólo permita un subconjunto restringido de tráfico.

Las redes públicas son útiles para pruebas y para «party lines» entre iguales para juegos, chat y otras aplicaciones. Se advierte a los participantes en redes públicas que presten especial atención a la seguridad. Si se une a una red pública, tenga cuidado de no exponer servicios vulnerables o compartir accidentalmente archivos privados a través de recursos compartidos de red abiertos o servidores HTTP. Asegúrese de que su sistema operativo, aplicaciones y servicios están totalmente actualizados.

ffSSSSEEEE000000
| | | |
| | | Reservado para uso futuro, debe ser 0
| | Fin del rango de puertos (hex)
| Inicio del intervalo de puertos (hex)
Reservado Prefijo de dirección de Aclass Tier que indica una red sin controlador

Las redes ad-hoc son redes públicas (sin control de acceso) que no tienen controlador de red. En su lugar, su configuración y otras credenciales se generan localmente. Las redes ad-hoc sólo permiten tráfico IPv6 UDP y TCP unicast (no multicast ni broadcast) utilizando direcciones IPv6 emuladas NDP en formato 6plane. Además, un ID de red ad-hoc codifica un rango de puertos IP. Los paquetes UDP y los paquetes TCP SYN (conexión abierta) sólo se permiten a puertos de destino dentro del rango codificado.

Por ejemplo, ff00160016000000 es una red ad-hoc que sólo permite SSH, mientras que ff0000ffff000000 es una red ad-hoc que permite cualquier puerto UDP o TCP.

Ten en cuenta que estas redes son públicas y cualquiera en el mundo entero puede unirse a ellas. Hay que tener cuidado para evitar exponer servicios vulnerables o compartir archivos u otros recursos no deseados.

En una versión futura (aún no implementada en la versión 1.4.2), Aclass Tier soportará nuevas reglas de priorización del tráfico que se basarán en las funciones de medición de enlaces. Habrá nueve categorías disponibles para la clasificación del tráfico: [0, 1, 2, 3, (4), 5, 6, 7, 8], cada uno con una prioridad geométricamente creciente, siendo el bloque 4 el predeterminado en ausencia de una regla de clasificación para un tipo de tráfico determinado.

Por ejemplo, digamos que quieres priorizar tu tráfico VoIP sobre el tráfico web estándar:

prioridad 6
iprotocolo udp
y dport 5060-5065
y sport 5060-5065
;

prioridad 3
iprotocolo tcp
y dport 80
y sport 80
;

Esto colocaría el tráfico VoIP en los puertos 5060 a 5065 en una prioridad 6 más alta que el tráfico web estándar del puerto 80 en el bloque 3.