Начал новый проект: 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 хорош!
- 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 сможет.
оставить комментарий
Сгенерирован: SGBlog 0.34.0