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

Unix> То, что ты 10 лет писал - ты писал для нормальных девайсов типа "кошка некастрированная" - а то что в residence areas стоит окучивать приходилось? Ухохочешься.
Да чего там в резиденсах. В IETF люди не все понимают. Посмотри на дискуссии 2009-2011 годов. Скажем, в том же Верайзоне вполне себе белые адреса (и несколько можно купить). А замутил дома такую вот серую сетку, так сам и пожинаешь плоды.

Mishka>> Поэтому разницы между TCP и UDP здесь нет. Для демультиплексации трафика используется тот же механизм портов.
zaitcev> Разница в том, что у в TCP есть ещё и последовательный нумер и флаги, которые мало того, что приложениям не всегда доступны, так еще вносят асимметрию.
Для демультиплексации эти флаги пофигу.

Ну, и, если мы начинаем подсовывать произвольные IP адреса, то уже сидим чуть ли не на уровне raw sockets. Значит и все флаги можно добыть.

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

Если сидим на уровне сырых сокетов, то обойти State Machine для TCP протокола тоже уже не шибко сложно. Я тебе больше скажу, можно перехватывать IP пакеты и там шурудить вплоть до того, что поставить альтернативный стек. Чем в своё время тоже занимались и на винде, и на лине древнем. А уж, как наши QoS драйвера работали...

Mishka> В исходящем — нормальный NAT знает про внутренние адреса

Ключевые слова процитированы. А теперь переходим в реальный мир ...

И да, без raw тут сложно.

Mishka> А замутил дома такую вот серую сетку, так сам и пожинаешь плоды.
Ну дык - comes with NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. © всё что связанно с IT.

А доку если найду - кину. Оно не поможет конечно, но и не помешает, бо маленькое. ТСу может пригодится.

AXT> Ключевые слова процитированы. А теперь переходим в реальный мир ...
Да-да, ключевые. Реальный мир. Реальный мир принял NAT, не особо понимая, что это. Но теперь все изыскивают. В общем, это, как с вирусами. Может сработает. )

AXT> И да, без raw тут сложно.
Дык, с raw разницы нет совсем. RFC 6528 - Defending against Sequence Number Attacks — тебе и Зайцеву будет интересно. 2012 год, Ещё только Proposed Standard. Это о том, как вклинится в TCP сессию. Хотя Стив Беловин, ещё в 1996 году предупреждал. Даже RFC написал 1948, который информационным и остался. Новый хоть в стандарты метит.

Mishka> Для демультиплексации эти флаги пофигу.

Зато для фильтрации не пофигу.

Mishka> Ну, и, если мы начинаем подсовывать произвольные IP адреса, то уже сидим чуть ли не на уровне raw sockets. Значит и все флаги можно добыть.

Во-первых, никто произвольных адресов не подсовывает. Это просто г-н yacc тебя запутал.

А во-вторых, клиент может какие угодно флаги ставить, но файрвол не пропустит.

Объясню, но это будет в последний раз.

Примем 2 клиента C1 и C2, и их файрволы F1 и F2. Для hole punching, C1 и C2 посылают нулевые пакеты с портами источниками pi1 и pi2 общей машине T, которая записываэт внешние порты источников этих пакетов, pe1 и pe2 (зачастую, если есть место в адресном пространстве NAT, peX == piX, но не всегда). Затем, через нормальный канал, T шлет pe1 C2 и pe2 C1.

После нулевых пакетов CX шлют первые пакеты, но уже друг другу. Рассмотрим C1. Его первый пакет имеет исходный порт pi1, в надежде, что NAT перемапит его в тот же pe1, который нам известен. Порт назначения у него pe2. Если нулевой пакет не открыл сессию, то первый откроет. Если при этом изменилось отображение pi1 к pe1, то все пропало и hole punching работать не будет.

Если C2 пошлет первый пакет несколько пожже, то его сессия в F2 может быть не открыта (если F2 открывает строгие адресные сессии и таковая создалась после нулевого пакета). Тогда C1 должен будет повторить посылку.

Теперь рассмотрим проблему TCP. На нулевой стадии необходимо не 1 пакет, а 4, так как сессия наверняка будет создана, а перанаправить ее будет невозможно. Это вообще-то делает всю рабуту тут практически невозможной. Но допустим, что каким-то чудом нам удалось узнать peX и первая сессия будет иметь его снаружи. Это нам все равно не поможет, так как состояний у сессии TCP больше, чем у UDP. Внимательно следи за шариком:

Допустим C1 шлет первый пакет. Это, конечно, будет SYN. Он благополучно открывает сессию в F1 и уходит с pe1:pe2 наружу. Допустим, что C2 сделал то же самое одновременно и на F2 есть такая же сессия. Казалось бы, дело в шляпе, "демультиплексации эти флаги пофигу". На самом же деле, это ничему не поможет, так как фильтр сбрасывает голый SYN. Но если C2 попытается этому помочь, послав SYN+ACK, его сбросит F2, так как сессии TCP создаются только по SYN.

Теперь тебе видна асимметрия?

digger> Конфигурировать раутеры нельзя

Посмотри, включен ли на этих роутерах UpNP. С ним будет работать, так как один из его компонентов - чтобы приложения на клиентах заказывали какие порты открыть и пробросить. Его только, к сожалению, трудно сделать безопасным, и в последнее время его стали держать выключенным по умолчанию.

Mishka> Дык, с raw разницы нет совсем. RFC 6528 - Defending against Sequence Number Attacks — тебе и Зайцеву будет интересно. 2012 год, Ещё только Proposed Standard. Это о том, как вклинится в TCP сессию.

Спасибо. Ещё более дешёвый угон сессии есть в IPX, тоже через sequence number (забыл, как он там точно именуется, 20 лет прошло уже). 2⁸ сложность подбора, автор протокола с ёлки на голову упал вообще?
А ещё немного постаравшись, можно сделать так, как будто он по-прежнему в соединении. Только весь трафик у нас. Дыра, как из главного калибра "Айовы". Главное, в той же подсети быть.

zaitcev> Во-первых, никто произвольных адресов не подсовывает. Это просто г-н yacc тебя запутал.

При проколе? В общем-то подсовывают.
zaitcev> А во-вторых, клиент может какие угодно флаги ставить, но файрвол не пропустит.
С трёх шаговым здорованием я знаком хорошо, можно было бы и не тратить время. В тех же RFC есть нормальное словесное описание автомата TCP сессии, в которой этот handshake входит. Только заметь, что там не описаны многие таймауты, которые на данный момент имплементированы. В частности, знаменитый FIN_WAIT_2, который был причиной элементарной DOS атаки на ту же HP-UX 10, а потом и 11. И обнаружили мы это случайно на моей первой работе на плохой модемной линии. Я смоделировал ситуацию и выбрал все порты на машине за секунду. Пришлось перезагружать.

zaitcev> Объясню, но это будет в последний раз.

Не надо. Это имеет довольно слабое отношение к NAT. На NAT\PNAT (или его стали называть NAPT) нет RFC стандарта. Есть пара информационных. Поэтому все извращения, как он должен работать — на совести разработчиков. Но те 2 RFC, скажем, предлагают ещё и протоколы верхнего уровня анализировать.

zaitcev> Теперь тебе видна асимметрия?
С точки зрения NAT-а — не-а.