333.i2p

Мой сервис недоступен внутри сети. Такая бодяга уже возникала ранее. Вылечил перезапуском демона. Сейчас перезапуск не помог.

21:32:28@901/info - SOCKS: requested ***.i2p:**
21:32:28@901/info - Destination: Requesting ***= at rGY3Vu0LSZ~nI7YBj7x-sGgN224-JhxoVs-rNlmAH10=
21:32:29@901/info - Destination: Requesting ***= at rDIsxDdTlBTYzkU~hb1bE7AP2lP2RkqTOJhCUz9BKsk=
21:32:34@901/info - Destination: Requesting ***= at rKbFuTGrLvir4PBafeLYOQSIdWt-QZnTAKZJWcOFxp8=
21:32:34@901/info - Destination: Requesting ***= at rWZMOblslnhKzTci1SKINubhLA4tuOqdKDExTwzjRSI=
21:32:34@901/info - Destination: Requesting ***= at rRL5aK9EUjmkstNCnJjmD9Vj~9MtR5xZK39kBcF7aQ0=
21:32:35@901/info - Destination: ***= was not found on 7 floodfills
21:32:35@901/error - SOCKS: error when creating the stream, check the previous warnings for more info
21:32:35@901/warn - SOCKS: v4 request failed: 4
21:32:35@901/warn - Destination: Request for ***= not found

Аналогично через HTTP прокси.

Обратил внимание на крайне малое количество обращений к сервису с утра. Они есть, но в мизерном количестве. Самое интересное, что я не могу получить доступ к собственному сервису, обращаясь к нему через HTTP или SOCKS прокси.

Надо смотреть логи не запросов, а публикаций.
Возможно плохой флудфил попал.

Плохой floodfil попадал на протяжении суток? Сейчас запустил - всё равно флудфилы плохие.
Возможно проблема кроется в другом - вчера обновил систему, среди завимосотей i2pd был openssl.

Установил нативный i2p, там поднял свой сервис - попадаются только хорошие флудфилы. Вполне возможно я откажусь от i2pd в пользу i2p.

Last edited: Thu, 02 Sep 2021, 08:20am от sAzh7Y

>Плохой floodfil попадал на протяжении суток?

Да. Потому что он ближайщий.

Надо будет сделать профилировщик флудфилов.

На той же самой машине у меня есть ещё один сервис. Он доступен, вообще нет проблем. Ты всё ещё винишь floodfill?

Зависит от самого адреса. Как раз это подтверждает что дело именно во флудфиле.

Методом научного тыка удалось нащупать и устранить проблему. Floodfillы оказались не причастны. Одновременно с этим нащупал нечто неожиданное для себя.

Ключ проблемного сервиса был накануне заюзан для клиентского тоннеля. В тот же день день служба на серверном тоннеле стала недоступна в сети.

Сменой ключа на клиентском сервисе удалось решить главную проблему и сразу обнаружить другую: почему нельзя использовать один ключ более одного раза и для разных типов тоннелей? Этот вопрос актуален, в том числе, для i2p.

Last edited: Sat, 04 Sep 2021, 11:54am от sAzh7Y

получился дубликат сообщения.

Last edited: Sat, 04 Sep 2021, 11:53am от sAzh7Y

>почему нельзя использовать один ключ более одного раза и для разных типов тоннелей?

Можно. И используется довольно часто.

Возможно в этом конкретном случае сначала создается клиентский тоннель и устанавливает флаг что не публиковать лизсет. Я проверю, если это так то баг.

С трудом верится в наличие идентичного бага в двух реализациях. В i2p не стабильно работают тоннели с одинаковым ключом. Один из таких тоннелей можеть падать. Налицо наличие конфликта из-за ключа.

Джава не позволяет держать клиенский и серверные тоннели на одном адресе.