VPN de malla: Un paso más hacia las redes de confianza cero

0
33

Las VPN de malla utilizan una arquitectura peer to peer, en la que cada nodo o peer de la red se puede conectar directamente a cualquier otro peer sin pasar por un concentrador central o puerta de enlace (gateway). Este enfoque puede ser menos costoso y más fácil de incrementar en escala que una VPN tradicional.

Las VPN de malla no es un concepto nuevo, pero sí le ha llevado mucho tiempo madurar y expandirse más allá de un uso específico. Hasta hace unos años, las necesidades de VPN de la mayoría de las organizaciones se satisfacían perfectamente a través de una arquitectura tradicional de concentrador y radio. La mayoría de los productos de seguridad como los gateways y firewalls corporativos incluyen la funcionalidad de VPN, y eso era conveniente para la mayoría de las empresas que solo tenían unos pocos empleados trabajando de forma remota.

El cambio a la infraestructura híbrida, basada en la nube, y el crecimiento de la fuerza de trabajo remota finalmente ha puesto las soluciones de redes de malla en el mapa. Esto comenzó con la necesidad de conectar máquinas virtuales y nodos que se ejecutan en diferentes nubes, una tecnología comúnmente conocida como «malla de servicios”, y ahora se está expandiendo para conectar terminales tradicionales como laptops y teléfonos móviles.

«Creo que, a largo plazo, la distinción entre mallas de servicio y VPNs de malla se difuminará, ya que ambos productos están trabajando para resolver el problema de mover paquetes de forma segura y privada entre dispositivos”, comentó David Crawshaw. Crawshaw es el CTO y cofundador de la startup de VPNs de malla, Tailscale, así como ex ingeniero de software de Google con experiencia laboral en sistemas distribuidos y proyectos de infraestructura experimental. «La distinción tradicional es si el dispositivo es virtual (una máquina virtual o contenedor) o físico (un teléfono, una laptop o un servidor), y esa distinción es cada vez más difícil de ver”.

Por qué las VPNs de malla son cada vez más populares
Casi de la noche a la mañana, la pandemia de la COVID-19 ha cambiado profundamente las operaciones de TI en la mayoría de las empresas, obligándolas a adaptarse a una nueva realidad de trabajo desde casa. Para algunos equipos de TI empresariales, esto ha significado acelerar los planes de transformación digital existentes para dar soporte el trabajo remoto, mientras que para otros significó realizar un esfuerzo para identificar e implementar nuevas soluciones.

Las grandes redes de entrega de contenido y los proveedores de nube, como Cloudflare, Akamai y Google, ahora ofrecen soluciones de acceso remoto que permiten a las empresas hacer que las aplicaciones internas estén disponibles, a través del navegador, para los trabajadores remotos, a la vez que imponen fuertes controles de acceso, identidad y seguridad. Sin embargo, hay un problema: la mayoría de esos productos funcionan solo para aplicaciones web, lo que significa que las aplicaciones y servicios que requieren otros protocolos para comunicarse deben accederse a través de una VPN.

Tradicionalmente, las arquitecturas VPN han seguido el modelo hub and spoke en el que una puerta de enlace VPN es el hub central al que se conectan todos los clientes -los spokes-. Las puertas de enlace VPN también se pueden conectar entre sí para lograr un diseño de múltiples hubs con múltiples spokes. Ese suele ser el caso en la práctica, ya que cada oficina corporativa o sucursal tiene su propio gateway VPN, pero aún representan un cuello de botella en la arquitectura de la red.

Las conexiones VPN usan encriptación, que es una operación computacionalmente intensiva, por lo que las puertas de enlace VPN son dispositivos de hardware construidos con suficiente potencia de CPU y RAM para soportar un cierto número de usuarios y conexiones simultáneos. Si de repente una empresa necesita dar soporte a una gran cantidad de usuarios remotos, como sucedió durante la pandemia, es posible que esa empresa deba reemplazar completamente su puerta de enlace VPN por una más poderosa, o agregar servidores VPN adicionales. Muchas soluciones VPN también vienen con una tarifa de licencia por puesto, por lo que la empresa, como mínimo, necesitaría comprar más puestos.

El ancho de banda de Internet disponible para la empresa, e implícitamente para el gateway VPN, también puede limitar la cantidad de usuarios simultáneos que se pueden soportar. Es por eso por lo que muchas organizaciones a menudo no guían todo el tráfico de Internet de sus trabajadores a través de la VPN, lo que potencialmente los deja expuestos cuando usan Wi-Fi público en ubicaciones inseguras.

