Nach über zwei Jahren Entwicklung wurde die Standardimplementierung des Yggdrasil-Protokolls 0.5 veröffentlicht, die es ermöglicht, ein separates, dezentrales privates IPv6-Netzwerk über ein gewöhnliches globales Netzwerk aufzubauen, um die Privatsphäre zu schützen, wobei End-to-End-Verschlüsselung verwendet wird. Im Yggdrasil-Netzwerk können alle vorhandenen Anwendungen verwendet werden, die IPv6 unterstützen. Die Implementierung ist in der Programmiersprache Go geschrieben und wird unter der Lizenz LGPLv3 verbreitet. Unterstützte Plattformen sind Linux, OpenWRT, Windows, macOS, FreeBSD, OpenBSD, VyOS und Ubiquiti EdgeRouter.
Yggdrasil entwickelt ein neues Routing-Konzept zur Schaffung eines globalen dezentralen Netzwerks, in dem Knoten sowohl direkt in einem Mesh-Netzwerk (zum Beispiel über Wi-Fi oder Bluetooth) verbunden werden können, als auch über bestehende IPv6- oder IPv4-Netzwerke kommunizieren (Netzwerk über Netzwerk). Ein herausragendes Merkmal von Yggdrasil ist die Selbstorganisation der Arbeit, die keine explizite Routerkonfiguration erfordert – Routeninformationen werden basierend auf der Position eines Knotens im Netzwerk im Verhältnis zu anderen Knoten berechnet. Geräte werden über eine gewöhnliche IPv6-Adresse adressiert, die sich nicht ändert, wenn sich der Knoten bewegt (in Yggdrasil wird ein ungenutzter Adressbereich 0200::/7 verwendet).
Das gesamte Yggdrasil-Netzwerk wird nicht als Vereinigung einzelner Subnetze betrachtet, sondern als ein einheitlicher, strukturierter Spannbaum, der einen "Wurzelknoten" hat, wobei jeder Knoten einen Elternknoten und einen oder mehrere Nachkommen hat. Diese baumartige Struktur ermöglicht es, einen Pfad zum Zielknoten relativ zum Quellknoten unter Verwendung des "Locator"-Mechanismus zu erstellen, der den optimalen Weg vom Wurzelknoten zum Knoten bestimmt. Informationen über den Baum werden zwischen den Knoten verteilt und nicht zentral gespeichert.
Um vor Verkehrsanalysen im Netzwerk zu schützen, wird End-to-End-Verschlüsselung angewendet (Transitrouten können den Inhalt nicht bestimmen), jedoch wird keine Anonymität garantiert – beim Anschluss über das Internet können Peer-Knoten, mit denen direkte Interaktionen stattfinden, die echte IP-Adresse ermitteln. Daher wird empfohlen, die Knoten über Tor oder I2P zu verbinden.
Trotz der Tatsache, dass sich das Projekt in der Alpha-Entwicklungsphase befindet, ist es bereits ausreichend stabil für die tägliche Nutzung, garantiert jedoch keine Abwärtskompatibilität zwischen den Versionen. Für Yggdrasil wird von der Community eine Reihe von Diensten unterstützt, einschließlich einer Plattform für die Bereitstellung von Linux-Containern für Hosting seine Websites, die Suchmaschine YaCy, den Kommunikationsserver Matrix, einen IRC-Server, DNS, ein VoIP-System, einen BitTorrent-Tracker, eine Karte der Verbindungspunkte, ein Gateway zu IPFS und ein Proxy für den Zugriff auf die Netzwerke Tor, I2P und Clearnet.
In der neuen Version:
- Die Möglichkeit der Authentifizierung der Verbindung zu Peers mit einem Passwort wurde hinzugefügt. Das Passwort wird über den Parameter „password=“ festgelegt, zum Beispiel „tls://a.b.c.d:12345?password=123456abcdef“.
- Die Möglichkeit zur Nutzung des QUIC-Protokolls basierend auf UDP für die Interaktion mit Peers wurde hinzugefügt. Um QUIC zu verwenden, sollte das URI-Schema quic:// in den Direktiven Listen und Peers angegeben werden, aber die Unterstützung für QUIC wurde bisher nicht so gut getestet wie TCP und TLS.
- Die Option PrivateKeyPath wurde hinzugefügt, die es ermöglicht, den privaten Schlüssel im PEM-Format separat von der Hauptkonfigurationsdatei zu speichern. Für den Export des Schlüssels in eine separate Datei kann die Option „-exportkey“ verwendet werden.
- Ein neues Routing-Schema wurde implementiert, das nicht abwärtskompatibel mit früheren Versionen ist (Knoten mit Yggdrasil 0.5 können nicht mit Hosts auf Basis von Yggdrasil 0.4 interagieren), aber viele der zuvor in der Version 0.4 vorhandenen Stabilitäts- und Skalierbarkeitsprobleme löst und den Speicherverbrauch erheblich reduziert sowie den Datenverkehr bei fehlender Netzwerkaktivität senkt.
In der neuen Implementierung werden für die Verfolgung von Verbindungen und Knoten eine probabilistische Datenstruktur des Bloom-Filters verwendet. Die verteilte Hash-Tabelle (DHT) wird nicht mehr für den Austausch von Routingdaten und das Binding von öffentlichen Schlüsseln im baumartigen Netzwerk verwendet.
Um die lokale Konsistenz aufrechtzuerhalten und die Abhängigkeit von Routen zu den Root-Knoten zu reduzieren, übertragen Knoten nun separat Informationen über jede Verbindung, die in CRDT-Strukturen verfolgt werden. Anstelle von Routing von der Quelle wird ein Routing basierend auf einem gierigen Algorithmus verwendet (Anfragen werden an den nächstgelegenen Nachbarknoten gesendet).
Die Formate, die bei der Genehmigung von Verbindungen und Multicast-Versand verwendet werden, wurden für eine bessere Erweiterbarkeit überarbeitet. Der Code zur Verarbeitung von Verbindungen wurde überarbeitet, um eine zuverlässigere Überwachung des Peer-Status zu gewährleisten. Eine separate Überwachung der Zeitintervalle zwischen wiederholten Verbindungen für jeden konfigurierten Peer wurde sichergestellt.
Zur Erkennung von Ausfällen werden anstelle des regelmäßigen Sendens separater Keepalive-Anfragen Bestätigungsnachrichten für den Datenverkehr eingesetzt, die es ermöglichen, den Datenverkehr bei Inaktivität im Netzwerk zu vermeiden (was beispielsweise den Energieverbrauch auf mobilen Geräten senkt, da der Datenverkehr im Leerlauf ausgeschlossen wird).
Quelle: opennet.ru
