{"id":115651,"date":"2024-05-09T13:52:14","date_gmt":"2024-05-09T11:52:14","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/vypusk-nebula-1-9-sistemy-dlya-sozdaniya-overlejnyh-p2p-setej"},"modified":"2024-05-09T13:52:14","modified_gmt":"2024-05-09T11:52:14","slug":"vypusk-nebula-1-9-sistemy-dlya-sozdaniya-overlejnyh-p2p-setej","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/news\/vypusk-nebula-1-9-sistemy-dlya-sozdaniya-overlejnyh-p2p-setej","title":{"rendered":"Sortie de Nebula 1.9, un syst\u00e8me pour cr\u00e9er des r\u00e9seaux P2P superpos\u00e9s","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

La version 1.9 du projet Nebula a \u00e9t\u00e9 publi\u00e9e, proposant des outils pour construire des r\u00e9seaux superpos\u00e9s s\u00e9curis\u00e9s, permettant de relier des h\u00f4tes g\u00e9ographiquement dispers\u00e9s en un r\u00e9seau isol\u00e9 fonctionnant sur Internet. Ce projet est destin\u00e9 \u00e0 cr\u00e9er vos propres r\u00e9seaux superpos\u00e9s pour divers besoins, par exemple, pour relier des ordinateurs d'entreprise dans diff\u00e9rents bureaux, des serveurs dans divers centres de donn\u00e9es ou des environnements virtuels chez diff\u00e9rents fournisseurs de cloud. Le code est \u00e9crit en Go et est distribu\u00e9 sous licence MIT. Le projet est bas\u00e9 sur la soci\u00e9t\u00e9 Slack, qui d\u00e9veloppe le messager d'entreprise \u00e9ponyme. Il prend en charge le fonctionnement sous Linux, FreeBSD, macOS, Windows, iOS et Android. <\/p>\n

Les n\u0153uds du r\u00e9seau Nebula interagissent directement entre eux en mode P2P \u2014 des connexions directes sont dynamiquement \u00e9tablies \u00e0 mesure que la n\u00e9cessit\u00e9 de transmettre des donn\u00e9es entre les n\u0153uds se pr\u00e9sente. VPN<\/a>-connexions. L'identit\u00e9 de chaque h\u00f4te dans le r\u00e9seau est confirm\u00e9e par un certificat num\u00e9rique, et la connexion au r\u00e9seau n\u00e9cessite une authentification \u2014 chaque utilisateur re\u00e7oit un certificat confirmant l'adresse IP dans le r\u00e9seau Nebula, son nom et son appartenance aux groupes d'h\u00f4tes. Les certificats sont sign\u00e9s par une autorit\u00e9 de certification interne d\u00e9ploy\u00e9e par le cr\u00e9ateur de chaque r\u00e9seau sur ses propres infrastructures et utilis\u00e9e pour certifier les autorisations des h\u00f4tes ayant le droit de se connecter \u00e0 un r\u00e9seau overlay sp\u00e9cifique li\u00e9 \u00e0 l'autorit\u00e9 de certification. <\/p>\n

Pour cr\u00e9er un canal de communication authentifi\u00e9 et s\u00e9curis\u00e9 dans Nebula, un protocole de tunnel propri\u00e9taire est utilis\u00e9, bas\u00e9 sur le protocole d'\u00e9change de cl\u00e9s Diffie-Hellman et le chiffrement AES-256-GCM. L'impl\u00e9mentation du protocole repose sur des primitives \u00e9prouv\u00e9es fournies par le cadre Noise, qui est \u00e9galement utilis\u00e9 dans des projets tels que WireGuard, Lightning et I2P. Il est affirm\u00e9 que le projet a pass\u00e9 un audit de s\u00e9curit\u00e9 ind\u00e9pendant. <\/p>\n

Pour d\u00e9couvrir d'autres n\u0153uds et coordonner les connexions au r\u00e9seau, des n\u0153uds sp\u00e9ciaux \u00ab lighthouse \u00bb sont cr\u00e9\u00e9s, dont les adresses IP globales sont fixes et connues des participants au r\u00e9seau. Les n\u0153uds participants n'ont pas d'attache \u00e0 des adresses externes. une adresse IP<\/a>Les propri\u00e9taires d\u2019h\u00f4tes ne peuvent pas apporter de modifications aux certificats sign\u00e9s et, contrairement aux r\u00e9seaux IP traditionnels, ne peuvent pas se faire passer pour un autre h\u00f4te simplement en changeant d'adresse IP. Lors de la cr\u00e9ation d'un tunnel, l'identit\u00e9 de l'h\u00f4te est confirm\u00e9e par une cl\u00e9 priv\u00e9e individuelle. <\/p>\n

Un certain \u00e9ventail d'adresses intranet est attribu\u00e9 au r\u00e9seau cr\u00e9\u00e9 (par exemple, 192.168.10.0\/24) et l'association des adresses internes avec les certificats des h\u00f4tes est effectu\u00e9e. Divers m\u00e9canismes sont fournis pour contourner les traducteurs d'adresses (NAT) et les pare-feu. Il est possible d'organiser le routage \u00e0 travers le r\u00e9seau superpos\u00e9 du trafic d'h\u00f4tes tiers n'appartenant pas \u00e0 Nebula (route non s\u00e9curis\u00e9e). Des groupes peuvent \u00eatre form\u00e9s parmi les participants du r\u00e9seau superpos\u00e9, par exemple, pour s\u00e9parer les serveurs des stations de travail, auxquels des r\u00e8gles de filtrage du trafic diff\u00e9rentes sont appliqu\u00e9es. <\/p>\n

La cr\u00e9ation de pare-feu pour segmenter l'acc\u00e8s et filtrer le trafic entre les n\u0153uds dans le r\u00e9seau superpos\u00e9 Nebula est prise en charge. Des ACL avec des balises sont utilis\u00e9es pour le filtrage. Chaque h\u00f4te du r\u00e9seau peut d\u00e9finir ses propres r\u00e8gles de filtrage par h\u00f4te, groupes, protocoles et ports r\u00e9seau. Les h\u00f4tes sont filtr\u00e9s non pas par adresses IP, mais par des identifiants de h\u00f4te sign\u00e9s num\u00e9riquement, qu'il est impossible de falsifier sans compromettre l'autorit\u00e9 de certification coordonnant le fonctionnement du r\u00e9seau. <\/p>\n

Dans cette nouvelle version : <\/p>\n