Po ponad dwóch latach prac opublikowano wersję referencyjną protokołu Yggdrasil 0.5, która umożliwia uruchomienie osobnej, zdecentralizowanej prywatnej sieci IPv6 nad zwykłą globalną siecią, w celu ochrony prywatności, z zastosowaniem szyfrowania end-to-end. W sieci Yggdrasil mogą być używane wszelkie istniejące aplikacje wspierające IPv6. Realizacja została napisana w języku Go i jest dostępna na licencji LGPLv3. Wspierane są platformy Linux, OpenWRT, Windows, macOS, FreeBSD, OpenBSD, VyOS i Ubiquiti EdgeRouter.
Yggdrasil rozwija nową koncepcję routingu w celu stworzenia globalnej zdecentralizowanej sieci, w której węzły mogą łączyć się zarówno bezpośrednio ze sobą w trybie sieci mesh (na przykład przez Wi-Fi lub Bluetooth), jak i komunikować się nad istniejącymi sieciami IPv6 lub IPv4 (sieć nad siecią). Cechą charakterystyczną Yggdrasil jest samoorganizacja pracy, która nie wymaga jawnej konfiguracji routingu — informacje o trasach są obliczane na podstawie lokalizacji węzła w sieci w stosunku do innych węzłów. Urządzenia są adresowane za pomocą standardowego adresu IPv6, który nie zmienia się w przypadku przemieszczania się węzła (w Yggdrasil wykorzystywany jest nieużywany zakres adresów 0200::/7).
Cała sieć Yggdrasil jest postrzegana nie jako zbiór rozproszonych podsieci, lecz jako jednolite, zorganizowane drzewo rozpinające, które ma jeden «korzeń», a każdy węzeł ma jednego rodzica i jednego lub kilku potomków. Taka struktura drzewiasta pozwala zbudować trasę do węzła docelowego w odniesieniu do węzła źródłowego za pomocą mechanizmu «locator», który określa optymalną trasę do węzła od korzenia. Informacje o drzewie są rozdzielane pomiędzy węzłami, a nie przechowywane centralnie.
Aby chronić się przed analizą ruchu w sieci, stosuje się szyfrowanie end-to-end (węzły tranzytowe nie mogą określić zawartości), ale anonimowość nie jest gwarantowana — przy łączeniu się przez internet, węzły peer-to-peer, z którymi następuje bezpośrednia interakcja, mogą określić rzeczywisty adres IP, dlatego dla anonimowości zaleca się łączenie węzłów przez Tor lub I2P.
Mimo że projekt znajduje się w fazie alfa, jest już wystarczająco stabilny do codziennego użytku, ale nie gwarantuje zgodności wstecznej między wydaniami. Społeczność Yggdrasil wspiera zestaw usług, w tym platformę do hostowania kontenerów Linux dla hostingu swoich stron, wyszukiwarkę YaCy, serwer komunikacyjny Matrix, serwer IRC, DNS, system VoIP, tracker BitTorrent, mapę punktów podłączenia, bramę do IPFS oraz proxy do komunikacji z sieciami Tor, I2P i clearnet.
W nowej wersji:
- Dodano możliwość uwierzytelniania połączeń z piramidami za pomocą hasła. Hasło określa się za pomocą parametru "password=", na przykład "tls://a.b.c.d:12345?password=123456abcdef".
- Dodano możliwość korzystania z protokołu QUIC, opartego na UDP, do interakcji z piramidami. Aby używać QUIC, należy wskazać schemat URI quic:// w dyrektywach Listen i Peers, ale wsparcie dla QUIC nie zostało jeszcze tak dokładnie przetestowane jak TCP i TLS.
- Dodano opcję PrivateKeyPath, która umożliwia przechowywanie klucza prywatnego w formacie PEM, osobno od głównego pliku konfiguracyjnego. Aby wyeksportować klucz do oddzielnego pliku, można użyć opcji "-exportkey".
- Wprowadzono nową schemę routingu, niekompatybilną z wcześniejszymi wersjami (węzły z Yggdrasil 0.5 nie mogą współpracować z hostami opartymi na Yggdrasil 0.4), która rozwiązuje większość problemów ze stabilnością i skalowalnością z gałęzi 0.4, a także znacznie zmniejsza zużycie pamięci oraz ogranicza ruch w przypadku braku aktywności sieciowej.
W nowej implementacji do śledzenia powiązań i węzłów używana jest probabilistyczna struktura Filtru Blooma. Rozproszona tablica haszująca (DHT) nie jest już stosowana do wymiany informacji o routingu i łączenia otwartych kluczy w hierarchicznej sieci.
Aby utrzymać lokalną spójność i zredukować zależność od tras prowadzących do węzłów głównych, węzły teraz osobno przekazują informacje o każdym łączu, które są śledzone w strukturach CRDT. Zamiast routingu od źródła, stosuje się routing oparty na algorytmie zachłannym (zapytania są kierowane do najbliższego węzła sąsiedniego).
Formaty używane podczas negocjacji połączeń i rozsyłania multicast zostały przekształcone w celu lepszej rozciągliwości. Kod obsługi połączeń został przerobiony w celu zapewnienia bardziej niez niezawodnego śledzenia stanu węzłów. Zapewnione zostało oddzielne śledzenie interwałów między ponownymi połączeniami dla każdego skonfigurowanego węzła.
W celu wykrywania awarii zamiast okresowego wysyłania wydzielonych zapytań keepalive zaangażowano wiadomości potwierdzające otrzymanie ruchu, co pozwala na eliminację ruchu w przypadku braku aktywności sieciowej (co m.in. obniża zużycie energii na urządzeniach mobilnych poprzez wyeliminowanie ruchu w trybie bezczynności).
Źródło: opennet.ru
