Le lancement de la nouvelle version de Nebula 1.5 qui se positionne comme un ensemble d'outils pour construire des réseaux superposés sécurisés Ils peuvent relier plusieurs à plusieurs dizaines de milliers d'hôtes géographiquement séparés, formant un réseau isolé séparé au-dessus du réseau mondial.
Le projet est conçu pour créer vos propres réseaux superposés pour tout besoin, par exemple, pour combiner des ordinateurs d'entreprise dans différents bureaux, des serveurs dans différents centres de données ou des environnements virtuels de différents fournisseurs de cloud.
À propos de Nébuleuse
Les nœuds du réseau Nebula communiquent directement entre eux en mode P2P, puisque la nécessité de transférer des données entre les nœudss crée dynamiquement des connexions VPN directes. L'identité de chaque hôte sur le réseau est confirmée par un certificat numérique, et la connexion au réseau nécessite une authentification ; chaque utilisateur reçoit un certificat confirmant l'adresse IP dans le réseau Nebula, le nom et l'appartenance aux groupes d'hôtes.
Les certificats sont signés par une autorité de certification interne, mis en œuvre par le créateur de chaque réseau individuel dans ses propres installations, et utilisés pour certifier l'autorité des hôtes qui ont le droit de se connecter à un réseau superposé spécifique lié à l'autorité de certification.
Pour créer un canal de communication sécurisé authentifié, Nebula utilise son propre protocole de tunneling basé sur le protocole d'échange de clés Diffie-Hellman et le cryptage AES-256-GCM. La mise en œuvre du protocole est basée sur des primitives prêtes à l'emploi et testées fournies par le framework Noise, qui est également utilisé dans des projets comme WireGuard, Lightning et I2P. Le projet aurait passé avec succès un audit de sécurité indépendant.
Pour découvrir d'autres nœuds et coordonner la connexion au réseau, des nœuds « balises » sont créés spéciaux, dont les adresses IP globales sont fixes et connues des participants au réseau. Les nœuds participants n'ont pas de lien vers une adresse IP externe, ils sont identifiés par des certificats. Les propriétaires d'hôtes ne peuvent pas modifier les certificats auto-signés et, contrairement aux réseaux IP traditionnels, ils ne peuvent pas prétendre être un autre hôte en modifiant simplement l'adresse IP. Lorsqu'un tunnel est créé, l'identité de l'hôte est validée par rapport à une clé privée individuelle.
Le réseau créé se voit attribuer une certaine plage d'adresses intranet (par exemple, 192.168.10.0/24) et les adresses internes sont liées à des certificats d'hôte. Des groupes peuvent être formés à partir de participants dans le réseau superposé, par exemple pour séparer les serveurs et les postes de travail, auxquels des règles de filtrage de trafic distinctes sont appliquées. Divers mécanismes sont fournis pour traverser les traducteurs d'adresses (NAT) et les pare-feu. Il est possible d'organiser le routage via le réseau de superposition du trafic provenant d'hôtes tiers qui ne sont pas inclus dans le réseau Nebula (route non sécurisée).
En outre, prend en charge la création de pare-feu pour séparer les accès et filtrer le trafic entre les nœuds du réseau Nebula superposé. Les listes de contrôle d'accès liées aux balises sont utilisées pour le filtrage. Chaque hôte du réseau peut définir ses propres règles de filtrage pour les hôtes, les groupes, les protocoles et les ports du réseau. Dans le même temps, les hôtes ne sont pas filtrés par adresses IP, mais par des identifiants d'hôtes signés numériquement, qui ne peuvent être falsifiés sans compromettre le centre de certification qui coordonne le réseau.
Le code est écrit en Go et est sous licence du MIT. Le projet a été fondé par Slack, qui développe le messager d'entreprise du même nom. Il prend en charge Linux, FreeBSD, macOS, Windows, iOS et Android.
En ce qui concerne les changements qui ont été mis en œuvre dans la nouvelle version sont les suivants:
- Ajout de l'indicateur "-raw" à la commande print-cert pour imprimer la représentation PEM du certificat.
- Ajout de la prise en charge de la nouvelle architecture Linux riscv64.
- Ajout du paramètre expérimental remote_allow_ranges pour lier les listes d'hôtes autorisés à des sous-réseaux spécifiques.
- Ajout de l'option pki.disconnect_invalid pour réinitialiser les tunnels après la fin de la confiance ou l'expiration du certificat.
- Ajout de l'option unsafe_routes. .metric pour définir le poids d'un chemin externe spécifique.
Enfin, si vous souhaitez en savoir plus, vous pouvez consulter ses coordonnées et/ou documentation dans le lien suivant.