Способы обхода NAT или взаимосвязь через интернет (2 стр)

STUN сервер сидит на фиксированном адресе. Все кому надо соединиться на нем регистрируются, он засекает их адреса и порты, они имеют возможность найти друг друга. Точно также можно сделать и через batle.net, и через steam, и через кучу других сервисов, включая свои собственные. В любом случае, для этого необходим сервер, пусть даже выполняющий очень мало функций.
Передается все напрямую, но без сервера не узнать адреса и порты друг друга, они ведь динамические. Коллекционированием адресов и портов пробитых NATов и занимается stun-сервер. Это единственное чем он занимается. Для общения с сервером есть соответствующий протокол.

Можно и без сервера... Пробросить порты через роутеры, если есть права эти роутеры администрировать. Тогда можете считать что у вас адрес внешний и проблем никаких нет.

Dampire
> Сейчас практически на всех роутерах (кроме корпоративных) есть UPnP NAT.
На который не стоит полагаться, поскольку зачастую он не работает или работает не так, как хотелось бы.

Gecko
> I2P можно заюзать, он за NAT'ом работает
При проброшенных портах. По крайней мере у меня нормально не работал, пока я уме порт не открыл.

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

outcast
> С этого места можно подробнее? Как через стун передать второй стороне что-то?
Никак. STUN - это всего лишь технология, позволяющая софту на ПК за NAT узнать свой внешний адрес и соответственно в протоколах указывать его для связи. Если маршрутизатор не настроен на пропуск входящих соединений куда надо, то ничего ты не передашь. Хотя его можно использовать как вспомогательную технологию.

По сути, единственный способ соединить два ПК за NAT, без проброса портов или использования DMZ - это использовать тоннель через промежуточный сервер, куда прицепятся оба клиента и после будут обмениваться информацией.

Также как вариант - ПК отсылает пакет на промежуточный сервер, маршрутизатор строит для него пару "адрес:порт внешний" - "адрес:порт внутренний". После этого к ПК можно достучаться извне, отправляя пакеты на "адрес:порт внешний", маршрутизатор будет всё слать на этот ПК. Внешний порт, который открылся, можно узнать через STUN (вот тут не до конца уверен, надо проверить, через тот же внешний порт будет идти запрос к STUN или нет). На UDP-трафик это точно работает.

agentgoblin
> Никак. STUN - это всего лишь технология, позволяющая софту на ПК за NAT узнать
> свой внешний адрес и соответственно в протоколах указывать его для связи. Если
> маршрутизатор не настроен на пропуск входящих соединений куда надо, то ничего
> ты не передашь.
Я какбы в курсе, но чел выше утверждал что можно послать что-то. Вот и интересуюсь принципом.

agentgoblin
> UDP, как и TCP, в этом случае не ходит вообще. Чтобы соединяться с кем-то за
> NAT, требуется на маршрутизаторе указывать, кому слать входящий трафик.

Ошибаетесь. Можно соединиться. И этим часто пользуются.

Как это работает: когда вы шлете что-то из-за NATа по UDP, вам выделяется на время внешний порт на роутере, который связывается с внутренним портом на вашем компе. На этот порт вам могут слать все что угодно. Связка портов держится некоторое время после того, как ей последний раз воспользовались. В зависимости от настроек роутера, от 20 минут, до 4х часов.
Однако, можно так настроить роутер, чтобы он запоминал, куда была первая передача, и принимал встречные посылки только из этого адреса. По умолчанию они обычно настроены так, чтобы принимать из любых адресов.

Zab
Получил внешний адресс + порт со STUN-сервера, но сначала с Port Restricted Cone, если второй раз посылать запрос на сервер, то уже Full Cone.
Но соединиться с этим клиентом, другим клиентом так и не могу. Хотя сервер STUN и дальше нормально оправляет ответы:
При 1 запросе:
PublicEndPoint: 93.84.56.84:65210
NetType: PortRestrictedCone

При последующих:
PublicEndPoint: 93.84.56.84:65210
NetType: FullCone

В чём может быть проблема?

И ещё возник вопрос:
Кто-нибудь пробывал напрямую соединяться через IPv6 при условии, что провайдер не поддерживает этот протокол?)
Интересная статья http://habrahabr.ru/post/207562/ для преобразования ip6 в ip4.
Но было бы лучше узнать подводные камни от людей, которые уже это проходили.
Интересно было бы узнать решения проблемы.

Возможные проблемы:
1. Не забиндили порт перед тем, как делать первую посылку по UDP. Биндить не обязательно для отсылки, но принимать сквозь NAT тогда не получится через этот же порт.
2. Связь идет по TCP. stun-серверу пофиг через что связь, он просто запоминает адреса и порты. Но в случае TCP пробитый порт всегда занят, нет никакого смысла пытаться соединиться с ним сквозь NAT.
3. Роутер может быть так настроен, чтобы принимать встречный поток только из одного адреса.

Zab
> Можно соединиться. И этим часто пользуются.
>
> Как это работает: когда вы шлете что-то из-за NATа по UDP
Я выше писал об этом. Обычно это работает, если только одна сторона за NAT. Можно выслать что-то из-за NAT и пока на файрволе открыт порт, слать туда, за NAT что угодно.

