From 2b3558a429ffa4c74f0b670a102501a909c6d7c1 Mon Sep 17 00:00:00 2001 From: Sergey Matveev Date: Sun, 18 Dec 2016 23:35:17 +0300 Subject: [PATCH] =?utf8?q?=D0=9D=D0=B0=D1=87=D0=B0=D0=BB=20=D0=BD=D0=BE?= =?utf8?q?=D0=B2=D1=8B=D0=B9=20=D0=BF=D1=80=D0=BE=D0=B5=D0=BA=D1=82:=20NNC?= =?utf8?q?P?= MIME-Version: 1.0 Content-Type: text/plain; charset=utf8 Content-Transfer-Encoding: 8bit Уже не первый год думаю о том чтобы написать что-то своё на замену текущих 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 сможет. -- 2.48.1