Die Version 1.9 des Nebula-Projekts wurde veröffentlicht. Dieses bietet Werkzeuge zum Aufbau gesicherter Overlay-Netzwerke, die es ermöglichen, räumlich getrennte Hosts in einem eigenen isolierten Netzwerk zu vereinen, das über das globale Netzwerk funktioniert. Das Projekt ist dafür konzipiert, eigene Overlay-Netzwerke für verschiedene Zwecke zu erstellen, beispielsweise zur Vernetzung von Unternehmenscomputern in verschiedenen Büros, Servern in diversen Rechenzentren oder virtuellen Umgebungen bei verschiedenen Cloud-Anbietern. Der Code ist in Go geschrieben und unter der MIT-Lizenz veröffentlicht. Das Projekt wurde von Slack ins Leben gerufen, das den gleichnamigen Unternehmensmessenger entwickelt. Es wird Unterstützung für Linux, FreeBSD, macOS, Windows, iOS und Android angeboten.
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 die Verbindung zum Netzwerk erfordert eine Authentifizierung – jeder Benutzer erhält ein Zertifikat, das die IP-Adresse im Nebula-Netzwerk, den Namen und die Zugehörigkeit zu Host-Gruppen bestätigt. Die Zertifikate werden von einer internen Zertifizierungsstelle unterzeichnet, die vom Ersteller jedes einzelnen Netzwerks in dessen Infrastruktur bereitgestellt wird und zur Bestätigung der Berechtigungen von Hosts verwendet wird, die berechtigt sind, sich mit einem bestimmten Overlay-Netzwerk zu verbinden, das an die Zertifizierungsstelle gebunden ist.
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 (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.
Es wird die Erstellung von Firewalls zur Segmentierung des Zugriffs und zur Traffic-Filterung zwischen Knoten im Overlay-Netzwerk Nebula unterstützt. Für die Filterung werden ACLs mit Tag-Bindungen verwendet. Jeder Host im Netzwerk kann seine eigenen Filterregeln basierend auf Hosts, Gruppen, Protokollen und Netzwerkports definieren. Dabei werden Hosts nicht nach IP-Adressen gefiltert, sondern nach zertifizierten, digital signierten Host-IDs, die ohne Kompromittierung der Zertifizierungsstelle, die das Netzwerk koordiniert, nicht gefälscht werden können.
In der neuen Version:
- Eine neue Einstellung default_local_cidr_any wurde hinzugefügt, die das Verhalten bei der Verarbeitung von Subnetzen „local_ip“ in Firewall-Regeln ändert, um die unbegründete Erlaubnis von Traffic zu Hosts im Block unsafe_routes zu verhindern. In Version 1.9 ist die Einstellung auf „true“ gesetzt, wird jedoch in der nächsten Version 1.10 auf „false“ geändert, was dazu führt, dass lokale Subnetze bei der Anwendung von Firewall-Regeln auf Hosts berücksichtigt werden, die über unsichere Routen zugänglich sind (für den Zugriff auf diese Hosts ist eine zwingende Angabe von local_cidr erforderlich).
- Ein offizielles Image für das Docker-System wurde bereitgestellt, das es ermöglicht, schnell ein Overlay-Netzwerk basierend auf Nebula oder einen Knoten dafür bereitzustellen.
- Experimentelle Builds für die Architektur Loong64 wurden hinzugefügt.
- Ein Dienstskript für das OpenRC-Init-System wurde implementiert.
- Die Unterstützung für die Authentifizierung via von einer Zertifizierungsstelle (sshd.trusted_cas) validierten Zertifikaten wurde zum SSH-Hintergrundprozess hinzugefügt. Es wurde die Möglichkeit implementiert, Host-Schlüssel in den Konfigurationsblock sshd.host_key einzufügen.
- Die Unterstützung für das Neuladen der Einstellungen von „tun.unsafe_routes“ wurde gewährleistet.
- Die Unterstützung für die veraltete Einstellung local_range wurde entfernt; stattdessen sollte preferred_ranges verwendet werden.
- Für die Erstellung wird jetzt die Go-Toolchain 1.22 benötigt. Die Mindestanforderungen an Versionen von Windows wurden auf Windows 10 und Windows Server 2016 erhöht.
Quelle: opennet.ru
