Wydano wydanie projektu Nebula 1.5, oferującego narzędzia do budowy zabezpieczonych sieci overlay. Sieć może łączyć od kilku do dziesiątek tysięcy geograficznie rozproszonych hostów, umieszczonych u różnych dostawców, tworząc oddzielną, izolowaną sieć na tle globalnej sieci. Projekt został napisany w języku Go i jest udostępniany na licencji MIT. Powstał w firmie Slack, rozwijającej ten sam nazwany komunikator dla firm. 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 certyfikatem cyfrowym, a dostęp do sieci wymaga przejścia autoryzacji — każdy użytkownik otrzymuje certyfikat potwierdzający adres IP w sieci Nebula, nazwisko i przynależność do grup hostów. Certyfikaty są podpisywane wewnętrzną jednostką certyfikacyjną, wdrażaną przez twórcę sieci na jego własnych zasobach i wykorzystywaną do zatwierdzania uprawnień hostów mających prawo do podłączenia się do sieci overlay.
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 przydzielany jest określony zakres adresów intranetowych (na przykład 192.168.10.0/24) i realizowane jest powiązanie adresów wewnętrznych z certyfikatami hostów. Z uczestników sieci overlay mogą być tworzone grupy, na przykład do rozdzielenia serwerów i stacji roboczych, do których stosowane są oddzielne zasady filtrowania ruchu. Zapewniane są różne mechanizmy do omijania translatorów adresów (NAT) i zapór sieciowych. Możliwa jest organizacja routingu przez sieć overlay dla ruchu zewnętrznych hostów, które nie wchodzą do sieci Nebula (unsafe route).
Obsługiwane jest tworzenie zapór sieciowych do rozdzielenia dostępu i filtrowania ruchu pomiędzy węzłami w sieci overlay Nebula. Do filtrowania stosowane są ACL z powiązanymi tagami. Każdy host w sieci może definiować własne zasady filtrowania według hostów, grup, protokołów i portów sieciowych. W tym przypadku hosty są filtrowane nie według adresów IP, ale według zatwierdzonych podpisem cyfrowym identyfikatorów hosta, których nie można sfałszować bez kompromitacji zespołu koordynującego sieciowy certyfikatu.
W nowym wydaniu:
- Do polecenia print-cert dodano flagę „-raw” do wyświetlania reprezentacji PEM certyfikatu.
- Dodano obsługę nowej architektury Linux riscv64.
- Dodano eksperymentalne ustawienie remote_allow_ranges do przypisywania list autoryzowanych hostów do określonych podsieci.
- Dodano opcję pki.disconnect_invalid do resetowania tuneli po utracie zaufania lub wygaśnięciu certyfikatu.
- Dodano opcję unsafe_routes..metric do przypisania wagi określonemu zewnętrznemu routowi.
Źródło: opennet.ru
