Стек, который заводится там, где TCP/IP сдаётся: разбираем Reticulum

Представьте канал, у которого пропускная способность измеряется битами в секунду, а не мегабитами. КВ-радио на 300 бод. LoRa-модуль, отдающий полтора килобита в хорошую погоду. Спутник с секундными задержками. Витая пара между корпусами, которую периодически перерубает экскаватор. На такой среде классический стек ведёт себя плохо: рукопожатия требуют нескольких раундов, таймауты срабатывают раньше, чем приходит ответ, служебные протоколы вроде DHCP и DNS добавляют своих ожиданий.

Из этого наблюдения и вырос Reticulum. Его проектировали от обратного: считаем, что канал скверный, и это не авария, а рабочее состояние. Нижняя граница по спецификации — 5 бит/с при MTU 500 байт; верхний ориентир, который называют разработчики, — гигабит. Проект не заброшен: сборка RNS 1.3.8 датирована 10 июля 2026 года, а формат кадра и программный интерфейс объявлены устоявшимися.

Три ожидания, которые не сбудутся

Ярлык «децентрализованный интернет» цепляют к проекту постоянно, и именно он порождает разочарования. Расставим границы заранее.

• Единой сети нет. Подключиться «к Reticulum» некуда: вы либо цепляетесь к конкретному чужому узлу, либо разворачиваете собственный сегмент. Авторы описывают свою работу как инструмент для создания тысяч сетей — не одной большой.
• Анонимности уровня Tor тут нет. Да, шифрование принудительное и выключить его нельзя, а адрес источника в кадр не кладётся. Но узлам-транспортам доступны адреса получателей, размеры кадров и моменты их появления, а передатчик в эфире пеленгуется вне зависимости от стойкости криптографии.
• IP никуда не денется. Стек целиком живёт в пространстве пользователя и способен работать поверх обычного TCP. Модулей ядра нет, сетевых интерфейсов в системе не создаётся.

Поднимаем узел: pip, конфиг, два интерфейса

Дистрибутив ставится обычным питоновским способом:

pip install rns
# на Debian/Ubuntu/Raspberry Pi и свежих macOS:
pip install rns --break-system-packages
# либо изолированно:
pipx install rns

Затем поднимается демон, он же генерирует шаблон настроек:

rnsd --exampleconfig > ~/.reticulum/config   # шаблон с комментариями
rnsd -vvv                                    # запуск с подробным логом
rnstatus                                     # состояние интерфейсов

Настройки хранятся по пути ~/.reticulum/config, синтаксис — INI со вложенными секциями. Вот как выглядит узел на VPS, который и принимает подключения, и пересылает чужой трафик:

[reticulum]
  enable_transport = Yes
  share_instance = Yes

[interfaces]
  [[Local WiFi]]
    type = AutoInterface
    enabled = yes

  [[Public TCP]]
    type = TCPServerInterface
    enabled = yes
    listen_ip = 0.0.0.0
    listen_port = 4242

Встречный блок на ноутбуке выглядит зеркально:

  [[Uplink]]
    type = TCPClientInterface
    enabled = yes
    target_host = 203.0.113.10
    target_port = 4242

Закрытый сегмент делается через IFAC — аутентификацию на уровне интерфейса. Шифрование данных она не подменяет, её задача — не пускать посторонние узлы:

    network_name = internal_1
    passphrase = <ваша-длинная-фраза>
    ifac_size = 16

Как это устроено внутри

Interface — любая среда, способная передать байты

Физика прячется за нижним слоем. Поддерживаются Ethernet и WiFi (соседи обнаруживаются мультикастом через AutoInterface), TCP и UDP, последовательные порты, KISS-модемы и TNC пакетного радио, LoRa на устройствах RNode, а также произвольная внешняя программа, с которой общаются через stdio.

Единственное условие к среде — полудуплекс со скоростью выше 5 бит/с и MTU от 500 байт. Дальше вопрос только конфигурации.

Destination — самовыдаваемый идентификатор

Адресом служат 16 байт усечённого SHA-256, посчитанного от публичного ключа и имени назначения; на письме это выглядит как <13425ec15b621c1d928589718000d814>. Если 128 бит мало, длину поднимают до 256.

Принципиальный момент — идентификатор рождается локально, на самом узле, без запросов наружу. Ни регистратора, ни DHCP, ни нарезки подсетей. Переезд узла в другую часть сети адрес не меняет: он остаётся достижимым. Видимым для остальных новый адрес становится за секунды или минуты — по мере расхождения анонса.

Назначения бывают четырёх сортов:

• single — шифрованный юникаст на уникальный публичный ключ, проходит через несколько хопов;
• plain — открытый, только в пределах локального сегмента, многохоповая маршрутизация недоступна;
• group — симметричное AES-256 на заранее розданном ключе;
• link — абстракция канала, разбирается ниже.

