Die Veröffentlichung von Nebula 1.5 ist verfügbar und bietet ein Toolkit zur Erstellung von sicheren Overlay-Netzwerken. Das Netzwerk kann von wenigen bis zu mehreren zehntausend geografisch verteilten Hosts kombiniert werden, die bei verschiedenen Anbietern untergebracht sind und ein separates, isoliertes Netzwerk über dem globalen Netzwerk bilden. Das Projekt ist in Go geschrieben und unter der MIT-Lizenz verfügbar. Es wird von Slack, dem Unternehmen hinter dem gleichnamigen Unternehmens-Messaging-Dienst, betrieben. Die Nutzung wird auf Linux, FreeBSD, macOS, Windows, iOS und Android unterstützt.
Die Knoten im Nebula-Netzwerk kommunizieren direkt im P2P-Modus miteinander – bei Bedarf werden dynamisch direkte Verbindungen zur Datenübertragung zwischen den Knoten hergestellt. VPN-Verbindungen. Die Identität jedes Hosts im Netzwerk wird durch ein digitales Zertifikat bestätigt, und der Zugang 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. Die Zertifikate werden von einer internen Zertifizierungsstelle signiert, die vom Netzwerkinhaber auf seinen Ressourcen bereitgestellt wird und zur Bestätigung der Berechtigungen von Hosts verwendet wird, die berechtigt sind, sich mit dem Overlay-Netzwerk zu verbinden.
Zur Schaffung eines authentifizierten, sicheren Kommunikationskanals wird in Nebula ein proprietäres Tunnelprotokoll verwendet, das auf dem Schlüsselvereinbarungsprotokoll von Diffie-Hellman und dem AES-256-GCM Verschlüsselungsalgorithmus basiert. Die Implementierung des Protokolls stützt sich auf bewährte und erprobte 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 Sicherheitsüberprüfung bestanden hat.
Zur Erkennung anderer Knoten und zur Koordination der Verbindungen im Netzwerk werden spezielle Knoten namens „Lighthouse“ eingerichtet, deren globale IP-Adressen festgelegt und den Teilnehmern des Netzwerks bekannt sind. Die Teilnehmerknoten sind nicht an externe IP-Adressen gebunden; sie werden durch Zertifikate identifiziert. Die Besitzer von Hosts können keine Änderungen an den signierten Zertifikaten vornehmen und können sich im Gegensatz zu herkömmlichen IP-Netzen nicht einfach durch einen Wechsel 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. die IP-Adresse gebunden sindDas erstellte Netzwerk erhält einen bestimmten Bereich von Intranet-Adressen (z. B. 192.168.10.0/24), und die internen Adressen werden mit den Zertifikaten der Hosts verbunden. Es stehen verschiedene Mechanismen zur Verfügung, um Adressübersetzer (NAT) und Firewalls zu umgehen. Eine Organisation der Routing über Overlay-Netzwerke nicht in das Nebula-Netzwerk integrierter Hosts (unsafe route) ist möglich. Aus den Teilnehmern des Overlay-Netzwerks können Gruppen gebildet werden, zum Beispiel zur Trennung von Servern und Arbeitsstationen, für die separate Regeln zur Filterung des Datenverkehrs gelten.
Das erstellte Netzwerk erhält einen bestimmten Bereich von Intranet-Adressen (zum Beispiel 192.168.10.0/24), und es erfolgt eine Zuordnung interner Adressen zu Host-Zertifikaten. Aus den Teilnehmern des Overlay-Netzwerks können Gruppen gebildet werden, beispielsweise zur Trennung von Servern und Arbeitsstationen, auf die separate Regeln zur Verkehrsfilterung angewendet werden. Verschiedene Mechanismen stehen zur Verfügung, um Adressübersetzer (NAT) und Firewalls zu umgehen. Es ist möglich, Routing über das Overlay-Netzwerk für den Verkehr von externen Hosts, die nicht zum Nebula-Netzwerk gehören (unsichere Route), zu organisieren.
Die Erstellung von Firewalls zur Trennung des Zugriffs und zur Filterung des Verkehrs zwischen Knoten im Nebula-Overlay-Netzwerk wird unterstützt. Zur Filterung werden ACL mit Tag-Zuordnungen verwendet. Jeder Host im Netzwerk kann eigene Filterregeln basierend auf Hosts, Gruppen, Protokollen und Netzwerkports festlegen. Dabei werden Hosts nicht nach IP-Adressen, sondern anhand von durch digitale Signaturen bestätigten Identifikatoren gefiltert, die ohne Kompromittierung der koordinierenden Komponente des Zertifizierungszentrums nicht gefälscht werden können.
In der neuen Version:
- Dem Befehl print-cert wurde die Option „-raw“ hinzugefügt, um die PEM-Darstellung des Zertifikats auszugeben.
- Unterstützung für die neue Linux-Architektur riscv64 wurde hinzugefügt.
- Eine experimentelle Einstellung remote_allow_ranges wurde hinzugefügt, um Listen erlaubter Hosts an bestimmte Subnetze zu binden.
- Die Option pki.disconnect_invalid wurde hinzugefügt, um Tunnel nach dem Verlust des Vertrauens oder dem Ablauf der Lebensdauer des Zertifikats zurückzusetzen.
- Die Option unsafe_routes.<route>.metric ist verfügbar, um einem bestimmten externen Route eine Gewichtung zuzuweisen.
Quelle: opennet.ru
