Se acaba de dar a conocer el lanzamiento de la nueva version de Nebula 1.5 la cual se posiciona como una colección de herramientas para construir redes superpuestas seguras que pueden unir desde varios hasta decenas de miles de hosts separados geográficamente, formando una red aislada separada en la parte superior de la red global.
El proyecto está diseñado para crear sus propias redes superpuestas para cualquier necesidad, por ejemplo, para combinar computadoras corporativas en diferentes oficinas, servidores en diferentes centros de datos o entornos virtuales de diferentes proveedores de nube.
Sobre Nebula
Los nodos de la red Nebula se comunican directamente entre sí en modo P2P, ya que la necesidad de transferir datos entre los nodos crea conexiones VPN directas de forma dinámica. La identidad de cada host en la red se confirma mediante un certificado digital, y la conexión a la red requiere autenticación; cada usuario recibe un certificado que confirma la dirección IP en la red Nebula, el nombre y la membresía de los grupos de hosts.
Los certificados son firmados por una autoridad de certificación interna, implementados por el creador de cada red individual en sus propias instalaciones y utilizados para certificar la autoridad de los hosts que tienen derecho a conectarse a una red superpuesta específica vinculada a la autoridad de certificación.
Para crear un canal de comunicación seguro autenticado, Nebula utiliza su propio protocolo de túnel basado en el protocolo de intercambio de claves Diffie-Hellman y el cifrado AES-256-GCM. La implementación del protocolo se basa en primitivas listas para usar y probadas proporcionadas por el marco Noise , que también se utiliza en proyectos como WireGuard, Lightning e I2P. Se dice que el proyecto pasó una auditoría de seguridad independiente.
Para descubrir otros nodos y coordinar la conexión a la red, se crean nodos «faro» especiales, cuyas direcciones IP globales son fijas y conocidas por los participantes de la red. Los nodos participantes no tienen un enlace a una dirección IP externa, se identifican mediante certificados. Los propietarios de hosts no pueden realizar cambios en los certificados firmados por sí mismos y, a diferencia de las redes IP tradicionales, no pueden pretender ser otro host simplemente cambiando la dirección IP. Cuando se crea un túnel, la identidad del host se valida con una clave privada individual.
A la red creada se le asigna un cierto rango de direcciones de intranet (por ejemplo, 192.168.10.0/24) y las direcciones internas están vinculadas con certificados de host. Los grupos se pueden formar a partir de los participantes en la red superpuesta, por ejemplo, a servidores y estaciones de trabajo separados, a los que se aplican reglas de filtrado de tráfico separadas. Se proporcionan varios mecanismos para atravesar traductores de direcciones (NAT) y cortafuegos. Es posible organizar el enrutamiento a través de la red superpuesta de tráfico de hosts de terceros que no están incluidos en la red Nebula (ruta insegura).
Ademas, admite la creación de Firewalls para separar el acceso y filtrar el tráfico entre los nodos de la red superpuesta Nebula. Las ACL con enlace de etiquetas se utilizan para el filtrado. Cada host de la red puede definir sus propias reglas de filtrado para hosts, grupos, protocolos y puertos de red. Al mismo tiempo, los hosts no se filtran por direcciones IP, sino por identificadores de host firmados digitalmente, que no se pueden falsificar sin comprometer el centro de certificación que coordina la red.
El código está escrito en Go y tiene la licencia MIT. El proyecto fue fundado por Slack, que desarrolla el mensajero corporativo del mismo nombre. Soporta Linux, FreeBSD, macOS, Windows, iOS y Android.
En cuanto a los cambios que se implementaron en la nueva versión son los siguientes:
- Se agregó el indicador «-raw» al comando print-cert para imprimir la representación PEM del certificado.
- Se agregó soporte para la nueva arquitectura de Linux riscv64.
- Se agregó la configuración experimental remote_allow_ranges para vincular las listas de hosts permitidos a subredes específicas.
- Se agregó la opción pki.disconnect_invalid para restablecer los túneles después de la terminación de la confianza o el vencimiento del certificado.
- Se agregó la opción unsafe_routes. <ruta> .metric para establecer el peso de una ruta externa específica.
Finalmente, si estás interesado en poder conocer más al respecto, puedes consultar sus detalles y/o documentación en el siguiente enlace.
from Desde Linux https://ift.tt/3FcG1pL
via IFTTT
No hay comentarios.:
Publicar un comentario