Набор алгоритмов задан жёстко, выбирать нечего: X25519 в обмене ключами, Ed25519 в подписях, AES-256-CBC с PKCS7 в симметрике, HKDF при деривации, HMAC-SHA256 для аутентификации, токены по спецификации Fernet. Открытый линк не установится ни при каких настройках, а нешифрованные кадры считаются невалидными и выбрасываются.

Кадр — 19 байт накладных расходов

Разметка кадра простая и компактная: заголовок в два байта, адресная часть на 16 или 32 байта, байт контекста, следом полезная нагрузка объёмом до 465 байт. В первом байте заголовка упакованы флаги — IFAC, тип заголовка, флаг контекста, режим распространения, тип назначения, тип пакета; второй байт отведён под счётчик хопов.

Такая экономия и даёт цифры, которыми проект любит иллюстрировать себя: 51 байт на запрос установки линка, 167 байт на анонс, 115 байт на подтверждение линка.

Link — канал ценой в 297 байт

Под именем Link скрывается одноразовый шифрованный канал, натянутый на найденный путь. Схема установки такая: инициатор отправляет запрос, принимающая сторона делает свежую пару X25519, обе стороны через ECDH выводят общий секрет, а принимающая подписывает доказательство ключом Ed25519.

Суммарная стоимость процедуры — 297 байт в трёх пакетах. Поддержание уже открытого канала обходится в 0,45 бит/с. Для контраста: TLS поверх TCP на подобном канале договаривался бы минутами.

Из конструкции вытекает приятное следствие: пока идёт установка, инициатор не сообщает о себе ничего — принимающей стороне достаётся лишь одноразовый ключ. Одноразовость же обеспечивает и forward secrecy.

Transport — путь строится из услышанного

Маршрутизации в классическом понимании здесь не завезли: ни обмена таблицами, ни метрик, ни зон. Работает другое — анонсы. Узел заявляет о себе, соседи повторяют заявление дальше, и каждый, кто его принял, заводит запись вида «этот адрес доступен через такого-то соседа, столько-то хопов».

Значения по умолчанию: потолок в 128 хопов, под анонсы резервируется 2 % полосы интерфейса, ретрансмит однократный со случайной задержкой, повторы отбрасываются.

Пересылка чужого трафика по умолчанию отключена. Превращение узла в транспортный делается явно:

[reticulum]
  enable_transport = Yes

На транспортном узле оседают таблицы линков и накопленное знание об анонсах. Именно он и располагает картиной того, кто с кем контактирует — пусть содержимое ему и недоступно.

Что уже написано поверх

Стек сам по себе бесполезен; ценность — в комплекте прикладных программ:

• rnstatus — состояние интерфейсов и трафик;
• rnpath — просмотр и сброс известных путей;
• rnprobe — диагностика связности до конкретного адреса;
• rncp — копирование файлов между узлами;
• rnid — управление идентичностями, шифрование и расшифровка файлов;
• rnsh — интерактивный удалённый шелл;
• rnx — запуск одной команды на удалённом узле с возвратом вывода;
• rngit и git-remote-rns — git-ремоут поверх Reticulum, с подписью и валидацией коммитов.

Выше утилит расположен прикладной слой. LXMF — протокол переписки, спокойно переносящий задержки и обрывы: сообщение долежит до восстановления связи. На нём построены Sideband (графический клиент под Android, Linux, macOS и Windows — файлы, голосовые, карты, телеметрия) и Nomad Network — текстовая среда со страницами и обменом файлами.

Слабые места

Без этого раздела получился бы рекламный текст, поэтому перечислю честно.

Скорость реализации. Эталонный код написан на Python. Пять бит в секунду он обслужит без вопросов, гигабит — уже вопрос. Для систем, где недоступна PyCA/cryptography, существует пакет rnspure, и работает он ощутимо медленнее.

Метаданные остаются. Закрыть содержимое не значит спрятать сам факт разговора. Транспортным узлам видны адреса получателей, объёмы и тайминги. В радиоэфире к этому добавляется физика: излучение пеленгуется, и криптография тут бессильна.

Эфир регулируется. Правовой статус LoRa на 433/868/915 МГц и пакетного радио в VHF различается от страны к стране: где-то нужна лицензия, где-то ограничены мощность и доля времени в эфире, где-то шифрование в любительских диапазонах прямо под запретом. Выяснять это стоит до покупки железа, а не после.

Сообщество узкое. Десяти ответов на профильном форуме по вашей проблеме не найдётся. Документация у проекта развёрнутая, но круг пользователей маленький.

Источники

• Reticulum Network — официальный сайт
• Understanding Reticulum — раздел руководства с описанием слоёв, криптографии и формата кадра
• Getting Started Fast — установка, конфиг, утилиты
• Configuring Interfaces — параметры интерфейсов
• markqvist/Reticulum — репозиторий и релизы