Foi lançada a versão 1.9 do projeto Nebula, que oferece ferramentas para a construção de redes overlay seguras, permitindo reunir hosts geograficamente dispersos em uma rede isolada que opera sobre a rede global. O projeto é destinado à criação de suas próprias redes overlay para diversas necessidades, como unir computadores corporativos em diferentes escritórios, servidores em diferentes data centers ou ambientes virtuais em diversos provedores de nuvem. O código é escrito na linguagem Go e distribuído sob a licença MIT. O projeto é apoiado pela empresa Slack, que desenvolve o mensageiro corporativo homônimo. A compatibilidade é suportada em Linux, FreeBSD, macOS, Windows, iOS e Android.
Os nós na rede Nebula interagem diretamente entre si no modo P2P — à medida que surge a necessidade de transferência de dados entre os nós, conexões diretas são criadas dinamicamente. VPN- As identidades de cada host na rede são confirmadas por um certificado digital, e a conexão à rede requer autenticação — cada usuário recebe um certificado que confirma o endereço IP na rede Nebula, nome e o pertencimento a grupos de hosts. Os certificados são assinados por uma autoridade certificadora interna, implantada pelo criador de cada rede específica em suas instalações, e utilizada para validar as credenciais dos hosts autorizados a se conectar a uma rede overlay específica atrelada à autoridade certificadora.
Para criar um canal de comunicação autenticado e seguro no Nebula, é utilizado um protocolo de tunelamento próprio, baseado no protocolo de troca de chaves de Diffie-Hellman e na cifra AES-256-GCM. A implementação do protocolo se baseia em primitivas robustas e testadas fornecidas pelo framework Noise, que também é utilizado em projetos como WireGuard, Lightning e I2P. Afirma-se que o projeto passou por uma auditoria de segurança independente.
Para descobrir outros nós e coordenar conexões à rede, são criados nós especiais chamados "lighthouse", cujos endereços IP globais são fixos e conhecidos pelos participantes da rede. Os nós participantes não têm ligação com endereços externos. endereço IP, eles são identificados por certificados. Os proprietários de hosts não podem fazer alterações nos certificados assinados por conta própria, e, ao contrário das redes IP tradicionais, não podem se fazer passar por outro host simplesmente trocando o endereço IP. Ao criar um túnel, a identidade do host é confirmada por uma chave privada exclusiva.
A rede criada recebe um intervalo específico de endereços intranet (por exemplo, 192.168.10.0/24) e é estabelecida uma ligação entre os endereços internos e os certificados dos hosts. Diversos mecanismos são fornecidos para contornar tradutores de endereços (NAT) e firewalls. É possível organizar a roteação através de uma rede sobreposta de tráfego de hosts externos que não fazem parte da rede Nebula (rota insegura). Grupos podem ser formados entre os participantes da rede sobreposta, por exemplo, para separar servidores e estações de trabalho, aos quais se aplicam regras de filtragem de tráfego distintas.
É suportada a criação de firewalls para separar o acesso e filtrar o tráfego entre os nós na rede sobreposta Nebula. Para filtragem, são aplicadas ACLs com vínculo de tags. Cada host na rede pode definir suas próprias regras de filtragem por hosts, grupos, protocolos e portas de rede. Nesse processo, os hosts são filtrados não por endereços IP, mas por identificadores assinados digitalmente, que não podem ser falsificados sem comprometer a autoridade certificadora que coordena o trabalho da rede.
No novo lançamento:
- Foi adicionada uma nova configuração default_local_cidr_any, que altera o comportamento ao processar sub-redes "local_ip" nas regras do firewall para evitar o acesso inadequado ao tráfego para hosts listados no bloco unsafe_routes. Na versão 1.9, a configuração é definida como "true", mas na próxima versão, 1.10, será substituída pelo valor "false", o que levará à consideração de sub-redes locais ao aplicar regras de firewall a hosts acessíveis por rotas inseguras (para liberar acesso a esses hosts, será necessário especificar local_cidr).
- Fornecida uma imagem oficial para o sistema Docker, permitindo a rápida implementação de uma rede sobreposta baseada em Nebula ou um nó para ela.
- Adicionadas compilações experimentais para a arquitetura Loong64.
- Implementado um script de serviço para o sistema de inicialização OpenRC.
- O processo em segundo plano SSH agora suporta autenticação com certificados assinados por uma autoridade certificadora (sshd.trusted_cas). Implementada a possibilidade de embutir chaves de host no bloco de configurações sshd.host_key.
- O suporte para reinicialização das configurações "tun.unsafe_routes" foi garantido.
- O suporte para a configuração obsoleta local_range foi removido, devendo-se utilizar preferred_ranges em seu lugar.
- Agora é necessário o Go 1.22 para construção. Os requisitos mínimos para versões do Windows foram aumentados para Windows 10 e Windows Server 2016.
Fonte: opennet.ru
