Dostępna jest wersja projektu Nebula 1.5 oferującego narzędzia do budowy bezpiecznych sieci nakładkowych. Sieć może łączyć od kilku do kilkudziesięciu tysięcy geograficznie oddzielonych hostów hostowanych przez różnych dostawców, tworząc oddzielną, izolowaną sieć na szczycie sieci globalnej. Projekt napisany jest w Go i rozpowszechniany na licencji MIT. Projekt został założony przez firmę Slack, która rozwija korporacyjnego komunikatora o tej samej nazwie. Obsługuje Linux, FreeBSD, macOS, Windows, iOS i Android.
Węzły w sieci Nebula komunikują się ze sobą bezpośrednio w trybie P2P — bezpośrednie połączenia VPN są tworzone dynamicznie w miarę konieczności przesyłania danych pomiędzy węzłami. Tożsamość każdego hosta w sieci potwierdzana jest certyfikatem cyfrowym, a podłączenie do sieci wymaga uwierzytelnienia – każdy użytkownik otrzymuje certyfikat potwierdzający adres IP w sieci Nebula, nazwę i przynależność do grup hostów. Certyfikaty są podpisane przez wewnętrzny urząd certyfikacji, wdrażane przez twórcę sieci w jego obiektach i służą do poświadczania uprawnień hostów, które mają prawo łączyć się z siecią nakładkową.
Aby stworzyć uwierzytelniony, bezpieczny kanał komunikacyjny, Nebula wykorzystuje własny protokół tunelowy oparty na protokole wymiany kluczy Diffiego-Hellmana i szyfrze AES-256-GCM. Implementacja protokołu opiera się na gotowych i sprawdzonych prymitywach dostarczonych przez framework Noise, który jest również wykorzystywany w projektach takich jak WireGuard, Lightning i I2P. Mówi się, że projekt przeszedł niezależny audyt bezpieczeństwa.
Aby wykryć inne węzły i koordynować połączenia z siecią, tworzone są specjalne węzły „latarni morskiej”, których globalne adresy IP są stałe i znane uczestnikom sieci. Węzły uczestniczące nie są powiązane z zewnętrznym adresem IP; są identyfikowane za pomocą certyfikatów. Właściciele hostów nie mogą samodzielnie 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 weryfikowana za pomocą indywidualnego klucza prywatnego.
Utworzonej sieci przydzielany jest określony zakres adresów intranetowych (na przykład 192.168.10.0/24), a adresy wewnętrzne są powiązane z certyfikatami hosta. Grupy można tworzyć z uczestników sieci nakładkowej, np. do odrębnych serwerów i stacji roboczych, do których stosowane są odrębne reguły filtrowania ruchu. Dostępne są różne mechanizmy umożliwiające ominięcie tłumaczy adresów (NAT) i zapór sieciowych. Możliwe jest zorganizowanie routingu przez sieć nakładkową ruchu z hostów innych firm, które nie są częścią sieci Nebula (trasa niebezpieczna).
Obsługuje tworzenie zapór sieciowych w celu separacji dostępu i filtrowania ruchu pomiędzy węzłami w sieci nakładkowej Nebula. Do filtrowania używane są listy ACL z powiązaniem znaczników. Każdy host w sieci może zdefiniować własne reguły filtrowania w oparciu o hosty, grupy, protokoły i porty sieciowe. W tym przypadku hosty są filtrowane nie według adresów IP, ale według podpisanych cyfrowo identyfikatorów hostów, których nie można sfałszować bez narażenia na szwank centrum certyfikacji koordynującego sieć.
W nowym wydaniu:
- Do polecenia print-cert dodano flagę „-raw”, aby wydrukować reprezentację certyfikatu PEM.
- Dodano obsługę nowej architektury Linux riscv64.
- Dodano eksperymentalne ustawienie Remote_allow_ranges umożliwiające powiązanie list dozwolonych hostów z określonymi podsieciami.
- Dodano opcję pki.disconnect_invalid umożliwiającą resetowanie tuneli po zakończeniu zaufania lub wygaśnięciu ważności certyfikatu.
- Dodano opcję unsafe_routes. .metric, aby przypisać wagę do określonej trasy zewnętrznej.
Źródło: opennet.ru