Как работает честный P2P за раутером?

p2p vpn. Кажется, openvpn умеет это.

OpenVPN находит хосты с помощью торрент-трекера,то есть центрального сервера.А как дальше оно работает без прокси и разного IP?

Вопрос непонятен. Если ты хочешь организовать связь двух «серых» машин без участия третьей стороны, то нужно на роутере пробрасывать порты. Т.е. на роутере указываешь, какой его входящий порт соответствует какому порту какой внутренней машины. В частном случае можно пробросить порт только на одном роутере, тогда соединение может быть активировано со второй «непроброшенной» машины.

Если хочешь связать две «серых» машины между собой не имея возможности возиться с роутерами, то нужна внешняя третья машина, с которой они соединятся и через которую пойдёт трафик.

Других вариантов нет.

digger> OpenVPN находит хосты с помощью торрент-трекера,то есть центрального сервера.А как дальше оно работает без прокси и разного IP?

Заводишь там, где у тебя есть внешний IP-адрес и возможность управлять маршрутизацией сервер OpenVPN. Подключаешься со своих клиентов на этот сервер. Т.к. сервер с openvpn — твой, можно меньше волноваться о компроментации и допуске посторонних к этому решению. Получаешь туннели, по которым бегает любой маршрутизируемый трафик. Альтернативой этому — только проброс портов, как Рома правильно отметил. Однако, этот способ тебе не подходит из условий задачи, т.к. роутеры клиентов трогать нельзя.

Balancer> Других вариантов нет.

UDP hole punching. Но начальном этапе третья машина нужна, но потом — нет.

AXT> UDP hole punching

Интересно, не знал. Но, да, всё равно нужна третья машина.

Изучал,машина нужна,если дырка не пробьется.Нет уникального IP - прямая связь невозможна.Получается,современный Интернет с НАТом - дефективный по своей природе.А как работает торрент P2P? За раутером - 2 машины,качающие разные файлы с таких же машин.Использует чужие машины,имеющие уникальный IP,или один из компьютеров в сети,в качестве прокси?

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

digger> Получается,современный Интернет с НАТом - дефективный по своей природе.

Это не «современный Интернет», а «Интернет ультрадешёвых провайдеров и операторов сотовой связи». Он массовый, не не всеохватывающий Вот, скажем, у Корбины/Билайна при всей его массовости все IP белые. На том Авиабаза сейчас и сидит.

digger> А как работает торрент P2P?

Через «белые» пиры. Если все будут серыми, раздачи не будет.

digger> Сама тема - прожект босса.Сделать что-нибудь эдакое мониторящее всю домашнюю сеть и телефоны впридачу,но без центрального сервера

Ну, пусть каждый отчитывающийся складывает отчёты в BTSync. А то, чем мониторишь, просто будет смотреть в каталоге на тему изменения файлов и их содержимого.

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

digger> По замыслу у нас максимальная приватность,т.е. по возможности никакого физического рилея через посторонние сервера

Тогда (порты не пробрасываются, как я понимаю, иначе бы вопроса не было?) только самому что-то писать для UDP hole punching. И всё равно третья машина на время установки соединения потребуется.

То есть фирменный сервер с известным УРЛ,как обычно.Примерно так я себе представляю.Человек получает ID,одинаковый на всех его машинах,ставит аппликацию.Аппликация сообщает на сервер свой внутренний и внешний IP ,общий ID и уникальный сгенерированный ID каждой машины.Дальше с каждой машины можно попробовать опросить все другие машины ,пробуя или внутренний ,или внешний IP для каждой,используя данные с сервера.Теперь мы пытаемся с телефона попасть на 3 машины с одним IP за раутером.Одна из машин получает пакеты за все 3,так как раутер так сконфигурирован.Она видит не свои уникальные ID и ищет машины по внутреннему IP.Находя,рилеит данные на телефон.

digger> Изучал,машина нужна,если дырка не пробьется.
Поправочка - она нужна чтобы пробить дырку. А если не пробьешь - оно работает прокси.
digger> Нет уникального IP - прямая связь невозможна.
"Беолго" IP наверное? Он всё равно будет А уникальной доджна быть пара IP:Port
digger> Получается,современный Интернет с НАТом - дефективный по своей природе.
Перейди на IP6 .. там НАТ не нужен

