Release of Nebula 1.5, a system for creating P2P overlay networks

The release of the Nebula 1.5 project is available, offering tools for building secure overlay networks. The network can unite from several to tens of thousands of geographically separated hosts hosted by different providers, forming a separate isolated network on top of the global network. The project is written in Go and distributed under the MIT license. The project was founded by Slack, which develops a corporate messenger of the same name. Supports Linux, FreeBSD, macOS, Windows, iOS and Android.

Nodes on the Nebula network communicate directly with each other in P2P mode—direct VPN connections are dynamically created as data needs to be transferred between nodes. The identity of each host on the network is confirmed by a digital certificate, and connecting to the network requires authentication - each user receives a certificate confirming the IP address in the Nebula network, name and membership in host groups. Certificates are signed by an internal certification authority, deployed by the network creator at its facilities and used to certify the authority of hosts that have the right to connect to the overlay network.

To create an authenticated, secure communication channel, Nebula uses its own tunnel protocol based on the Diffie-Hellman key exchange protocol and the AES-256-GCM cipher. The protocol implementation is based on ready-made and proven primitives provided by the Noise framework, which is also used in projects such as WireGuard, Lightning and I2P. The project is said to have undergone an independent security audit.

To discover other nodes and coordinate connections to the network, special “lighthouse” nodes are created, the global IP addresses of which are fixed and known to network participants. Participating nodes are not bound to an external IP address; they are identified by certificates. Host owners cannot make changes to signed certificates on their own and, unlike traditional IP networks, cannot pretend to be another host simply by changing the IP address. When a tunnel is created, the host's identity is verified with an individual private key.

The created network is allocated a certain range of intranet addresses (for example, 192.168.10.0/24) and the internal addresses are associated with host certificates. Groups can be formed from participants in the overlay network, for example, to separate servers and workstations, to which separate traffic filtering rules are applied. Various mechanisms are provided to bypass address translators (NATs) and firewalls. It is possible to organize routing through the overlay network of traffic from third-party hosts that are not part of the Nebula network (unsafe route).

It supports the creation of firewalls to separate access and filter traffic between nodes in the Nebula overlay network. ACLs with tag binding are used for filtering. Each host on the network can define its own filtering rules based on hosts, groups, protocols, and network ports. In this case, hosts are filtered not by IP addresses, but by digitally signed host identifiers, which cannot be forged without compromising the certification center coordinating the network.

In the new release:

  • Added a "-raw" flag to the print-cert command to print the PEM representation of the certificate.
  • Added support for the new Linux architecture riscv64.
  • Added an experimental remote_allow_ranges setting to bind lists of allowed hosts to specific subnets.
  • Added pki.disconnect_invalid option to reset tunnels after trust termination or certificate lifetime expires.
  • Added unsafe_routes option. .metric to assign weight to a specific external route.

Source: opennet.ru

Add a comment