{"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\/it\/blog\/news\/vypusk-nebula-1-9-sistemy-dlya-sozdaniya-overlejnyh-p2p-setej","title":{"rendered":"Rilascio di Nebula 1.9, sistema per la creazione di reti P2P sovrapposte","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\u00c8 stato pubblicato il rilascio del progetto Nebula 1.9, che offre strumenti per la creazione di reti overlay sicure, consentendo di unire host territorialmente separati in una rete isolata che opera sopra la rete globale. Il progetto \u00e8 destinato alla creazione di reti overlay personalizzate per qualsiasi esigenza, ad esempio per unire computer aziendali in diversi uffici, server in diversi data center o ambienti virtuali presso diversi fornitori di cloud. Il codice \u00e8 scritto in Go ed \u00e8 distribuito sotto licenza MIT. Il progetto \u00e8 sviluppato dall'azienda Slack, che gestisce l'omonimo messenger aziendale. \u00c8 supportato su Linux, FreeBSD, macOS, Windows, iOS e Android. <\/p>\n

I nodi nella rete Nebula interagiscono tra loro direttamente in modalit\u00e0 P2P \u2013 man mano che sorge la necessit\u00e0 di trasferire dati tra i nodi, vengono create dinamicamente connessioni dirette. VPN<\/a>L'identit\u00e0 di ogni host nella rete \u00e8 confermata da un certificato digitale, e la connessione alla rete richiede l'autenticazione \u2013 ogni utente riceve un certificato che verifica l'indirizzo IP nella rete Nebula, il nome e l'appartenenza ai gruppi di host. I certificati sono firmati da un'autorit\u00e0 di certificazione interna, implementata dal creatore di ciascuna rete specifica sulle proprie infrastrutture e utilizzata per certificare le autorizzazioni degli host che possono connettersi a una particolare rete overlay, collegata a tale autorit\u00e0 di certificazione. <\/p>\n

Per creare un canale di comunicazione autenticato e protetto in Nebula, viene utilizzato un protocollo di tunneling proprietario, basato sul protocollo di scambio di chiavi di Diffie-Hellman e sul cifrario AES-256-GCM. L'implementazione del protocollo si basa su primitivi pronti e collaudati, forniti dal framework Noise, anch'esso utilizzato in progetti come WireGuard, Lightning e I2P. Si afferma che il progetto abbia superato una revisione indipendente della sicurezza. <\/p>\n

Per rilevare altri nodi e coordinare le connessioni alla rete, vengono creati nodi speciali 'lighthouse', i cui indirizzi IP globali sono fissi e noti ai partecipanti alla rete. I nodi partecipanti non sono legati a fonti esterne. indirizzo IP<\/a>, sono identificati dai certificati. I proprietari degli host non possono apportare modifiche ai certificati firmati e, a differenza delle reti IP tradizionali, non possono spacciarsi per un altro host semplicemente cambiando indirizzo IP. Durante la creazione del tunnel, l'identit\u00e0 dell'host \u00e8 confermata da una chiave privata individuale. <\/p>\n

Alla rete creata viene assegnato un intervallo specifico di indirizzi intranet (ad esempio, 192.168.10.0\/24) e si effettua il collegamento degli indirizzi interni ai certificati degli host. Vengono forniti vari meccanismi per eludere i traduttori di indirizzi (NAT) e i firewall. \u00c8 possibile organizzare il routing attraverso una rete overlay di traffico di host esterni non appartenenti alla rete Nebula (unsafe route). Dai partecipanti alla rete overlay possono formarsi gruppi, ad esempio, per separare server e workstation, ai quali si applicano regole di filtraggio del traffico separate. <\/p>\n

\u00c8 supportata la creazione di firewall per separare l'accesso e filtrare il traffico tra i nodi nella rete overlay Nebula. Per il filtraggio vengono applicati ACL con l'associazione di tag. Ogni host nella rete pu\u00f2 definire le proprie regole di filtraggio per host, gruppi, protocolli e porte di rete. In questo caso, gli host vengono filtrati non in base agli indirizzi IP, ma in base agli identificatori degli host firmati digitalmente, che non possono essere falsificati senza compromettere l'autorit\u00e0 di certificazione che coordina l'operativit\u00e0 della rete. <\/p>\n

Nel nuovo rilascio: <\/p>\n