FEDAnet: полная версия исходных текстовWed Jun 25 18:00:00 2025 UTC Кажется, мне удалось-таки допилить исходники FEDA (включая сервер) до состояния, когда их всё-таки можно показать публике. Не, ну там, конечно, внутри по прежнему жуть с ружьём, но совсем откровенные заплатки я вроде заборол. Так что если у кого есть больше одной машины на реальных IP-адресах, можете попробовать поднять свою систему серверов для проверки типа NAT. Можно, естественно, кооперироваться. Сервер ресурсов жрёт чуть больше чем ничего, всё, что ему нужно — это один несчастный UDP-порт. Ещё появилась хотя бы одна полезная (прямо сейчас) функция у всей этой криптографической инфраструктуры: можно пойнтовым ключом подписать произвольный файл и потом эту подпись проверить. В планах стоит ещё шифровка/дешифровка, но пока не реализовано. Баги там, скорее всего, многозубые и в количестве, код жутко сырой, но лучше, чем ничего. В общем, вот новость на сайте FEDAnet, вот тут качать архив. Спасибо всем, кто поддержал проект! 
|
пояснениеВы находитесь на официальном сайте Андрея Викторовича Столярова, автора учебных пособий по программированию и информационным технологиям. Если вы искали сайт замечательного писателя-фантаста Андрея Михайловича Столярова, то вам, к сожалению, не сюда. Андрей Михайлович Столяров в библиотеке Мошкова |
☞ From Parthen (unverified) Fri Jun 27 10:07:08 2025 UTC
Таки поднял
Как-то я упустил, что за second stage?
ответить
Re: Таки поднял
> что за second stage?
Там всё выглядит так: сначала natcheck посылает серверу пять штук "заглушек" (stubs), чтобы сервер мог исполнить принцип "не посылать в ответ больше, чем было в запросе"; после этого серверу отправляется дэйтаграмма "хочу проверить свой NAT". Сервер в ответ на это отправляет дэйтаграмму, в которой указано, во-первых, как выглядит с его точки зрения адрес того, кто к нему пришёл, а во-вторых, сколько у него есть peer'ов и где они (адрес/порт каждого). Кроме того, сервер посылает своим peer'ам дэйтаграммы с просьбой кинуть дэйтаграмму такому-то (собственно тому, кто пришёл). Получив эти просьбы, peer'ы кидают на указанный адрес свои "заглушки" (это того же типа дэйтаграмма, которая используется natcheck'ом в самом начале).
На своём конце natcheck сидит и ждёт (по умолчанию 5 секунд), что ему придёт. Ну или если пришло всё, чего можно было ожидать, то вываливается раньше, но это бывает только при Full Cone. Собственно, при Full Cone он получает и ответ сервера, и заглушки от peer'ов, и на основании этого радостно констатирует, что это Full Cone, и успокаивается.
Если ему пришёл только ответ от сервера, но заглушки от peer'ов не пришли, он понимает, что с Full Cone тут не сложилось, но чего он пока что не может утверждать с уверенностью — restricted это или symmetric. Вот тут, собственно, и проводится second stage: natcheck тупо посылает echo request'ы тем peer'ам, которые ему любезно подсказал сервер в своём ответе. В ответ на echo request приходит echo reply, содержащий информацию о том, как мы выглядим с точки зрения того, кто нам отвечает, т.е. какие он видит пары адрес/порт. Если они совпадают между собой и с тем, что сервер сказал — значит, это Restricted Cone. Если не совпадают — ну, нам не повезло совсем, это долбаный symmetric.
ответить
Re: Re: Таки поднял
Ну, вроде понятно.
P.S. Сервера я оставил запущенными, кто хочет попробовать - welcome
ответить
Re: Re: Re: Таки поднял
ответить
Re: Таки поднял
Странно, у меня работает — только что проверил
ответить
Re: Re: Таки поднял
Сервак в Нидерландах, может из-за этого
ответить
Re: Re: Re: Таки поднял
Вряд ли, ибо на веб сайт заходится без проблем.
ответить
☞ From Anonymous (unverified) Thu Jun 26 23:12:09 2025 UTC
Поднял свои сервера для проверки NAT
Поднял свои сервера для проверки NAT (на 2 машинах). Проверил в natcheck - работает.
Скомпилировал на домашней машине, а на сервера пробросил статические бинарники. Почему-то при выполнении deploy на каждом сервере вначале писало следующее:
при котором, насколько я помню, создавались не все файлы и последующие import не работали. После того, как я какое-то время ждал и повторял процедуру (отчищая создаваемые файлы) команда отрабатывала спокойно (как на домашней машине) и в дальнейшем все работало.
В 2 часа ночи я как-то поленился лезть в исходники и узнавать что эта строка значит. Не знаю связано ли с этим то, что время (seconds since the Epoch) на моих серверах и домашнем компьютере отличается на несколько минут.
P.S. Линуксом пользуюсь лишь 4 года, а сервера себе взял лишь пару месяцев назад, поэтому досконального понимания того, что я делаю, у меня нет.
ответить
Re: Поднял свои сервера для проверки NAT
ZP cert outdated означает буквально, что у вас там локально в базе ($HOME/.fedanet/keys/...) есть сертификат для zero point той же ноды, который новее (по его тайммарку), нежели тот, который вы пытаетесь сохранить. С текущим временем оно, насколько я помню, ничего не сравнивает, только разные сертификаты между собой. Но вот обновление (перегенерация) сертификата для zero point влечёт, что вполне естественно, недействительность всех сертификатов, подписанных подписью этого вашего zero point — того, который старый.
Ну, во всяком случае так должно быть :-) За отсутствие багов в этом коде я никак не поручусь.
ответить
☞ From Anonymous (unverified) Thu Jun 26 21:22:10 2025 UTC
Возможно опечатка в NC_SERVERS
NC_SERVERS, 183 строка: > usere specify ports
ответить
Re: Возможно опечатка в NC_SERVERS
Есть такое, спасибо.
ответить
☞ From Parthen (unverified) Wed Jun 25 19:08:43 2025 UTC
Поздравляю!
И вдогонку:
NC_SERVERS, 179 строка:
>theserver in any other way
ответить
Re: Поздравляю!
thanks :)
ответить