Вопрос в другом: у вас оба клиента за NAT. Куда должен послать пакет первый клиент, инициирующий соединение? На второго клиента? Как второй клиент узнает, какой порт открылся извне на первом клиенте? И уверены ли вы на 100%, что для клиента будет выделен снаружи заведомо какой-то известный порт, если мы полагаемся на это? В случае одного ПК за NAT можно считать (с оговорками), что снаружи откроется тот же порт с тем же номером, что и на ПК за NAT. Если же у вас более одного ПК за NAT, то на файрволе откроется что угодно. Как второй клиент будет узнавать, что там открылось, не используя промежуточных серверов?

Заметьте, я говорю не о том, что отправлять пакеты невозможно, я говорю именно о моменте инициации соединения - как два ПК за разным NAT узнают друг о друге без вспомогательных серверов?

agentgoblin
> Как второй клиент узнает, какой порт открылся извне на первом клиенте?
Как раз для этого есть stun-сервера или специализированные игровые сервисы типа battle.net.
Первый клиент связывается со stun-сервером, тот фиксирует его пробитый, внешний адрес и порт. Второй клиент, через stun-сервер же, узнает этот порт и инициирует p2p соединение.

Zab
STUN пробивает нат для клиента. Ему покласть на остальных. Он не регистрирует заявки, он ничего не фиксирует. Он всего-лишь пробивает порт и сообщает реальный адрес тому-же серверу, с которого пришел запрос на пробитие, после чего благополучно все забывает. Я че-то протупил этот момент.
St1G
Забей на всю эту ерунду и сделай свой мастер сервер, который будет запоминать пробитые порты для адреса, а затем либо реинвайты кидать, либо гонять траффик через себя. Либо унификация портов, которые кстати могут быть заняты какой-нибудь другой дрянью. Все остальные варианты будут работать без гарантий.

Похоже я себе не очень хорошо представлял что такое stun-сервер... Он действительно не коллекционирует адреса, и не сообщает их никому, помимо инициировавшего соединение. Но тогда нафиг он нужен? А он и не нужен, и не используется почти нигде...

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

Если stun сообщает что у вас статус FullCone, это значит что все отлично, он проверил что ваш NAT так настроен, что может принимать посылки из многих адресов.

St1G
> Кто-нибудь пробывал напрямую соединяться через IPv6 при условии, что провайдер не поддерживает этот протокол?)
Я не только пробовал но и работаю в том числе по IPv6. Всё просто отлично.

Туннели IPv6 принципиально ничем не отличаются от VPN  с частным диапазоном, кроме прямой доступности снаружи. Все так же нужен VPN сервер с диапазоном, который будет раздавать адреса. Либо пинками заставляйте всех клиентов переходить на dom.ru. Они IPv6 раздают. По запросу. Только все равно надо настраивать DHCP, чтобы он раздавал IPv6 из выданного диапазона.

Zab
> Как раз для этого есть stun-сервера или специализированные игровые сервисы типа
> battle.net.
Т.е. мы пришли к тому, что всё-таки требуется какой-то промежуточный сервис, где один клиент сможет узнать адрес и порт другого клиента.

> Похоже я себе не очень хорошо представлял что такое stun-сервер... Он
> действительно не коллекционирует адреса, и не сообщает их никому, помимо
> инициировавшего соединение.
> Но тогда нафиг он нужен? А он и не нужен, и не используется почти нигде...

Dampire
> Либо унификация портов, которые кстати могут быть заняты какой-нибудь другой
> дрянью.
Увы, тоже без гарантий. Во-первых, могут быть заняты и тогда откроется какой угодно порт. Во-вторых, на некоторых реализациях NAT, даже если снаружи нужный порт свободен, то открывается не тот же порт, что и внутри, а какой-нибудь посторонний.

Вообще пробитие NAT, которое будет универсальным и при этом 100% корректным - это нетривиальная задача из-за зоопарка реализаций и настроек этого самого NAT. Всякий софт, который славится своими обходами NAT, как правило использует комбинации разных методов и точно активно использует всякие внешние сервисы (тот же Skype, непример).

вот есть тулза которая по заявлению автора пробивает все типы натов, вроде она же может проксировать tcp трафик между двумя клиентами за натами
http://samy.pl/pwnat/
там есть объяснение как она работает
насколько я помню оба киента шлют сначала ping на какой-то несуществующий адрес, а потом друг другу. о том как они узнают друг о друге я не помню, возможно эту инфу нужно передать по другим каналам

Pushkoff
> возможно эту инфу нужно передать по другим каналам
This. Там даже в примере команд указано, что на клиенте требуется задавать IP-адрес сервера для работы всего этого. Сервер запускается просто так, а клиенту надо сказать, мол, сервер на таком-то ойпи. И если ты используешь порт, отличный от 2222, то и его надо указать.

Цитата дня:
A: Will this work behind my corporate NAT and firewall?
Q: This will work behind many NATs and firewalls, but not all.
(Работает через многие типы NAT и файрволов, но не со всеми)