Доступен выпуск проекта Nebula 1.5, предлагающего инструментарий для построения защищённых оверлейных сетей, которые могут объединять от нескольких до десятков тысяч территориально разделённых хостов, формируя отдельную изолированную сеть поверх глобальной сети. Проект предназначен для создания своих собственных оверлейных сетей для любых нужд, например, для объединения корпоративных компьютеров в разных офисах, серверов в разных ЦОД или виртуальных окружений у разных облачных провайдеров. Код написан на языке Go и распространяется под лицензией MIT. Проект основан компанией Slack, развивающей одноимённый корпоративный мессенджер. Поддерживается работа в Linux, FreeBSD, macOS, Windows, iOS и Android.
Узлы в сети Nebula взаимодействуют друг с другом напрямую в режиме P2P - по мере появления необходимости передачи данных между узлами динамически создаются прямые VPN-соединения. Идентичность каждого хоста в сети подтверждается цифровым сертификатом, а подключение к сети требует прохождения аутентификации - каждый пользователь получает сертификат, подтверждающий IP-адрес в сети Nebula, имя и членство в группах хостов. Сертификаты подписываются внутренним удостоверяющим центром, развёртываемым создателем каждой отдельной сети на своих мощностях и применяемом для заверения полномочий хостов, имеющих право подключения к привязанной к удостоверяющему центру конкретной оверлейной сети.
Для создания аутентифицированного защищённого канала связи в Nebula применяется собственный туннельный протокол, основанный на протоколе обмена ключами Диффи—Хеллмана и шифре AES-256-GCM. Реализация протокола базируется на готовых и проверенных примитивах, предоставляемых фреймворком Noise, который также применяется в таких проектах, как WireGuard, Lightning и I2P. Утверждается, что проект прошёл независимый аудит безопасности.
Для обнаружения других узлов и координации подключении к сети создаются специальные узлы "lighthouse", глобальные IP-адреса которых фиксированы и известны участникам сети. У узлов-участников нет привязки к внешнему IP-адресу, они идентифицируются по сертификатам. Владельцы хостов самостоятельно не могут внести изменения в подписанные сертификаты и в отличие от традиционных IP-сетей не могут притвориться другим хостом простой сменой IP-адреса. При создании туннеля идентичность хоста подтверждается индивидуальным закрытым ключом.
Создаваемой сети выделяется определённый диапазон интранет адресов (например, 192.168.10.0/24) и осуществляется связывание внутренних адресов с сертификатами хостов. Из участников оверлейной сети могут формироваться группы, например, для разделения серверов и рабочих станций, к которым применяются отдельные правила фильтрации трафика. Предоставляются различные механизмы для обхода трансляторов адресов (NAT) и межсетевых экранов. Возможна организации маршрутизации через оверлейную сеть трафика сторонних хостов, не входящих в сеть Nebula (unsafe route).
Поддерживается создание межсетевых экранов для разделения доступа и фильтрации трафика между узлами в оверлейной сети Nebula. Для фильтрации применяются ACL с привязкой тегов. Каждый хост в сети может определять собственные правила фильтрации по хостам, группам, протоколам и сетевым портам. При этом хосты фильтруются не по IP-адресам, а по заверенным цифровой подписью идентификаторам хоста, которые невозможно подделать без компрометации координирующего состав сети удостоверяющего центра.
В новом выпуске:
www.opennet.ru
Узлы в сети Nebula взаимодействуют друг с другом напрямую в режиме P2P - по мере появления необходимости передачи данных между узлами динамически создаются прямые VPN-соединения. Идентичность каждого хоста в сети подтверждается цифровым сертификатом, а подключение к сети требует прохождения аутентификации - каждый пользователь получает сертификат, подтверждающий IP-адрес в сети Nebula, имя и членство в группах хостов. Сертификаты подписываются внутренним удостоверяющим центром, развёртываемым создателем каждой отдельной сети на своих мощностях и применяемом для заверения полномочий хостов, имеющих право подключения к привязанной к удостоверяющему центру конкретной оверлейной сети.
Для создания аутентифицированного защищённого канала связи в Nebula применяется собственный туннельный протокол, основанный на протоколе обмена ключами Диффи—Хеллмана и шифре AES-256-GCM. Реализация протокола базируется на готовых и проверенных примитивах, предоставляемых фреймворком Noise, который также применяется в таких проектах, как WireGuard, Lightning и I2P. Утверждается, что проект прошёл независимый аудит безопасности.
Для обнаружения других узлов и координации подключении к сети создаются специальные узлы "lighthouse", глобальные IP-адреса которых фиксированы и известны участникам сети. У узлов-участников нет привязки к внешнему IP-адресу, они идентифицируются по сертификатам. Владельцы хостов самостоятельно не могут внести изменения в подписанные сертификаты и в отличие от традиционных IP-сетей не могут притвориться другим хостом простой сменой IP-адреса. При создании туннеля идентичность хоста подтверждается индивидуальным закрытым ключом.
Создаваемой сети выделяется определённый диапазон интранет адресов (например, 192.168.10.0/24) и осуществляется связывание внутренних адресов с сертификатами хостов. Из участников оверлейной сети могут формироваться группы, например, для разделения серверов и рабочих станций, к которым применяются отдельные правила фильтрации трафика. Предоставляются различные механизмы для обхода трансляторов адресов (NAT) и межсетевых экранов. Возможна организации маршрутизации через оверлейную сеть трафика сторонних хостов, не входящих в сеть Nebula (unsafe route).
Поддерживается создание межсетевых экранов для разделения доступа и фильтрации трафика между узлами в оверлейной сети Nebula. Для фильтрации применяются ACL с привязкой тегов. Каждый хост в сети может определять собственные правила фильтрации по хостам, группам, протоколам и сетевым портам. При этом хосты фильтруются не по IP-адресам, а по заверенным цифровой подписью идентификаторам хоста, которые невозможно подделать без компрометации координирующего состав сети удостоверяющего центра.
В новом выпуске:
- В команду print-cert добавлен флаг "-raw" для вывода PEM-представления сертификата.
- Добавлена поддержка новой архитектуры Linux riscv64.
- Добавлена экспериментальная настройка remote_allow_ranges для привязки списков разрешённых хостов к определённым подсетям.
- Добавлена опция pki.disconnect_invalid для сброса туннелей после прекращения доверия или истечения времени жизни сертификата.
- Добавлена опция unsafe_routes.<route>.metric для задания веса определённому внешнему маршруту.