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

Что: 2b3558a429ffa4c74f0b670a102501a909c6d7c1

Когда: 2016-12-18 23:35:17+03:00

Темы: 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 хорош!


  запустить

  немного маленьких, как в UUCP, показалось что не так уж и страшно):
  nncp-send, nncp-toss, nncp-freq, nncp-stat, nncp-gennode, nncp-mail

  файла (File REQuest: freq), отослать почтовое сообщение (аналогично
  rmail из UUCP: просто запустить sendmail и скормить ему сообщение)

  сообщения. В конфиге задаётся: достучаться до "alice" нужно через
  "bob" -- создаётся сообщение для alice, оборачивается в транзитный
  пакет до bob и отсылается ему. Кол-во hop-ов не ограничено сейчас

  onion encryption: транзитные ноды знают только про предыдущего и
  следующего получателя, но не знают даже про тип пакета

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

  адресаты писем (и их длины) не утекают

  Curve25519 (один ключ эфемерный, другой статичный)

  forward secrecy

  более приоритетные, остальное откладывая на потом. Нужно чтобы жирные
  файлы не забивали возможность прохождения почты

  ключами известных нод это всё что нужно

  директориях, никаких БД. Логи и статистика -- аналогично

  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 сможет.

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

Сгенерирован: SGBlog 0.34.0