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

 
+
-
edit
 

digger

аксакал

Допустим,есть 2 офиса или дома.В каждом стоит 1 раутер,к которому подключено несколько компьютеров,разумеется,с одним внешним IP.Ну или компьютеры за раутером и телефон на мобильном Интернете.В частности, RDP на этот IP заходит только на один из компьютеров.Задача - как послать данные из одной подсети в другую,TCP или UDP - без разницы,с минимальным вмешательством.Конфигурировать раутеры нельзя : компьютеры - это частные клиенты,на которые ставится минимально интрузивный софт.Нечестные способы известны : связь через прокси,где оба компьютера в действительности подсоединены к одному внешнему серверу и данные проходят через него.Так работает TeamViewer в плохих случаях.Известен UDP hole punching : узнается внешний и внутренний IP и посылается на оба,связь работает на том,на котором удается.Но у нас нет разных внешних IP.
 33.033.0
+
-
edit
 

HolyBoy

аксакал

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

digger

аксакал

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

Balancer

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

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

Других вариантов нет.
 3838
+
-
edit
 

HolyBoy

аксакал

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

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

AXT

инженер вольнодумец
★☆
Balancer> Других вариантов нет.

UDP hole punching. Но начальном этапе третья машина нужна, но потом — нет.
... так пускай наступает на нас холодным рассветом новый день ...  13.0.782.22013.0.782.220
+
-
edit
 

Balancer

администратор
★★★★★
AXT> UDP hole punching

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

digger

аксакал

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

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

Balancer

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

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

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

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

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

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

digger

аксакал

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

Balancer

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

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

digger

аксакал

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

Unix

опытный

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

digger

аксакал

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

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

AXT

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

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

Mishka

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

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

Keith Moore и сейчас ведёт борьбу против (P)NAT-а в IPv6, но опять проигрывает. :( Если интересны старые обсуждения, то можно почитать тут — Re: draft-ietf-nat-protocol-complications-02.txt — по цепочке в обе стороны. Про IPv6 можно почитать тут — Re: [nat66] Necessity for NAT remains in IPv6 Re: [nat66] Necessity for NAT remains in IPv6 Re: why market picked up NATs [Re: Writeups on why RFC1918 is bad?]

Оригинальные документы 404 Not Found и 404 Not Found на страничке универа не существуют. Он там больше не работает.

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

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

Mishka

модератор
★★★
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> Отсюда есть возможность его обмануть.
Это не верно.
 17.017.0
Это сообщение редактировалось 08.12.2014 в 08:43
+
-
edit
 

Mishka

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

Mishka

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

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

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

Unix> Перейди на IP6 .. там НАТ не нужен ;)
Раскатал губу. :F Посмотри на ссылки, что я дал.
 17.017.0
Это сообщение редактировалось 08.12.2014 в 08:57

AXT

инженер вольнодумец
★☆
Чтобы не растекаться по древу:

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

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

AXT

инженер вольнодумец
★☆
(ответ на правленное)

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

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

Unix

опытный

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

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

zaitcev

опытный

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

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

Mishka

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

Mishka

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

в начало страницы | новое
 
Поиск
Настройки
Твиттер сайта
Статистика
Рейтинг@Mail.ru