La version 1.9 du projet Nebula a été publiée, proposant des outils pour construire des réseaux superposés sécurisés, permettant de relier des hôtes géographiquement dispersés en un réseau isolé fonctionnant sur Internet. Ce projet est destiné à créer vos propres réseaux superposés pour divers besoins, par exemple, pour relier des ordinateurs d'entreprise dans différents bureaux, des serveurs dans divers centres de données ou des environnements virtuels chez différents fournisseurs de cloud. Le code est écrit en Go et est distribué sous licence MIT. Le projet est basé sur la société Slack, qui développe le messager d'entreprise éponyme. Il prend en charge le fonctionnement sous Linux, FreeBSD, macOS, Windows, iOS et Android.
Les nœuds du réseau Nebula interagissent directement entre eux en mode P2P — au fur et à mesure de la nécessité de transférer des données entre les nœuds, des connexions directes sont créées dynamiquement. VPN- connexions. L'identité de chaque hôte dans le réseau est vérifié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, son nom et son appartenance aux groupes d'hôtes. Les certificats sont signés par une autorité de certification interne déployée par le créateur de chaque réseau particulier dans ses propres installations, et utilisée pour certifier les autorisations des hôtes autorisés à se connecter à un réseau superposé spécifique lié à l'autorité de certification.
Pour établir un canal de communication authentifié et sécurisé dans Nebula, un protocole de tunnel propre, basé sur le protocole d’échange de clés de Diffie-Hellman et le chiffrement AES-256-GCM, est utilisé. L’implémentation du protocole repose sur des primitives éprouvées fournies par le framework Noise, également utilisé dans des projets tels que WireGuard, Lightning et I2P. Il est affirmé que le projet a passé un audit de sécurité indépendant.
Pour découvrir d'autres nœuds et coordonner les connexions au réseau, des nœuds spéciaux appelés « lighthouse » sont créés, dont les adresses IP globales sont fixes et connues des participants du réseau. Les nœuds participants ne sont pas liés à un extérieur, ils sont identifiés par des certificats. une adresse IPLes propriétaires d’hôtes ne peuvent pas apporter de modifications aux certificats signés et, contrairement aux réseaux IP traditionnels, ne peuvent pas se faire passer pour un autre hôte simplement en changeant d'adresse IP. Lors de la création d'un tunnel, l'identité de l'hôte est confirmée par une clé privée individuelle.
Un certain éventail d'adresses intranet est attribué au réseau créé (par exemple, 192.168.10.0/24) et l'association des adresses internes avec les certificats des hôtes est effectuée. Divers mécanismes sont fournis pour contourner les traducteurs d'adresses (NAT) et les pare-feu. Il est possible d'organiser le routage à travers le réseau superposé du trafic d'hôtes tiers n'appartenant pas à Nebula (route non sécurisée). Des groupes peuvent être formés parmi les participants du réseau superposé, par exemple, pour séparer les serveurs des stations de travail, auxquels des règles de filtrage du trafic différentes sont appliquées.
La création de pare-feu pour segmenter l'accès et filtrer le trafic entre les nœuds dans le réseau superposé Nebula est prise en charge. Des ACL avec des balises sont utilisées pour le filtrage. Chaque hôte du réseau peut définir ses propres règles de filtrage par hôte, groupes, protocoles et ports réseau. Les hôtes sont filtrés non pas par adresses IP, mais par des identifiants de hôte signés numériquement, qu'il est impossible de falsifier sans compromettre l'autorité de certification coordonnant le fonctionnement du réseau.
Dans cette nouvelle version :
- Une nouvelle configuration default_local_cidr_any a été ajoutée, modifiant le comportement lors du traitement des sous-réseaux «local_ip» dans les règles de pare-feu pour éviter la délivrance injustifiée de trafic aux hôtes répertoriés dans le bloc unsafe_routes. Dans la version 1.9, la configuration est définie sur «true», mais dans la prochaine version 1.10, elle sera remplacée par «false», ce qui entraînera la prise en compte des sous-réseaux locaux lors de l'application des règles de pare-feu aux hôtes accessibles via des routes non sécurisées (il sera nécessaire de spécifier local_cidr pour accéder à de tels hôtes).
- Une image officielle pour le système Docker a été fournie, permettant de déployer rapidement un réseau superposé basé sur Nebula ou un nœud pour celui-ci.
- Des builds expérimentales pour l'architecture Loong64 ont été ajoutés.
- Un script de service pour le système d'initialisation OpenRC a été mis en œuvre.
- Le processus en arrière-plan SSH a ajouté la prise en charge de l'authentification par certificats signés par une autorité de certification (sshd.trusted_cas). La possibilité d'incorporer des clés hôtes dans le bloc de paramètres sshd.host_key a été réalisée.
- La prise en charge du redémarrage des paramètres «tun.unsafe_routes» a été assurée.
- Le support de l'ancienne configuration local_range a été supprimé, et il convient d'utiliser preferred_ranges à la place.
- Pour la construction, l'outil Go 1.22 est désormais requis. Les exigences minimales pour les versions de Windows ont été augmentées à Windows 10 et Windows Server 2016.
Source : opennet.ru