Otro problema es que no todos los recursos y aplicaciones de TI a los que alguien necesita acceder se encuentran on premises en la oficina de la empresa. Si se trata de una versión de prueba de una aplicación en la que están trabajando y quieren compartir, puede ejecutarse en un servidor virtual en la nube o incluso en la laptop de un compañero de trabajo. En esos casos, el usuario debe pasar primero por el gateway VPN de la empresa, que puede estar ubicada en una ciudad o región diferente, y luego regresar al servidor final a través del enlace VPN entre ese servidor y el gateway VPN. Esto agrega mucha latencia a la conexión y afecta gravemente el rendimiento.

Ingrese a las VPN de malla peer to peer, donde cada nodo puede conectarse directamente a cualquier otro peer sin la necesidad de un concentrador central o gateway. Así es como se diseñó Internet originalmente, con las organizaciones y los usuarios simplemente agregando nodos adicionales a la red; no había muchas preocupaciones por la seguridad en ese entonces.

Cómo funcionan las VPN de malla
Con el tiempo, Internet desarrolló una red troncal compuesta por empresas de telecomunicaciones de nivel 1, proveedores de nube y redes de distribución de contenido que están vinculadas entre sí en puntos de intercambio de Internet de alta velocidad. Además, el grupo limitado de direcciones IPv4 públicas ha llevado a un mayor uso de la traducción de direcciones de red (NAT, por sus siglas en inglés) incluso a nivel de ISP, lo que hace que Internet se parezca cada vez más a una arquitectura de hubs and spokes. Esto es algo que los defensores de la IPv6 esperan revertir.

Algunas puertas de enlace VPN de hardware soportan configuraciones multipunto a multipunto y pueden funcionar de manera similar a las redes en malla, pero sus configuraciones deben administrarse y actualizarse constantemente cuando se producen cambios en los clientes y nodos; y en el mundo de los servicios y aplicaciones que se ejecutan en máquinas virtuales en múltiples nubes, esto sucede con bastante frecuencia.

«Las redes se reorganizan constantemente”, afirma Crawshaw. «Las máquinas virtuales se mueven entre centros de datos, los teléfonos se mueven de la oficina a la cafetería. Una empresa puede tener una oficina durante 30 años y construir hardware de red dedicado on premises o alquilar una oficina mensualmente. Por lo general, cuando el término ‘malla’ se utiliza, este implica la configuración automática de los terminales. Es decir, si mueve un dispositivo en una red, debe restablecer la comunicación con otros dispositivos en la red de malla sin la intervención de los administradores de TI”.

Las VPN de malla se implementan a través de software, por lo que, en ese sentido, son redes definidas por software, aunque SD-WAN (red de área amplia definida por software) se ha convertido en un término que a menudo se refiere a soluciones diseñadas para simplificar y automatizar la administración central, así como el control de los equipos de redes tradicionales en grandes proyectos de infraestructura de centros de datos y telecomunicaciones.

Soluciones populares de VPN de malla
Una de las primeras VPN de código abierto diseñada para redes de malla es Tinc VPN, que se remonta a 1998. Funciona en casi todos los sistemas operativos principales, incluidos Windows, Linux, BSD y macOS y soporta enrutamiento automático de malla completa, cruce de NAT y puentes de segmentos Ethernet. Tinc sirvió de inspiración para muchos de los proyectos posteriores.

Una nueva solución VPN de malla de código abierto, que también tiene un negocio comercial detrás, es ZeroTier, establecida en el 2015. ZeroTier se describe a sí misma como «un switch Ethernet programable e inteligente para el planeta Tierra” que tiene la mayoría de las capacidades de un switch SDN empresarial, que controla una red peer to peer de aplicaciones y dispositivos distribuidos en redes locales o en Internet. El resultado es una VPN de malla con un hipervisor de red que proporciona mejores capacidades de administración y monitoreo, detección y configuración automática de peers y cifrado del tráfico a través de un protocolo personalizado.

El año pasado, los ingenieros de software de Slack lanzaron otro proyecto VPN de malla de código abierto llamado Nebula, que se basa en el Noise Protocol Framework. Se refieren a Nebula como una «herramienta escalable de redes superpuestas”, diseñada para crear una red definida por software peer to peer que se autentica mutuamente y que puede vincular miles de nodos ejecutables en múltiples proveedores de servicios en la nube en varios lugares del mundo. Nebula utiliza certificados emitidos por una autoridad de certificación para identificar nodos, así como algunos de sus atributos, como direcciones IP, nombre y pertenencia a grupos definidos por el usuario.

