Opublikowano wydanie projektu Nebula 1.9, oferującego narzędzia do budowy zabezpieczonych sieci overlay, umożliwiających połączenie geograficznie rozdzielonych hostów w oddzielną, izolowaną sieć działającą na globalnej sieci. Projekt ma na celu tworzenie własnych sieci overlay do różnych zastosowań, takich jak łączenie komputerów firmowych w różnych biurach, serwerów w różnych centrach danych czy środowisk wirtualnych u różnych dostawców chmury. Kod napisany jest w języku Go i jest udostępniany na licencji MIT. Projekt został założony przez firmę Slack, która rozwija identyczną korporacyjną aplikację do komunikacji. Obsługiwane są systemy Linux, FreeBSD, macOS, Windows, iOS i Android.
Węzły w sieci Nebula komunikują się ze sobą bezpośrednio w trybie P2P – w miarę pojawienia się potrzeby przesyłania danych między węzłami, dynamicznie tworzone są bezpośrednie VPN-połączenia. Tożsamość każdego hosta w sieci jest potwierdzana cyfrowym certyfikatem, a połączenie z siecią wymaga przejścia autoryzacji – każdy użytkownik otrzymuje certyfikat, który potwierdza adres IP w sieci Nebula, nazwisko oraz członkostwo w grupach hostów. Certyfikaty są podpisywane przez wewnętrzny urząd certyfikacji, wdrażany przez twórcę każdej oddzielnej sieci na własnych zasobach, który jest stosowany do potwierdzania uprawnień hostów, mających prawo do łączenia się z konkretną siecią overlay przypisaną do tego urzędnika certyfikacyjnego.
Aby utworzyć autoryzowany, zabezpieczony kanał komunikacji w Nebula, używany jest własny protokół tunelowy, oparty na protokole wymiany kluczy Diffie-Hellmana i szyfrze AES-256-GCM. Realizacja protokołu bazuje na gotowych i sprawdzonych prymitywach dostarczanych przez framework Noise, który jest również używany w takich projektach jak WireGuard, Lightning i I2P. Twierdzi się, że projekt przeszedł niezależny audyt bezpieczeństwa.
Aby wykrywać inne węzły i koordynować połączenia z siecią, tworzone są specjalne węzły „lighthouse”, których globalne adresy IP są stałe i znane uczestnikom sieci. Węzły-uczestnicy nie mają przypisania do zewnętrznego adresem IP, są identyfikowane przez certyfikaty. Właściciele hostów nie mogą sami wprowadzać zmian w podpisanych certyfikatach i w przeciwieństwie do tradycyjnych sieci IP, nie mogą udawać innego hosta po prostu zmieniając adres IP. Podczas tworzenia tunelu tożsamość hosta jest potwierdzana indywidualnym kluczem prywatnym.
Tworzonej sieci przypisywany jest określony zakres adresów intranetowych (na przykład 192.168.10.0/24) i zachodzi powiązanie wewnętrznych adresów z certyfikatami hostów. Zapewnia się różne mechanizmy do omijania translatorów adresów (NAT) oraz zapór sieciowych. Istnieje możliwość organizacji routingu przez nakładkową sieć ruchu zewnętrznych hostów, które nie są częścią sieci Nebula (niebezpieczna trasa). Z uczestników nakładkowej sieci mogą formować się grupy, na przykład do podziału serwerów i stacji roboczych, do których stosowane są oddzielne zasady filtracji ruchu.
Wsparcie dla tworzenia zapór sieciowych w celu podziału dostępu i filtracji ruchu między węzłami w nakładkowej sieci Nebula. Do filtracji stosowane są ACL z przypisanymi tagami. Każdy host w sieci może określać własne zasady filtracji według hostów, grup, protokołów i portów sieciowych. Przy czym hosty są filtrowane nie według adresów IP, ale według poświadczonych cyfrową podpisem identyfikatorów hosta, których nie można podrobić bez kompromitacji centrum certyfikacji koordynującego działanie sieci.
W nowym wydaniu:
- Dodano nowe ustawienie default_local_cidr_any, które zmienia zachowanie podczas przetwarzania podsieci „local_ip” w zasadach zapory sieciowej, aby zapobiec bezpodstawnemu zezwoleniu na ruch do hostów wymienionych w bloku unsafe_routes. W wersji 1.9 ustawienie to jest ustawione na wartość „true”, ale w następnej wersji 1.10 zostanie zmienione na wartość „false”, co spowoduje uwzględnienie lokalnych podsieci przy stosowaniu zasad zapory sieciowej do hostów dostępnych przez niebezpieczne trasy (aby otworzyć dostęp do takich hostów, wymagane będzie obowiązkowe wskazanie local_cidr).
- Udostępniono oficjalny obraz dla systemu Docker, umożliwiający szybkie wdrożenie nakładkowej sieci opartej na Nebula lub węzła dla niej.
- Dodano eksperymentalne kompilacje dla architektury Loong64.
- Wdrożono skrypt serwisowy dla systemu inicjalizacji OpenRC.
- Do procesu w tle SSH dodano wsparcie dla uwierzytelniania za pomocą certyfikatów zatwierdzonych przez urząd certyfikacji (sshd.trusted_cas). Wprowadzono możliwość osadzania kluczy hosta w bloku ustawień sshd.host_key.
- Zapewniono wsparcie dla ponownego ładowania ustawień „tun.unsafe_routes”.
- Usunięto wsparcie dla przestarzałej konfiguracji local_range, którą należy zastąpić preferred_ranges.
- Do kompilacji wymagane jest teraz narzędzie go 1.22. Minimalne wymagania dotyczące wersji systemu Windows zostały podniesione do Windows 10 i Windows Server 2016.
Źródło: opennet.ru
