{"id":102274,"date":"2021-11-12T21:36:38","date_gmt":"2021-11-12T19:36:38","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/vypusk-nebula-1-5-sistemy-dlya-sozdaniya-overlejnyh-p2p-setej"},"modified":"2021-11-12T21:36:38","modified_gmt":"2021-11-12T19:36:38","slug":"vypusk-nebula-1-5-sistemy-dlya-sozdaniya-overlejnyh-p2p-setej","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/news\/vypusk-nebula-1-5-sistemy-dlya-sozdaniya-overlejnyh-p2p-setej","title":{"rendered":"Nebula 1.5 Edition, Systeme zur Erstellung von Overlay-P2P-Netzen","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Die Edition des Nebula 1.5 Projekts ist verf\u00fcgbar und bietet Werkzeuge zum Aufbau von sicheren Overlay-Netzen. Das Netzwerk kann von mehreren bis zu zehntausenden territorial getrennten Hosts bestehen, die bei verschiedenen Anbietern gehostet werden und ein separates isoliertes Netzwerk \u00fcber dem globalen Netzwerk bilden. Das Projekt ist in Go geschrieben und wird unter der MIT-Lizenz ver\u00f6ffentlicht. Es wurde von der Firma Slack, die den gleichnamigen Unternehmensmessenger entwickelt, ins Leben gerufen. Die Nutzung wird in Linux, FreeBSD, macOS, Windows, iOS und Android unterst\u00fctzt. <\/p>\n

Die Knoten im Nebula-Netzwerk kommunizieren direkt im P2P-Modus miteinander \u2013 direkte Verbindungen werden dynamisch aufgebaut, sobald der Bedarf besteht, Daten zwischen Knoten zu \u00fcbertragen. VPN<\/a>-Verbindungen. Die Identit\u00e4t jedes Hosts im Netzwerk wird durch ein digitales Zertifikat best\u00e4tigt, und die Verbindung zum Netzwerk erfordert eine Authentifizierung \u2013 jeder Benutzer erh\u00e4lt ein Zertifikat, das die IP-Adresse im Nebula-Netzwerk, den Namen und die Mitgliedschaft in Hostgruppen best\u00e4tigt. Die Zertifikate werden von einer internen Zertifizierungsstelle signiert, die vom Netzwerkadministrator auf seinen Ressourcen bereitgestellt wird und zur Best\u00e4tigung der Berechtigungen der Hosts, die das Overlay-Netzwerk betreten d\u00fcrfen, verwendet wird. <\/p>\n

Um einen authentifizierten, sicheren Kommunikationskanal in Nebula zu schaffen, wird ein hauseigenes Tunnelprotokoll verwendet, das auf dem Diffie-Hellman-Schl\u00fcsselaustauschprotokoll und dem AES-256-GCM-Verschl\u00fcsselungsalgorithmus basiert. Die Implementierung des Protokolls st\u00fctzt sich auf bestehende und bew\u00e4hrte Primitiven, die vom Noise-Framework bereitgestellt werden, das auch in Projekten wie WireGuard, Lightning und I2P verwendet wird. Es wird behauptet, dass das Projekt eine unabh\u00e4ngige Sicherheits\u00fcberpr\u00fcfung durchlaufen hat. <\/p>\n

Um andere Knoten zu erkennen und die Verbindungen zum Netzwerk zu koordinieren, werden spezielle Knoten 'lighthouse' erstellt, deren globale IP-Adressen festgelegt und den Teilnehmern des Netzwerks bekannt sind. Die Teilnehmerknoten sind nicht an externe gebunden. IP-Adresse<\/a>, sie werden durch Zertifikate identifiziert. Die Eigent\u00fcmer der Hosts k\u00f6nnen keine \u00c4nderungen an den signierten Zertifikaten vornehmen und im Gegensatz zu traditionellen IP-Netzen k\u00f6nnen sie sich nicht einfach durch \u00c4ndern der IP-Adresse als ein anderer Host ausgeben. Bei der Erstellung eines Tunnels wird die Identit\u00e4t des Hosts durch einen individuellen privaten Schl\u00fcssel best\u00e4tigt. <\/p>\n

F\u00fcr das erstellte Netzwerk wird ein bestimmter Bereich von Intranetadressen zugewiesen (zum Beispiel 192.168.10.0\/24), und es erfolgt eine Zuordnung interner Adressen zu den Hostzertifikaten. Aus den Teilnehmern des Overlay-Netzwerks k\u00f6nnen Gruppen gebildet werden, beispielsweise zur Trennung von Servern und Arbeitsstationen, f\u00fcr die jeweils separate Regeln zur Filterung des Datenverkehrs gelten. Verschiedene Mechanismen werden bereitgestellt, um Adress\u00fcbersetzung (NAT) und Firewalls zu umgehen. Es ist m\u00f6glich, die Routen durch Overlay-Netzwerke von externen Hosts, die nicht Teil des Nebula-Netzwerks sind (unsafe route), zu organisieren. <\/p>\n

Es wird die Erstellung von Firewalls unterst\u00fctzt, um den Zugang zu trennen und den Datenverkehr zwischen Knoten im Nebula-Overlay-Netzwerk zu filtern. F\u00fcr die Filterung kommen ACLs mit Tag-Zuordnung zum Einsatz. Jeder Host im Netzwerk kann eigene Filterregeln f\u00fcr Hosts, Gruppen, Protokolle und Netzwerkports definieren. Dabei werden Hosts nicht nach IP-Adressen, sondern nach signierten Identifikatoren gefiltert, deren F\u00e4lschung ohne Kompromittierung des koordinierenden Netz-CA nicht m\u00f6glich ist. <\/p>\n

In der neuen Version: <\/p>\n