Всё, что относится к разработке сети «Medium».
  • Дата создания
    3 октября 2019
  • Топиков
    4
  • Ограничение на постинг
    0.000

Альтернативные Mesh-сети

Прежде чем бросаться на амбразуры разработки medium было бы неплохо поискать существующие в мире аналоги, изучить их, взвесить плюсы и минусы, может где то подсмотреть какие то решения, в общем это будет довольно объемной и кропотливой работой, которую одному не вытянуть. Поэтому создаю данный топик для объединения разрозненной информации по существующим аналогам, и ее обсуждению.

Начну с информации от Eduard
в Италии есть сеть Guifi.net ...
Вроде бы основной смысл понятен
… их подгоняет отсутствие интернета как такового в труднодоступных местах...
Описание

Далее:
Сегодня наткнулся на интересный проект www.arednmesh.org
Описание
Их коллеги
Очень интересная концепция с точки зрения юридической организации. Компания единомышленников с заявленной благой целью поддержки цифровой связи во время чрезвычайных ситуаций или стихийных бедствий. При этом у них в наличии действующая нeпoдкoнтpoльная гос. органами сеть, которую они используют в спокойное время по своему усмотрению.

Далее:
Немного аппаратных решений:
Wireless optical system Instructions
Беспроводная оптическая система для передачи данных с очень подробным описанием по изготовлению и наладке. Идеально подойдет для мест со сложной эфирной обстановкой.
Создания WiFi-ретрансляторов с поддержкой построения Mesh-сети
Простые и дешевые повторители WiFi. Хорошо подойдут для увеличения зоны действия WiFi в зданиях.
Делаем Wi-Fi усилитель на 2,4 Ггц
2-х ватный двунаправленный усилитель WiFi диапазона 2.4 ГГц.

А вот это вообще кажется мне очень перспективным:
High-speed multimedia radio (HSMM)
Это реализация беспроводных сетей передачи данных на радиолюбительских частотах (2400 — 2450 МГц) с использованием коммерческого готового оборудования (COTS), такого как точки доступа 802.11. На этих диапазонах лицензированные радиолюбители могут использовать усилители и специализированные антенны для увеличения мощности и зоны покрытия сигнала 802.11, а это вариант законно использовать мощности от 5 до 10 ВТ!
гуглить hsmm mesh

NPR (New Packet Radio)
Это OpenSouce проект радиомодема с протоколом оптимизированным для топологии «точка-многоточка» с помощью управляемой TDMA на безлицензионном диапазоне 433 МГц итоговой стоимостью чуть более 80 долларов, со скоростью до 500kbps.

tinc-boot — full-mesh сеть без боли
Автоматическая, защищенная, распределенная, с транзистивными связями (т.е. пересылкой сообщений, когда нет прямого доступа между абонентами), без единой точки отказа, равноправная, проверенная временем, с низким потреблением ресурсов, full-mesh VPN сеть c возможностью «пробивки» NAT

Идея альтернативы DNS

Вот появилась такая идея:
А что если мы обратимся в другую крайность и не будем делать централизованную DNS в medium принципиально? Централизованная DNS рождает больше проблем и векторов злоупотребления чем пользы. Вот я и подумал, а что если DNS не будет в принципе? Будут адреса Yggdrasil и аналог файла hosts в котором каждый сможет обозвать любой ресурс как он сам пожелает. Никакой централизации. Просто сделать удобное приложение для работы с hosts и можно закрывать тему. Для ленивых добавить в приложение возможность делиться hosts с другими пользователями.
Что это дает?
1. Никакой централизации.
2. Отсутствие векторов злоупотребления.
3. Снимает ответственность c провайдеров за названия и имена.
4. Демократия в натуральном виде, ресурсы получат те названия от пользователей которые заслужили.

Минусы:
1. DNS spoofing
2. инертность
3. скорость обновления очень низкая

Что думаете?

[MTF] К обсуждению: упрощённая система DNS, на основе GIT, PoW и др.

Уважаемые коллеги!

ВЫНОШУ НА ОБСУЖДЕНИЕ ПРОБЛЕМУ

Сети Medium И сети Yggdrasil требуется достойная система DNS, которая будет отвечать следующим критериям:

  1. Устойчивость — отсутствие одного или нескольких серверов не должно сказываться на работе других.
  2. Управляемость — мы должны иметь возможность исправить возникшие проблемы в архитектуре системы очень оперативно.
  3. Относительная приватность — возможность хостить у себя все DNS-записи, относящиеся к своему домену. Хранить скрытые домены третьего уровня и т.п.
  4. Контроль — должна быть возможность влиять на распространение общепринятого противозаконного контента хотя бы с помощью разделегирования доменов.
  5. Защищённость от манипуляций и сквоттинга — должна быть возможность доказать своё право владения доменом, и невозможность захвата большого количества доменов одним лицом.

ПРЕДЛАГАЮ

Я вижу эту систему такой:

  1. Устойчивость достигается наличием нескольких корневых серверов, одновременно обслуживающих сами зоны. Возможно разделение. Наличием нескольких NS-серверов, обслуживающих домены и их записи. Наличие нескольких кэширующих рекурсивных резолверов с постоянным аптаймом.
  2. Управляемость достигается простотой всей системы. Домены хранятся в общедоступном GIT-репозитории, управляются набором скриптов. Репозиторий многократно зеркалируется.
  3. Приватность достигается возможностью указать только свои NS-сервера и хостить их самому. Смягчается требование количества необходимых NS-серверов, можно будет указать только один.
  4. Контроль и возможность разделегирования осуществляется с помощью рейтингов, присваиваемых доменам в момент регистрации (porn, politics, adult language...), и возможностью ручного вмешательства в GIT-репозиторий после обсуждения кворумом администраторов.
  5. Защищённость от манипуляций и сквоттинга достигается с помощью двух пунктов: открытостью репозитория с дозором сообщества (с автоматической рассылкой писем о любом изменении администраторам) и доказательством владения доменом на основе «доказательства работы» (PoW).

На последнем я остановлюсь подробнее.

  • При регистрации домена пользователь заходит на сайт регистратора и вводит нужный домен в форму с единственным полем.
  • Если домен доступен для регистрации, сервер выдаёт пользователю NONCE в виде Base64. В нём зашифрованы: дата-время создания NONCE, MurMur-хэш домена, 8 случайных байт. NONCE сохраняет у себя в базе, как маркер занятости на 3 дня. (период обсуждаем)
  • Пользователь скачивает утилитку для расчёта PoW (её можно написать на Rust, а потом с помощью WebAssembly подключить прямо на страницу регистрации), запускает её примерно следующим образом: pow -d example.medium -n ODcyYzcyMGFiM2ZhMGNhY2U0NTkyYjcyMzQzMTQ4M2E=
  • Утилита находит случайный набор байт, который, при подстановке в формулу hash([email protected]/random) даст в результирующем хэше необходимое количество нулей в начале.
  • Нужное количество нулей зависит и от выбранного алгоритма функции hash() и от длины желаемого домена. Например, для домена длиной 7 символов (без учёта зоны) требуется 3 нуля, а при уменьшении длины домена количество требуемых нулей растёт. То есть, увеличивается сложность.
  • Так же, для увеличения сложности функция hash() применяется несколько раз, по аналогии с количеством нулей выше.
  • После того, как утилита нашла подходящий набор байт, он выводится в консоль в виде Base64 — это и есть пароль к администрированию. Пользователь ещё раз заходит на сайт и вводит на этот раз домен, NONCE и RESULT. Сервер регистратора проверяет, что хэш подходит к NONCE и домену, и регистрирует его, сохраняя у себя в добавок к NONCE хэш от RESULT, чтобы потом подтверждать авторизацию пользователя, когда тот будет администрировать записи. (можно сохранять и какой-нибудь hash(result+password))

АКТУАЛЬНОСТЬ

Проблема создания устойчивого DNS уже давно назрела, и в распределённых сетях она до сих пор решена лишь с оговорками, и текущие системы не обеспечивают все предъявленные выше требования.

ВОПРОСЫ К ОБСУЖДЕНИЮ

  1. Правильно ли сформулированы требования к системе DNS? Может что-то упущено?
  2. Как вы относитесь к предложенной системе PoW без блокчейна для борьбы со сквоттингом и для аутентификации владельца домена?
, ,

DNS на базе GIT

Я придумал простую централизованную систему DNS, с распределённым контролем.

1. Поднимается git-репозиторий внутри yggdrasil.
2. В нём хранятся файлы конфига unbound с записями DNS. Unbound позволяет инклюдить конфиги, что поможет всё структурировать.
3. Структура файлов вложенная, примерно такая:
unbound.conf
unbound.conf.d/domain1.isp.conf
unbound.conf.d/domain2.isp.conf
unbound.conf.d/domain1.medium.conf
...

4. В каждом файле типа unbound.conf.d/domain1.isp.conf первой строкой идёт коммент с e-mail адресом (или несколькими) владельца домена. Ещё какие-нибудь дополнительные данные, может и публичный ключ PGP для подписи коммитов, изменяющих записи домена.

5. Простенькая вебморда при логине будет высылать ссылку с кодом для авторизации на сайте. Тогда владелец сможет зайти и поменять записи для своего домена.
Вебморда будет коммитить изменения только в соответствующий файл.

6. Запускаются несколько независимых DNS-серверов, разными участниками сети.

7. Обновления скриптуются примерно так:
Бэкап текущей конфигурации (хэша коммита).
Пулл из гита.
Проверка работоспособности конфигов. Резолв домена git-репозитория и ещё какого-нибудь своего домена. Потом либо перезапуск unbound с новой конфигурацией, либо откат на бэкап (на предыдущий коммит).
Отправка изменений меинтейнеру сервера, если они есть. (так он, и остальные меинтейнеры у себя, сразу заметят неправомерные изменения в git)
8. Скрипт обновления вешается в cron на каждые 5 минут. Причём, каждый сервер делает это со смещением. Один в 0,5,10 и т.д. минут, другой в 1,6,11 и т.д.

9. Насчёт подписи коммита ключом владельца домена, реализация пока не ясна, но надо будет это обдумать.

Реализация проста, как два пальца, и может простоять десятилетия.
Кроме того, исходники всех скриптов и веб-морды будут в общем доступе, если вдруг какая-то часть (git-сервер или вебморда) перестанет работать по любой причине, то один из администраторов может их поднять у себя.

Ответы на некоторые возражения из Телеграма:
как будет проходить аппрув делегирования? как будет проходить обсуждение? как будет обрабатываться всякие анонимные сообщения «о цепе и подобном», и вообще репорты про домены? если появится несколько регистраторов — как будет проходить процесс делегирования доменов? какие требования к регистраторам?
1. Аппрув делегирования? Никак. Он не нужен. Если домен не занят, он делегируется. Потом, можно написать скрипт, который проверит сколько доменов на каждое лицо выдано, и мы будем решать проблему административным путём.
2. Обсуждения по каждому домену не будет.
3. Сообщения о цп? Ну там же, на вебморде регистратора. Высылается письмо всем админам днс-серверов, они обсуждают где захотят.
4. Регистраторы для новых зон? Через API, которое потом напишем. Сейчас оно не нужно, а разработать его очень просто. Требования простые — придумал новую зону, не пересекающуюся с клирнетом и хочешь её меинтейнить? Отлично, на тебе API. Не хочешь меинтейнить? Можем добавить в общий конфиг, и добавим регистрацию доменов в этой зоне основному регистратору.
,