333.i2p

С сеткой 23.0/8 - разобрались: на основном канале сломалась маршрутизация и значительная часть хостов просто была вне доступа. Сейчас ситуация поправилась...

Сегодня еще обратил внимание на одной из машинок, что подавляющее большинство (32 из 37) адресов в выводе http://127.0.0.1:7070/?page=transports принадлежит одной сети: 23.128.248.0/24. Это что, ботоферма для "ловли" трафика i2p?

В контексте "пресечения активности" - подключил сбор статистики с одного из узлов. И периодически наблюдаю резкий подъем количества Routers и FloodFills... Причем подъемы эти, на мой взгляд, никак не связаны с локальной активностью на хосте.

Вопрос: что это за пики?

Last edited: Thu, 14 Jul 2022, 07:12pm от lecho24

orignal wrote:

Только запустить и посмотреть лог.

Т.е., если у меня доступ по ssh через тот-же ip2d - то все пропало? Или не поднимется только тот туннель, который с ошибками?

orignal wrote:

Другое дело, что утилита выдает их кодировке base64, которая для I2P отличается от стандартной.

Интуитивно понятно, просто я сходу не нашел аналогов функции EVP в командной строке openssl. :)

Не сильно умею читать код "с листа", но мне показалось, что данная утилита всегда (кроме вывода подсказки) генерирует новую пару ключей и других вариантов ее использования - не подразумевается?

Надо тогда где-то акцентировать внимание пользователей на том, что необходимо хранить и приват- и паблик- ключи, т.к. получить из приватного ключа публичный - просто так не получится: пробовал из консоли генерировать командами openssl - получается что-то не то.

Last edited: Thu, 07 Jul 2022, 02:04pm от lecho24

Спасибо! Осталось понять: что произойдет, если при записи очередного ключа - произойдет ошибка...

Есть ли какой-то способ "проверить конфигурацию" до перезапуска i2pd?

В документации как-то скромно сказано по поводу директивы accesslist в конфигурации туннеля.

У нас тут, в связи с переносом одного сайта в i2p, возник вопрос: сколько b32.i2p адресов можно в этой директиве указывать? И что будет делать i2pd, когда упрется в ограничение?

Тот же вопрос предельного количества касается указания в конфигах открытых клиентских ключей при использовании шифрованого лизсета.

txtcon wrote:

i2pd безусловно передаёт сетевому сервису упомянутые тобой заголовки? К примеру "X-I2P-DestB32" не фигурирует в логах.

Это так называемые "HTTP заголовки", в лог их можно положить только если сервер позволяет. У nginx или апача, например, можно определять набор переменных, которые будут записываться в тот, или иной лог. Но это - только HTTP. Для регистрации активности по всем ресурсам хочется какого-то аналога tcpdump? Ну а потом что с этим знанием делать? :) BlackList-а ведь все равно нету...

KOT_HA_MATPACE wrote:

Спустя сутки работы отвалилась операционка, не подает признаков жизни. Повторная попытка привела к такому же результату.

Может быть у кого-то есть скрипт для автозапуска, поделитесь если не жалко

Если "отвалилось через сутки" - то это не автозапуск надо делать а что-то типа системного respawn. Т.е. некий скрипт (запускаемый по крону) следит за наличием процесса (и его блокировок) и перезапускает его в случае отсутствия.

При нормальных условиях - демон i2pd не должен сам по себе падать. Я в таких случаях пробую менять (обновлять) версию... Ну, или логи вычитывать: что там ему не нравится.

reportn462 wrote:

Вернуть серверный туннель в работоспоссобное состояние можно только закомментировав его в tunnels.conf, сделать HUP, раскомментировать, и еще раз HUP.

У нас на 2.42.1 помогает вместо HUP просто рестарт сервиса. Но это хорошо, пока клиентов немного. А если будет с десяток пользователей отваливаться после добавления в access-лист очередного - это будет печально. :(