[О блоге] [наверх] [пред] [2016-12-18 23:35:17+03:00] [2b3558a429ffa4c74f0b670a102501a909c6d7c1]
Темы: [go][nncp]

Начал новый проект: NNCP

Уже не первый год думаю о том чтобы написать что-то своё на замену
текущих store-and-forward, UUCP решений. Много лет я живу в большинстве
случаев в store-and-forward режиме. Мне это нравится, это удобно, это
надёжно, это сильно независимо от внешних условий (решений корпораций
всяких). Кое что на эту тему писал вот тут: https://habrahabr.ru/post/282493/

Всё это у меня фактически сводилось к UUCP окружению. Оно работает,
исправно, но, как говорил, не первый год мучает оно тем, что требует
очень аккуратной настройки и наличия различных дополнительных
инструментов.

В Taylor UUCP реализации очень такая богатая настройка. Для выполнения
некоторых действий нужно минимум усилий. Для других -- сильно больше.
Лично у меня проблема в том что некоторые из просто-выполнимых задач --
мне не нужны, а нужные -- не так тривиальны к лёгкой настройке.

Плюс UUCP абсолютно никак не заботиться о шифровании, криптографической
безопасности. То есть, если его использовать поверх Интернета, то нужно
самостоятельно городить SSH/VPN/whatever.

Плюс он не парится о приватности данных: промежуточные ноды очень
неплохо видят что вы запрашиваете/передаёте. Если это расценивать
исключительно как F2F сеть, то не так всё страшно, но например DeadDrop
какой-нибудь уже не получится использовать.

Собственно, наболело оно всё, накопилось и я уже чуть ли не большую
часть всего написал, сделал и в голове целостная картина уже всего
имеется. Пока оно не будет хорошенько протестировано в бою, выкладывать
в свободном доступе не буду. Но то что оно будет очень активно
использоваться: это уж точно, потому-что прям не терпится заменить
SSH/VPN/UUCP/shell-скрипты-обвязки этим простым творением. Я уже очень
доволен тем что успел на этих выходных написать и в который раз
убеждаюсь насколько же язык Go хорош!

* NNCP -- Node-to-Node-CoPY (по аналогии с UUCP -- UNIX-to-UNIX-CoPy)
* Написан на Go, вроде ничто не мешает его даже на Windows каком-нибудь
  запустить
* Это набор исполняемых файлов (думал сделать это вообще в одном, но
  немного маленьких, как в UUCP, показалось что не так уж и страшно):
  nncp-send, nncp-toss, nncp-freq, nncp-stat, nncp-gennode, nncp-mail
* Один единственный конфигурационный YAML файл
* Friend-to-Friend сеть: связь только и только с явно знакомыми нодами
* Одноранговая сеть
* Все действия: store-and-forward. Умеет: отослать файл, запросить отсыл
  файла (File REQuest: freq), отослать почтовое сообщение (аналогично
  rmail из UUCP: просто запустить sendmail и скормить ему сообщение)
* Может посылать через несколько hop-ов: специальные транзитные
  сообщения. В конфиге задаётся: достучаться до "alice" нужно через
  "bob" -- создаётся сообщение для alice, оборачивается в транзитный
  пакет до bob и отсылается ему. Кол-во hop-ов не ограничено сейчас
* Все пакеты шифруются и аутентифицируются от точки до точки. Фактически
  onion encryption: транзитные ноды знают только про предыдущего и
  следующего получателя, но не знают даже про тип пакета
* Придётся всю сеть полностью описывать: все маршруты и знать все
  публичные ключи соседей, адресатов и прочего. Поэтому это только для
  маленьких сетей. Аналогично UUCP, опять же
* В пакетах есть некая защита приватности метаданных: имена файлов и
  адресаты писем (и их длины) не утекают
* Кодирование данных: XDR
* Используемые криптоалгоритмы: Twofish-CTR, BLAKE2b-MAC, HKDF, Ed25519,
  Curve25519 (один ключ эфемерный, другой статичный)
* Не полноценный (только одна половинка ключа эфемерна), но всё же
  forward secrecy
* Приоритезация трафика и пакетов: первым делом будут обрабатываться
  более приоритетные, остальное откладывая на потом. Нужно чтобы жирные
  файлы не забивали возможность прохождения почты
* В принципе это stateless система: конфигурационный файл с публичными
  ключами известных нод это всё что нужно
* Все пакеты для отправки, после приёма -- хранится в файлах, в
  директориях, никаких БД. Логи и статистика -- аналогично
* Информация о целостности данных зашита в самих файлах
* Поведение nncp-mail совместимо с uux/rmail из UUCP: то есть любой
  Postfix, Exim, Sendmail можно точно так же подружить с NNCP. В Postfix
  это разкомментировать две строки, ну и uux заменить на nncp-mail

Это всё что уже реализовано. На данный момент даже это уже закрывает то,
чего нет в UUCP: возможность общения через floppynet, sneakernet,
deaddrop. В UUCP самое простое что можно сделать это полностью
скопировать директорию /var/spool/uucp как-будто эта нода тут всегда
была. Это неудобно, опасно, чревато ошибками. В FidoNet такой проблемы
нет: там можно подложить файлы в inbound и сканнер мейлера увидит новые
задачи и их обработает. В NNCP точно такой же подход: подложил, демон
увидел и взял в обработку. Результаты работы (outbound сообщения) --
каким образом от него уйдут: не его заботы.

Надо написать будет TCP демон. В принципе это мог бы быть rsync: реально
он выполнит задачу по синхронизации директорий, но это лишняя
зависимость, он не может легко взять и проигнорировать неприоритетные
пакеты. Кроме просто "я хочу передать XXX", "передавай" нужна
возможность докачки. Нужно согласование приоритетов. Общение должно быть
двусторонним или односторонним: в одном случае как можно быстрее по
полнодуплексному каналу связи пообщаться, в другом случае например по
спутниковой связи быстрее в одну сторону отрабатывать, без feedback-а.

Демон установления соединения должен уметь общаться в нужное время, при
нужных событиях (polling, соединяться когда появится outbound, только
когда попросят), обрабатывать только заданные приоритет трафика,
ограничивать скорость, суммарный трафик на вход или выход. Всё тоже
самое касается и слушающего демона.

Предположительно связь по online каналу (а не sneakernet) будет
использовать Noise протокол с обязательной двусторонней аутентификацией.
Анонимных пользователей (как в FTP, HTTP, UUCP) нет.

Задача не сложная, все библиотеки для Go уже есть, сам язык легко
позволяет подобное писать, но за пару дней до всего этого не успел ещё
дойти. Видимо, пара-тройка выходных и будет готово. И сам NNCP на этом
готов. Больше идей что туда впилить у меня нет, так как мои задачи оно с
лихвой покрывает. Если нужен удалённое исполнение команд: лучше UUCP я
думаю поставить. Если нужна сложная маршрутизация, а не полностью F2F
где-все-другу-друга-знают сеть, да ещё эхоконференции/NNTP -- лучше FTN
(FidoNet) использовать. Но сделать store-and-forward прослойку для почты
и файлообмена, как с online, так и sneakernet доступом NNCP сможет.

    [оставить комментарий]