Die Edition des Nebula 1.5 Projekts ist verfügbar 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 über dem globalen Netzwerk bilden. Das Projekt ist in Go geschrieben und wird unter der MIT-Lizenz veröffentlicht. 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ützt.
Die Knoten im Nebula-Netzwerk interagieren direkt im P2P-Modus – sobald der Bedarf an einem Datenaustausch zwischen den Knoten besteht, werden dynamisch direkte VPN-Verbindungen hergestellt. 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 den Hostgruppen bestätigt. Die Zertifikate werden von einer internen Zertifizierungsstelle, die der Netzwerkadministrator auf den eigenen Ressourcen betreibt, signiert und dienen zur Bestätigung der Berechtigungen der Hosts, die berechtigt sind, sich mit dem Overlay-Netzwerk zu verbinden.
Für die Erstellung eines authentifizierten sicheren Kommunikationskanals in Nebula wird ein eigener Tunnelprotokoll verwendet, das auf dem Schlüsselaustauschprotokoll von Diffie–Hellman und dem AES-256-GCM-Verschlüsselungsalgorithmus basiert. Die Implementierung des Protokolls stützt sich auf bewährte und getestete Bausteine, 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ängige Sicherheitsprüfung bestanden hat.
Zur Entdeckung anderer Knoten und zur Koordination der Verbindungen zum Netzwerk werden spezielle Knoten mit der Bezeichnung „Lighthouse“ eingerichtet, deren globale IP-Adressen festgelegt und den Teilnehmern des Netzwerks bekannt sind. Teilnehmerknoten haben keine Bindung an externe IP-Adresse, sie werden durch Zertifikate identifiziert. Die Eigentümer der Hosts können keine Änderungen an den signierten Zertifikaten vornehmen und im Gegensatz zu traditionellen IP-Netzen können sie sich nicht einfach durch Ändern der IP-Adresse als ein anderer Host ausgeben. Bei der Erstellung eines Tunnels wird die Identität des Hosts durch einen individuellen privaten Schlüssel bestätigt.
Für 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önnen Gruppen gebildet werden, beispielsweise zur Trennung von Servern und Arbeitsstationen, für die jeweils separate Regeln zur Filterung des Datenverkehrs gelten. Verschiedene Mechanismen werden bereitgestellt, um Adressübersetzung (NAT) und Firewalls zu umgehen. Es ist möglich, die Routen durch Overlay-Netzwerke von externen Hosts, die nicht Teil des Nebula-Netzwerks sind (unsafe route), zu organisieren.
Es wird die Erstellung von Firewalls unterstützt, um den Zugang zu trennen und den Datenverkehr zwischen Knoten im Nebula-Overlay-Netzwerk zu filtern. Für die Filterung kommen ACLs mit Tag-Zuordnung zum Einsatz. Jeder Host im Netzwerk kann eigene Filterregeln für Hosts, Gruppen, Protokolle und Netzwerkports definieren. Dabei werden Hosts nicht nach IP-Adressen, sondern nach signierten Identifikatoren gefiltert, deren Fälschung ohne Kompromittierung des koordinierenden Netz-CA nicht möglich ist.
In der neuen Version:
- Dem Befehl print-cert wurde das Flag „-raw“ hinzugefügt, um die PEM-Darstellung des Zertifikats anzuzeigen.
- Unterstützung für die neue Linux-Architektur riscv64 wurde hinzugefügt.
- Eine experimentelle Einstellung remote_allow_ranges wurde hinzugefügt, um Listen von erlaubten Hosts bestimmten Subnetzen zuzuordnen.
- Die Option pki.disconnect_invalid wurde hinzugefügt, um Tunnel nach Verlust der Vertrauenswürdigkeit oder Ablauf der Lebensdauer des Zertifikats zurückzusetzen.
- Die Option unsafe_routes..metric wurde hinzugefügt, um einem bestimmten externen Route Gewicht zu verleihen.
Quelle: opennet.ru