>А уникальной доджна быть пара IP:Port

Не совсем понимаю.За модемом-раутером 2 компьютера с одним внешним IP.Снаружи - телефон на мобильном Интернете.Пакеты с телефона приходят куда надо просто за счет разных портов на 2-х компьютерах?Или нужны дополнительные ухищрения?Как решается проблема с открытием/закрытием UDP портов раутерами : как выбрать порт,который он пропустит?

>>А уникальной доджна быть пара IP:Port
digger> Не совсем понимаю.

Да всё просто. В UDP нет понятия сессии (соединения), каждый пакет едет сам по себе. Из-за этого NAT не обладает полной информацией о соединении, и вынужден транслировать всё, что похоже на реальный пакет. Отсюда есть возможность его обмануть.

digger> Получается,современный Интернет с НАТом - дефективный по своей природе.
Интернет с NAT-м — очень дефективен. И бывший "председатель" IETF об этом прямо говорил, когда этот NAT ещё только внедряли и был очень против. А я на Базе много лет назад его слова приводил и подтверждал.

PS Я ни как не пойму, в чём сокральность UDP Hole Punching? В чём разница с TCP? В отношении демультиплексирования трафика разницы нет.

Keith Moore и сейчас ведёт борьбу против (P)NAT-а в IPv6, но опять проигрывает. Если интересны старые обсуждения, то можно почитать тут — Re: draft-ietf-nat-protocol-complications-02.txt — по цепочке в обе стороны. Про IPv6 можно почитать тут — nat66 nat66 ipv6

Оригинальные документы http://www.cs.utk.edu/~moore/what-nats-break.html и http://www.cs.utk.edu/~moore/opinions/ipv6/dubious-assumptions.html на страничке универа не существуют. Он там больше не работает.

О, таки нашёл — http://jooh.no/root/text/NAT_bad/what-nats-break.html — кто-то сохранил.

Интересно, что сам большой и ужасный Оле Якобсон выступал за NAT в 2004, аргументируя тем, что то, что ломает NAT не так уж и интересно с точки зрения бизнес-поездок. На сегодня Оле уже не считает свои аргументы легитимными.

AXT> Да всё просто. В UDP нет понятия сессии (соединения), каждый пакет едет сам по себе.
Да, UDP stateless протокол. Только (P)NAT-у наплевать на это дело. Он не firewall. Т.е. он смотрит в TCP и, как только получает запрос на разрыв, то удаляет из своих таблиц. Для UDP он это делает по таймеру. Хотя умные (P)NAT делают по таймеру и для TCP. Не у всех выставлена опция Keep Alive для TCP.

AXT> Из-за этого NAT не обладает полной информацией о соединении, и вынужден транслировать всё, что похоже на реальный пакет.
Это не правда. (P)NAT должен быть настроен. Либо на трансляцию адреса внешнего на внутренний (внутренний на внешний там автоматом) на какую-то машину (чистый NAT, сам NAT просто не имеет представления, какой внутренний IP использовать, когда приходит запрос), либо трансляцию портов и адресов (PNAT) на указанные внутренние порты и адреса. Проблемы в том, что тот же FTP клиент сообщает серверу по командному каналу (в активном режиме) свой адрес и порт для передачи данных по каналу данных, на которых он собирается слушать. Т.е. сервер тут выступает в качестве клиента и пытается установить соединение с FTP клиентом, который выступает в качестве сервера. При этом, обычно, в FTP клиентах выбор порта для данных отдаётся на откуп ОС, т.е. любые значения в диапазоне 1024-65535. И таких приложений много. Скажем, многие VoIP с коммутацией. Или всякие лоадбалансинги. Третий вариант — это DMZ, но тогда весь трафик направляется (по неустановленным соединениям) на один адрес. Кстати, (P)NAT независимо от протокола уровня UDP или TCP ведёт сессии. И таймауты там есть, как указано выше. Собственно сессия у него выражается во входе в табличку — адрес и порт из серой сети с временной пометкой. Т.е. это такое знание приобретённое, которое помогает ему направлять пакет, пришедший снаружи, на нужный адрес и порт (путём подправления заголовка пакета). Нет входа — нет перенаправления. Правила открытия портов/адресов — это добавление ручками входов в эту таблицу на перманентной основе.

