Pull to refresh

Comments 27

А, собственно, чем не устраивает teredo? Запускается в один клик, работает. У большинства и так уже есть IPv6, потому что uTorrent незаметно для пользователей поднимает IPv6 teredo-интерфейс.
Teredo требует наличия публичного адреса и у клиента и у сервера. Я предлагаю прямую связь между двумя участниками, не имеющими такового.
Вы, находясь за NAT, можете соединиться с другим участником, находящимся за NAT, не требуя поддержки Terendo или других протоколов у ваших шлюзов(провайдеров). (Обратное верно — ваш друг тоже может с вами соединиться)
Вы, находясь за NAT, можете соединиться с другим участником, находящимся за NAT, не требуя поддержки Terendo или других протоколов у ваших шлюзов(провайдеров). (Обратное верно — ваш друг тоже может с вами соединиться)

Я что-то пропустил и наконец-то проблема соединения за NAT решена без участия третьего сервера или эксплуатации багов роутера (hole punching)?
Вы не прочитали документ. Обход NAT через proxy, прозрачно для клиента и сервера.
Ну попробуйте. У микрософта развёрнуты некислые мощности, чтобы держать сервера и релеи Teredo. Возвращаясь к первой ссылке вашей статьи, не исключено, что всё это финансируется в рамках PRISM (а что — вывести национальный трафик на сервера США вполне себе идея). Повторять подобное (схема на проксях) силами энтузиастов — тупиковый путь, нужны другие принципы.
Вероятно. Я согласен с вами, что у свободного сообщества сейчас таких сетей нет.
Я буду думать дальше, может из этого, а может из другого получится.
Skype же заработал по этому принципу. Я верю.
Hole punching это никакие не баги. Это метод работы, основанный на особенностях протоколов.
Метод работы должен быть надёжным. Как минимум, программист должен иметь возможность стандартным запросом определить тип NAT, а не так что «попробовал — не получилось. наверное, не поддерживается».
Teredo не требует наличия публичного IP у клиентов. Они все могут находиться за NAT, и по IPv6 успешно соединяться друг с другом.
> Стандартные средства инкапсуляции IPv6 в IPv4 требуют, чтобы как сервер, так и клиент имели публичный IP-адрес. Однако, в настоящее время многие устройства присоединены к Интернету IPv4 через одно или несколько устройств NAT, как правило из-за нехватки IPv4 адресов. В такой ситуации единственный доступный IPv4 адрес принадлежит устройству NAT. Протокол Teredo даёт возможность доступа к IPv6 сетям при такой конфигурации сети.

Читайте не наискосок. Если сократить фразу, получится «Стандартные средства инкапсуляции требуют, а Teredo — не требует.»
Так в вики так и написано, как у Wolong
Все участники получают уникальные адреса из одного диапазона

Кто раздаёт адреса?
Как другие участники меня найдут, если мой IPv4-провайдер в следующей сессии даст мне другой IPv4-адрес?
Кто раздаёт адреса?

База данных распределена и доступна всем. Если под вашим IPv4 уже существуют участники, вы берете случайный идентификатор. Я решил что оставшихся 8 байт будет достаточно, что бы избежать коллизий по времени.

Как другие участники меня найдут, если мой IPv4-провайдер в следующей сессии даст мне другой IPv4-адрес?

Про динамические адреса я думал, и однозначного решения не нашел.
Я вижу два выхода:
— либо сказать что это сеансовая сеть, и как с обычным IP, вам придется публиковать новый(или обновлять записи dns).
— либо в специальном диапазоне(благо флаги предусмотрены), передавать другие сообщения.
— либо участники должны понимать, если айпи адрес сменился, но публичный ключ остался — это тот же участник

но публичный ключ остался — это тот же участник

Пичалька. Я думал, вы хоть что-то понимаете в сетях, а вот так сразу в кучу публичные ключи и адресацию на уровне L3 не оставляет никаких шансов.
Обидно это слышать. Я сделал свой максимум. Помогите его улучить?
Или, расскажите, в чем ошибка?

Последний пункт был экспромтом, потому как я считал, что развитие по первому варианту логично. От ipv4/ipv6 никто не требует подобного.
С тех пор, как это не стандарт, а посредник, я думал его разместить между L3 и L4.
Все таки сеть оверлейная.
Тогда ключи — это ключевой момент сети (извиняюсь за каламбур). И их надо было подробнейше в статье рассмотреть.
Текст был составлен на основе слегка измененных правил копирайтинга:
— написанный текст продает лучше ненаписанного
— написанный и выложенный текст продает лучше невыложенного
— написанный, выложенный и прочитанный текст продает лучше непрочитанного
Я решил, что лучше выложить сырую документацию, и скорее ее доработать.
Не, ну если вы сюда как продажник, а не как технарь, это делает мои придирки совершенно безосновательными.
Простите, ввел в заблуждение, это аллегория.
— написанная документация дорабатывается лучше ненаписанной
— написанная и выложенная документация дорабатывается лучше невыложенной
Товарищ топикстартер. А как на счёт уже существующих cjdns (hyperboria), tinc (chaosvpn) и иже с ними?
Спасибо, добра вам! Исправлю пост.
То, что вы предлагаете очень похоже на то, что уже делает Host Identity Protocol (HIP) for Linux. Это открытая реализация HIP, пока только для линукса. Работает именно так — создается новый интерфейс со специальным адресом, и все пакеты в данную подсеть перехватываются. Бонусом идут шифрование, идентификация узлов, проверка целостности, криптографически проверяемые адреса.
Прочитал по диагонали. Для IPv6 NAT ненужен, соответственно нет и проблем с ним.
За одним небольшим исключением… если провайдер НЕ предоставляет доступ в интернет по IPv6.
Sign up to leave a comment.

Articles