«La mayoría de los proveedores de nube ofrecen alguna forma de agrupación de hosts de red definida por el usuario, a menudo denominados ‘grupos de seguridad’, que le permiten filtrar el tráfico de red en función de la pertenencia al grupo, en lugar de hacerlo individualmente por dirección IP o rango”, escribieron los ingenieros de Slack en su anuncio de Nebula. «Desafortunadamente, al momento de escribir este artículo, los grupos de seguridad están aislados en cada región individual correspondiente a un proveedor de alojamiento. Además, no existe una versión interoperable de los grupos de seguridad entre diferentes proveedores de alojamiento. Esto significa que, a medida que se expande a varias regiones o proveedores, su única opción útil se convierte en la segmentación de la red por dirección IP o rango de red IP, lo cual complica su administración. Dados nuestros requisitos, así como la falta de opciones disponibles que puedan cumplir con nuestros requisitos de operación, encriptación y segmentación, decidimos crear nuestra propia solución”.

Otro recién llegado en este espacio es Tailscale, de Crawshaw, que se construye en torno al nuevo protocolo de VPN de alto rendimiento, WireGuard, que se abrió camino en los kernels de Linux y OpenBSD de este año. Tailscale todavía no usa el código del kernel WireGuard. Pero ya se encuentra disponible para Windows, Linux, macOS, iOS y Android una implementación del espacio de usuario del protocolo escrita en el lenguaje de programación Go.

La mayor parte del código de Tailscale es de código abierto y su modelo de negocio se centra en ejecutar un servicio de directorio central, o un nodo de coordinación, que se utiliza para el descubrimiento y la configuración automática de los peers. También les permite a los administradores gestionar los controles de acceso y el registro basados en roles. Para implementaciones de grandes empresas, Tailscale ofrece la opción de ejecutar servidores de coordinación locales, pero no hay tráfico de usuarios real que pase a través de estos servidores, a diferencia de una puerta de enlace VPN tradicional. Solo se utilizan para intercambiar información de configuración.

Redes de identidad y confianza cero
Las redes de confianza cero se consideran el futuro de las redes empresariales. Es una arquitectura en la que se verifica la identidad de cada usuario y dispositivo antes de que se asigne la confianza y se otorgue acceso a los recursos corporativos. En la mayoría de las redes corporativas tradicionales, los dispositivos ubicados en la red interna pueden conectarse a servidores y servicios, simplemente porque están en la misma red implícitamente «confiable”, razón por la cual los hackers tienen tanto éxito moviéndose lateralmente a través de las redes.

La mayoría de las soluciones VPN de malla se inspiran en el proyecto BeyondCorp de Google y otros conceptos de redes de confianza cero, poniendo un gran énfasis en la verificación del dispositivo o del nodo de identidad. En ZeroTier, Nebula y Tailscale, la identidad del nodo se realiza en la capa IP, a través de algún tipo de criptografía de clave pública.

«Las redes físicas tradicionales no proporcionan ninguna noción de identidad, y estamos tan acostumbrados a esa idea que el trabajo moderno para llevar la identidad al tráfico de red siempre ha comenzado en niveles más altos de abstracción [HTTPS/TLS, por ejemplo]”, afirma Crawshaw. «Pero eso no es necesario. Es posible utilizar túneles de red y criptografía moderna para garantizar, con precisión, que la dirección de origen IP de un paquete pueda describir quién lo envió realmente. La ventaja de trasladar este concepto a la capa IP es que se vuelve compatible con el software existente. Usted puede tomar las herramientas internas existentes y moverlas lentamente a redes virtuales privadas, donde se conoce la identidad de todos los remitentes y receptores, desactivando lentamente el acceso a través de las redes tradicionales. No tiene que reescribir todo su software para reconocer la identidad”.

El protocolo WireGuard, por ejemplo, introduce el concepto de routing de clave criptográfica, donde la clave pública de un nodo está vinculada a una lista de direcciones IP, la cual puede estar contenida dentro del nodo en el túnel VPN. Esto significa que no hay posibilidad de suplantación de un nodo en la red si la clave privada del nodo permanece segura. Esto da a los administradores de red, así como a los equipos de seguridad, el poder de garantizar que ciertas aplicaciones o recursos solo sean visibles y accesibles en la red de malla para usuarios y dispositivos muy específicos.

Además de las comprobaciones de identidad del dispositivo realizadas a nivel de protocolo, las VPN de malla también pueden realizar comprobaciones de identidad del usuario. Tailscale, por ejemplo, soporta la integración con los proveedores de identidad más comunes que ya son utilizados por empresas como Google, Microsoft, Okta y SAP y soporta la autenticación multifactorial a través de ellos.

Opcionalmente, las empresas también pueden combinar una solución VPN de malla para acceder a aplicaciones y servicios que no sean HTTP a través de una puerta de enlace de acceso de confianza cero, como las de Akamai, Cloudflare o Google, para acceder a sus aplicaciones web. Estas soluciones también realizan controles de seguridad del dispositivo por medio del navegador o mediante un cliente ligero separado instalado en los terminales.

Lucian Constantin, CSOonline.com