Published project release Nebula 1.9, which offers tools for building secure overlay networks that allow you to combine geographically separated hosts into a separate isolated network operating on top of the global network. The project is designed to create your own overlay networks for any need, for example, to combine corporate computers in different offices, servers in different data centers or virtual environments from different cloud providers. The code is written in Go language and distributed by under 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 in 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 center, deployed by the creator of each individual network at its own facilities and used to certify the authority of hosts that have the right to connect to a specific overlay network tied to the certification center.
Advertisement
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 implementation of the protocol is based on ready-made and proven primitives provided by the framework Noise, 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. 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). 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.
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 authority that coordinates the network.
Advertisement
In the new release:
- Added new setting default_local_cidr_any, which changes the behavior when handling “local_ip” subnets in firewall rules to prevent unreasonably allowing traffic to hosts listed in the unsafe_routes block. In version 1.9, the setting was set to “true”, but in the next release 1.10 it will be changed to “fasle”, which will result in local subnets being taken into account when applying firewall rules to hosts accessible through insecure routes (to open access to such hosts required local_cidr is required).
- Provided by official image for the Docker system, allowing you to quickly deploy an overlay network based on Nebula or a node for it.
- Added experimental builds for the Loong64 architecture.
- Implemented service script for the initialization system OpenRC.
- Support for authentication using certificates certified by a certification authority has been added to the background SSH process (sshd.trusted_cas). Possibility implemented embedding host keys in the sshd.host_key settings block.
- Support provided reboot settings “tun.unsafe_routes”.
- Removed support for the deprecated local_range setting, in favor of preferred_ranges.
- Build now requires go toolkit 1.22. The minimum requirements for Windows versions have been increased to Windows 10 and Windows Server 2016.
Thanks for reading: