I2P Multihoming — или один сайт на разных серверах.

Репликация. Фото с сайта clusterdb.com
Репликация. Фото с сайта clusterdb.com

Шалом тебе, дражайший читатель.

Я думаю, настало время поговорить о такой любопытной вещи, как i2p-multihoming, иначе говоря, возможности хостить один и тот же сайт на разных (физически разных) компьютерах. Поясню что я имею ввиду. Допустим, у вас есть некий сайт — скажем rus.i2p (условно) :) и он хостится на каком-нибудь старом системнике на кухне. Понятное дело, что подобная система абсолютно ненадёжна. Отключили электрики свет — всё, накрылся ваш сайт. Отключил провайдер интернет (скажем, авария у него на линии) — сервер недоступен. Куча различных причин! Опять же — пришли к вам какие-нибудь злые пидорасы, и изъяли из вашей квартиры системный блок — ну украли, допустим. И всё, все ваши (а возможно и не только ваши) труды — пошли прахом, владыка, блокаду надо снять. Как иэтого избежать? Нет, самый простой способ — это полное бэкапирование на удалённый сервер — делаете раз в сутки архив, а потом отправляете его туда, не знаю куда. Однако от выключения сервера до развёртки рабочей копии кем-либо на удалённой машине — времени может пройти уйма. Надо думать о чем-то другом.

Благо, уже подумали за нас — в i2p есть такая возможность, как multihoming. Это, по сути, разделение приватного ключа серверного тоннеля между несколькими роутерами, которые в свою очередь могут «смотреть» либо в серверный тоннель основного сайта, либо просто иметь по отдельной копии сайта целиком у себя. То есть физически сайт может находиться на разных машинах, сколь угодно далеко друг от друга находящихся. Для конечного потребителя, имеющего публичный ключ тоннеля, это неважно. Он так или иначе обращается к одному из этих серверов. Разумеется, требуется абсолютно доверять всем серверам, на которых находится приватный ключ тоннеля (читай — домена), и копии сайтов. Плюс существуют некоторые проблемы по организации синхронизации между серверами. То есть, если у вас скажем не статический, а динамический сайт — который использует PHP и базы данных (к примеру — MySQL или PostgreSQL), то возникают проблемы оперативного обновления содержимого. Простой пример — на одной копии сервера пользователь оставил сообщение / отредактировал статью. Но на другой его изменения не появились. Аналогично, если он загрузил файл (картинку к примеру)… Здесь всплывают все проблемы, связанные с построением распределённой и устойчивой архитектуры.

Я вижу решение этой задачи в создании отдельной от I2P сетевой структуры, предназначенной для служебных целей синхронизации контента. Например на основе OpenVPN с шифрованием канала — для этого создаваемые сервера, повторюсь, должны доверять друг другу. Плюс, сама архитектура должна по-возможности включать в себя один или более серверов БД, которые осуществляют репликацию данных (технологии этого уже существуют и довольно давно — ссылка-1, ссылка-2). Кроме того, необходимо проводить синхронизацию статического контента, например с помощью rsync. Соответственно, вариантов запуска rsync несколько — либо по cron, либо по какому-то триггеру, который будет повешен на обработчик, например, загрузчика файлов.

Как видите, задача нетривиальна, но если требуется обеспечить высокую степень надёжности и доступности ресурса в i2p — то здесь применимы все те же методы, которые используются для ресурсов с такими требованиями в обычной сети. I2P в этом случае, по-сути выполняет функции балансировщика нагрузки между зеркалами, и ничего более. При этом, для сохранения анонимности необходимо обеспечить достаточный уровень изоляции между служебным каналом, физическим интернет-соединением и i2p-сетью. Ну и в который раз скажу, что сервера в сети должны друг другу полностью доверять.

Кстати, немного дополнительной информации к размышлению можно почерпнуть здесь, на официальном форуме I2P.

Автор

Алекс Разгибалов

Сумасшедший мужчина, неопределённого возраста, наслаждающийся манией преследования. Паталогически недоверчив, эгоистичен, авторитарен. Вторичные диагнозы - программист и поц. Владеет английским языком на уровне около хренового разговорного. Также знаком с некоторыми другими языками. Интересуется всем и вся, за счёт чего в любой области знания являются поверхностными, неглубокими. Характер невыдержанный. Крепость - 55 градусов.

I2P Multihoming — или один сайт на разных серверах.: 14 комментариев

  1. Как-то пустенько там, в И2П…
    И флибусту оно, похоже, не спасло.
    И на шлюзах — 404.

    Я, честно говоря, так и не понял — клиент жив? или как?

    1. Технически — жив. Просто в рашке приживается довольно сложно, что в целом странно, учитывая правовой климат. Да и лень большинства никуда не делась, хостинг требуется, деньги, возможно разработка движка специализированного…)) А на шлюзах действительно даун, по неизвестной мне причине — второй роутер лёг.
      Флибуста жива, но так, знаете, поциэнту бы реанимация не помешала)) У них там с хостером проблемы есть — на них наехали правообладатели, что в целом иллюстрирует существующий конфликт интересов. Ну, в данном случае это постоянная война меча и щита — в данном случае у нас есть подобный меч для защиты своих интересов — это i2p. Но им почти никто не пользуется, пытаются решить проблему малой кровью, что попроще.

  2. Про флибусту я в курсе, слежу…
    ВВП бы поменьше.

    А меч — и кривоват, и из ножен со скрипом, и рукоятка ХЗ подо что заточена… а уж тяжёл-то как — ява, туды её.
    Да и против терморектального криптоанализа нестоек.
    Это в правовых государствах что-то доказывали. Раньше.

    Думаю, в рашке справедливо считают, что и2п наших проблем не решит ни разу.

    1. Ну с этим да, всё сложно — в этой стране надеяться на соблюдение хоть того же УПК при сборе доказательств — уж очень наивно. Ну, меч то какой есть, да ))) Он как минимум выполняет свои функции — растворить отдельного анонимуса в толпе, к слову ява как раз вполне оптимальна для этой технологии, в плане кроссплатформенности. Вообще я в последнее время с ней довольно близко познакомился, и могу сказать — что это просто отличный инструмент на самом деле. Память жрёт не она даже, больше те данные, которые роутер обрабатывает. Я сильно сомневаюсь, что при переносе допустим на С++ роутер станет есть памяти меньше. Дело не в JVM.

  3. Растворять мелких засранцев в толпе таких же — кой смысл?
    Они и так, фактом толпонутости, прикрыты.
    Хоцца чего-то эдакого, да…

    1. Чтобы не было заметно даже самого шифрованного траффика, угу?)) Да, мне тоже хочется, но это вряд ли пока возможно — по крайней мере на основе существующих каналов связи. Для того, чтобы иметь полностью закрытую сеть, надо аппаратно-программную платформу, типа уоки-токи или нечто вроде такого… Причем беспроводное, и с радиусом действия соответствующим. Ну хотя бы пара километров… Тормозить правда будет, наверное…

    1. Ого! :) Слушайте, спасибо за наводку — это практически воплощение того, что я себе представлял в качестве p2p-радиосети передачи данных)) Правда я пока не нашёл информации по радиусу действия — подозреваю, что в рамках диапазона 2,4 ГГц, это десятки — сотни метров максимум, по сути аналогично WiFi (вряд ли мощность передатчика ZigBee выше, к тому же она регламентируется правовыми документами). В городах с высокой плотностью населения это пожалуй нормально. Скажем если радиус действия в бетонном здании — ну хотя бы 300-400 метров в максимуме диаграммы сигнала, то это позволяет уже организовать связь между близлежащими домами.

      Плюс смущает оговорка по поводу скорости передачи :)) Хотя опять же как гласит вика «В сетях с маячками специальные узлы сети, маршрутизаторы ZigBee, передают периодические маячки, чтобы подтвердить свое присутствие на других узлах сети. Узлы могут находиться в спящем состоянии между маячками, что снижает их скважность и увеличивает жизнь батареек. Интервалы маячков могут различаться от 15.36 мс до 15.36 мс * 214 = 251.65824 с для скорости в 250 kbit/s, от 24 мс до 24 мс * 214 = 393.216 с для скорости в 40 kbit/s и от 48 мс до 48 мс * 214 = 786.432 с для 20 kbit/s. Однако низкая скважность операций (сигналов) вместе с длинными интервалами маячков требует точного распределения времени, что может войти в противоречие с требованием низкой стоимости изделия»

      И по поводу дальности: «В чистом виде, при передаче через воздух скорость передачи данных составляет 250 кбит/с для каждого канала в диапазоне 2.4 ГГц, 40 кбит/с для каждого канала в диапазоне 915 МГц и 20 кбит/с в диапазоне 868 МГц. Расстояние передачи от 10 до 75 метров и свыше 1500 метров для Zigbee pro, хотя оно сильно зависит от отдельного оборудования. Максимальная выходная мощность радио в основном составляет 0 dBm (1 mW)»

      Конечно, 1 милливатт это мало… С другой стороны 1,5 км это уже вполне адекватная дальность… В общем поглядим, что это такое)))

  4. Про ZigBee можно курить спеки изделий, типа
    http://gsm.contrel.ru/wireless/zigbee/xbee/

    И всяких друинщиков, вроде http://www.arduino.cc/en/Main/ArduinoXbeeShield

    Которые его суют во всякую фигню, а ля http://forum.aircam.ru/index.php?showtopic=2036&pid=15947&mode=threaded&start=

    Там сильно разнятся показания — в помещении до 100м, а на воздухе — 1200м.

  5. чё-то очередной ответ куда-то канул :(

    в спеках на изделия (называются обычно «X-Bee Pro») и реализациях (у друинщиков популярно) говорится о 100м в помещении и 1200м (а то и 1.5км) на улице.

  6. Привет!
    Комент не совсем по теме. Но все таки:
    Недавно заинтересовался идеей i2p. Все установил, вроде работает. Только хотелось бы увидеть подробное руководство «Как настроить I2P»для новичков и несмыслящих в сетях и программировании.

    1. А вы поищите по сайту — справа в колонке есть ссылка на рубрику «I2P и анонимность» — и таки там точно было то, что вы ищите, правда для версии ветки 0.7.х, но и для 0.8.х оно подойдёт. Называется вроде «Как получить доступ к I2P проще» (название таки да, не самое удачное). Да и так, много всяческих заметок по теме.

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

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Собирать идеально - не обязательно, просто приблизительно соберите картинку (должен быть включен JavaScript).WordPress CAPTCHA