{"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\/de\/blog\/news\/vypusk-nebula-1-9-sistemy-dlya-sozdaniya-overlejnyh-p2p-setej","title":{"rendered":"Ver\u00f6ffentlichung von Nebula 1.9, einem System zur Erstellung von Overlay-P2P-Netzen","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Die Ver\u00f6ffentlichung der Nebula 1.9-Projekts bietet Werkzeuge zum Aufbau sicherer Overlay-Netzwerke, die geografisch getrennte Hosts in ein separates, isoliertes Netz integrieren, das \u00fcber das globale Netzwerk arbeitet. Das Projekt zielt darauf ab, individuelle Overlay-Netzwerke f\u00fcr verschiedene Bed\u00fcrfnisse zu schaffen, beispielsweise zur Verkn\u00fcpfung von Unternehmenscomputern in verschiedenen B\u00fcros, Servern in verschiedenen Rechenzentren oder virtuellen Umgebungen bei unterschiedlichen Cloud-Anbietern. Der Code ist in Go geschrieben und wird unter der MIT-Lizenz vertrieben. Das Projekt wird von der Firma Slack unterst\u00fctzt, die auch den gleichnamigen Unternehmensmessenger entwickelt. Die Nutzung erfolgt auf Linux, FreeBSD, macOS, Windows, iOS und Android. <\/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>Die Identit\u00e4t jedes Hosts im Netzwerk wird durch ein digitales Zertifikat best\u00e4tigt, und der Anschluss an das 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 Ersteller jedes einzelnen Netzwerks auf seinen Ressourcen implementiert wird und zur Beglaubigung der Berechtigungen von Hosts verwendet wird, die das Recht haben, sich mit einem bestimmten Overlay-Netzwerk zu verbinden, das an die Zertifizierungsstelle gebunden ist. <\/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

Der erstellten Netzwerk wird ein bestimmter Bereich von Intranet-Adressen zugewiesen (zum Beispiel 192.168.10.0\/24) und es wird eine Verkn\u00fcpfung der internen Adressen mit den Host-Zertifikaten hergestellt. Es stehen verschiedene Mechanismen zur Verf\u00fcgung, um Adress\u00fcbersetzer (NAT) und Firewalls zu umgehen. Es ist m\u00f6glich, die Routing \u00fcber das Overlay-Netzwerk f\u00fcr den Datenverkehr von Drittanbietern zu organisieren, die nicht Teil des Nebula-Netzwerks sind (unsichere Routen). Aus den Teilnehmern des Overlay-Netzwerks k\u00f6nnen Gruppen gebildet werden, zum Beispiel zur Trennung von Servern und Arbeitsstationen, f\u00fcr die separate Regeln zur Datenverkehrsfilterung gelten. <\/p>\n

Die Erstellung von Firewalls wird unterst\u00fctzt, um den Zugriff zu trennen und den Datenverkehr zwischen Knoten im Nebula-Overlay-Netzwerk zu filtern. F\u00fcr die Filterung werden ACLs mit Tag-Verkn\u00fcpfungen verwendet. Jeder Host im Netzwerk kann eigene Filterregeln basierend auf Hosts, Gruppen, Protokollen und Netzwerkports definieren. Dabei werden Hosts nicht nach IP-Adressen, sondern nach von einer Zertifizierungsstelle signierten Host-IDs gefiltert, die nicht gef\u00e4lscht werden k\u00f6nnen, ohne die Funktionsweise der Netzwerkzertifizierungsstelle zu kompromittieren. <\/p>\n

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