Veröffentlichung von Nebula 1.5, einem System zur Erstellung von Overlay-P2P-Netzwerken

Die Veröffentlichung des Nebula 1.5-Projekts ist verfügbar und bietet Tools zum Aufbau sicherer Overlay-Netzwerke. Das Netzwerk kann mehrere bis Zehntausende geografisch getrennte Hosts vereinen, die von verschiedenen Anbietern gehostet werden, und so ein separates isoliertes Netzwerk über dem globalen Netzwerk bilden. Das Projekt ist in Go geschrieben und wird unter der MIT-Lizenz vertrieben. Gegründet wurde das Projekt von Slack, das einen gleichnamigen Corporate Messenger entwickelt. Unterstützt Linux, FreeBSD, macOS, Windows, iOS und Android.

Knoten im Nebula-Netzwerk kommunizieren im P2P-Modus direkt miteinander – direkte VPN-Verbindungen werden dynamisch erstellt, wenn Daten zwischen Knoten übertragen werden müssen. Die Identität jedes Hosts im Netzwerk wird durch ein digitales Zertifikat bestätigt, und die Verbindung zum Netzwerk erfordert eine Authentifizierung – jeder Benutzer erhält ein Zertifikat, das die IP-Adresse im Nebula-Netzwerk, den Namen und die Mitgliedschaft in Hostgruppen bestätigt. Zertifikate werden von einer internen Zertifizierungsstelle signiert, vom Netzwerkersteller in seinen Einrichtungen bereitgestellt und zur Zertifizierung der Autorität von Hosts verwendet, die das Recht haben, eine Verbindung zum Overlay-Netzwerk herzustellen.

Um einen authentifizierten, sicheren Kommunikationskanal zu erstellen, verwendet Nebula ein eigenes Tunnelprotokoll, das auf dem Diffie-Hellman-Schlüsselaustauschprotokoll und der AES-256-GCM-Verschlüsselung basiert. Die Protokollimplementierung basiert auf vorgefertigten und bewährten Grundelementen des Noise-Frameworks, das auch in Projekten wie WireGuard, Lightning und I2P verwendet wird. Das Projekt soll einem unabhängigen Sicherheitsaudit unterzogen worden sein.

Um andere Knoten zu entdecken und Verbindungen zum Netzwerk zu koordinieren, werden spezielle „Leuchtturm“-Knoten erstellt, deren globale IP-Adressen fest und den Netzwerkteilnehmern bekannt sind. Teilnehmende Knoten sind nicht an eine externe IP-Adresse gebunden, sie werden durch Zertifikate identifiziert. Hostbesitzer können keine Änderungen an signierten Zertifikaten selbst vornehmen und können sich im Gegensatz zu herkömmlichen IP-Netzwerken nicht einfach durch Ändern der IP-Adresse als ein anderer Host ausgeben. Beim Erstellen eines Tunnels wird die Identität des Hosts mit einem individuellen privaten Schlüssel überprüft.

Dem erstellten Netzwerk wird ein bestimmter Bereich von Intranetadressen zugewiesen (z. B. 192.168.10.0/24) und die internen Adressen werden mit Host-Zertifikaten verknüpft. Gruppen können beispielsweise von Teilnehmern des Overlay-Netzwerks bis hin zu separaten Servern und Workstations gebildet werden, auf die separate Regeln zur Verkehrsfilterung angewendet werden. Zur Umgehung von Adressübersetzern (NATs) und Firewalls stehen verschiedene Mechanismen zur Verfügung. Es ist möglich, die Weiterleitung des Datenverkehrs von Drittanbieter-Hosts, die nicht Teil des Nebula-Netzwerks sind (unsichere Route), über das Overlay-Netzwerk zu organisieren.

Es unterstützt die Erstellung von Firewalls, um den Zugriff zu trennen und den Datenverkehr zwischen Knoten im Nebula-Overlay-Netzwerk zu filtern. Zur Filterung werden ACLs mit Tag-Bindung verwendet. Jeder Host im Netzwerk kann seine eigenen Filterregeln basierend auf Hosts, Gruppen, Protokollen und Netzwerkports definieren. In diesem Fall werden Hosts nicht nach IP-Adressen, sondern nach digital signierten Host-IDs gefiltert, die nicht gefälscht werden können, ohne das Zertifizierungszentrum zu gefährden, das das Netzwerk koordiniert.

In der neuen Version:

  • Dem Befehl print-cert wurde ein „-raw“-Flag hinzugefügt, um die PEM-Darstellung des Zertifikats zu drucken.
  • Unterstützung für die neue Linux-Architektur riscv64 hinzugefügt.
  • Es wurde eine experimentelle Einstellung „remote_allow_ranges“ hinzugefügt, um Listen zulässiger Hosts an bestimmte Subnetze zu binden.
  • Option pki.disconnect_invalid hinzugefügt, um Tunnel nach Beendigung der Vertrauensstellung oder Ablauf der Zertifikatslebensdauer zurückzusetzen.
  • Unsafe_routes-Option hinzugefügt. .metric, um einer bestimmten externen Route Gewicht zuzuweisen.

Source: opennet.ru

Kommentar hinzufügen