Поэтому разницы между TCP и UDP здесь нет. Для демультиплексации трафика используется тот же механизм портов. Кстати, даже в IPv6 SCTP тоже использует такой же механизм. Только он имеет ещё один уровень демультиплексирования — в нём можно организовать независимые подпотоки.

В чём может есть разница, так это в том, что в TCP ОС обрабатывает таймауты, а в UDP приходится прикладнухе этим делом заниматься — да, эта разница между надёжным TCP и ненадёжным UDP.

AXT> Отсюда есть возможность его обмануть.
Это не верно.

Balancer> только самому что-то писать для UDP hole punching. И всё равно третья машина на время установки соединения потребуется.
Не сработает. Если (P)NAT не сконфигурён, то не сработает.

Unix> Поправочка - она нужна чтобы пробить дырку. А если не пробьешь - оно работает прокси.

Ну откуда это берётся? Вот объясните мне. 10 лет я с этим делом работал, писал софт для управления сетями. Не пробивается так (P)NAT.

Что люди пытаются сделать, так это послать на какой-то левывый адрес UDP пакет, чтобы строчка появилась в табличке NAT, а потом пакеты, приходящие на этот адрес будут перенаправляться. Вот только нормальынй NAT смотрит на источник тоже. Не с того приходит, значит не пропускает. Потому и пробуют связаться с белым IP, чтобы тот сообщил реальныыыый адрес, куда пакет тиснуть. При этом со второй машины должно прийти пакет на первую, тоже со внешним адресом. И это должно пройти в рамках таймаута. Т.е. можно, наверное, назвать это пробитием дырки, только там надо до фига чего учитывать.

Unix> Перейди на IP6 .. там НАТ не нужен
Раскатал губу. Посмотри на ссылки, что я дал.

Чтобы не растекаться по древу:

AXT>> Отсюда есть возможность его обмануть.
Mishka> Это не верно.

"Если оно неправильно, но работает, значит, это не неправильно". И UDP hole punching таки работает.

(ответ на правленное)

Mishka> ... а потом пакеты, приходящие на этот адрес будут перенаправляться. Вот только нормальынй NAT смотрит на источник тоже. Не с того приходит, значит не пропускает.

... и тут, внезапно, мы указываем фальшивый IP источника.

Mishka> Ну откуда это берётся? Вот объясните мне. 10 лет я с этим делом работал, писал софт для управления сетями. Не пробивается так (P)NAT.
Ты слишком серьёзен Mishka.
То, что ты 10 лет писал - ты писал для нормальных девайсов типа "кошка некастрированная" - а то что в residence areas стоит окучивать приходилось? Ухохочешься.

Unix>> Перейди на IP6 .. там НАТ не нужен
Mishka> Раскатал губу. Посмотри на ссылки, что я дал.
Да ладно, я ж не знал что из всех смайлов ты распознаешь только самый мнэээ ... лошадинный
Кстати - гдето у меня в букмарках был более менее короткий но вменяемый хауту на эту тему. Найду - кину.

Mishka> Поэтому разницы между TCP и UDP здесь нет. Для демультиплексации трафика используется тот же механизм портов.

Разница в том, что у в TCP есть ещё и последовательный нумер и флаги, которые мало того, что приложениям не всегда доступны, так еще вносят асимметрию. То есть даже если клиенты обменяются всей информацией через 3-ю точку, они не могут сформировать 2-е пакеты, которые выглядят допустимыми для NAT. Им там надо SYN+ACK проставить как минимум. Далеко не всякий транслятор выпустит такое если 1-й пакет SYN не был, а его не впустить, так как он входит с противоположной стороны.

AXT> "Если оно неправильно, но работает, значит, это не неправильно". И UDP hole punching таки работает.
При нормально настроеной сети очень уж плохо работает, если не сказать, что совсем.

AXT> ... и тут, внезапно, мы указываем фальшивый IP источника.
В каком пакете? Входящем или исходящем? В исходящем — нормальный NAT знает про внутренние адреса и просто его не выпустит за пределы. Т.е. строки в таблице не создастья. Во входящем — он просто может не доехать, т.к. простая маршрутизация по только получателю во многих местах заменена на более умную.