Это плохая идея, посылать пакеты веером сразу на 1000 портов. У NAT'ов вполне конечный размер таблиц, и когда таблица переполняется, может быть все, что угодно — вплоть до зависания роутера. Роутеры "за 50 баксов из ближайшего компьютерного супермаркета" особенно этим страдают, а большинство роутеров именно такие.
R>ну отлично, только без статей статей это всего лишь слова
Никакого почёта нету в том, чтобы пробивать наты имея пару ассистентов снаружи.
Это умели делать и в 2003-2004 годах, причём все, кто не глупее обезьяны.
Важно чтобы топикстартер допёр до сути проблемы и вариаций таковой.
ну да, поэтому дураки придумали TURN
а гугл вообще глупый, вместо того что бы STUN раздавать, мог бы более двух асcистентов раздавать а не жлобиться на TURN
и все бы были в шоколаде вместо того что бы плясать сейчас вокруг webrtc+stun+turn
да и людей я не понимаю которые сначала подсвечивают слова на то что это возможно только в теории
а потом говорят что они это на практике уже сто лет в обед делали
тс-у наверное вообще все это пофиг, он лабу делает, что бы его в сетевики взяли
Здравствуйте, reversecode, Вы писали:
R>ну да, поэтому дураки придумали TURN R>а гугл вообще глупый, вместо того что бы STUN раздавать, мог бы более двух асcистентов раздавать а не жлобиться на TURN R>и все бы были в шоколаде вместо того что бы плясать сейчас вокруг webrtc+stun+turn
С webrtc та проблема, что он является стандартом. А значит, в нем все ходы должны быть расписаны, и он должен опираться на другие стандарты в вопросах, которые не делает сам. Вот он и опирается на stun, turn и ice (еще одно модное слово, которое ты забыл упомянуть).
В реальности, чтобы пробить конический NAT, хватает 2 RTT, потому что получение своего внешнего адреса и передачу пиру приглашения установить соединение можно объединить в один пакет, и еще один RTT понадобится, чтобы подтвердить соединение и взаимно авторизоваться. Со STUN'ом 2 RTT понадобится только на изучение своего NAT'а (да еще и с ужасными 10-секундными ожиданиями пакетов, которые тебе нафиг на самом деле не нужны), еще пару RTT понадобится, чтобы просигналить пиру и обменяться ICE'ными кандидатами, еще примерно столько же, чтобы проверить этих кандидатов, и только потом можно делать взаимную авторизацию. Т.е., если RTT занимает порядка 200 мс, получаем 5 секунд вместо полсекунды на установление соединения в хорошую погоду — телефонисты оценят разницу.
Здравствуйте, Qulac, Вы писали:
Q>Да ни чего особенного, соединить один ком с другим через интернет. Проблема в том, что у меня только один комп для тестирования, в этом случае мне лучше положиться на какую ни будь библиотеку или использовать стандартные настройки для этого. Вот не знаю, вот эта настройка решит мои проблемы или нет?
Сетевый проблемы лучше решать отдельно от кода приложения.
Если нельзя настроить port mapping на входящем раутере, то лучше решать кардинально по-другому.
Конкретно, для надежной связи желательно настроить NAT-free внутреннюю VPN сеть. Это исходящее VPN от PC за NAT (любого их количества) и внешний сервер, который держит VPN сервер и обеспечивает routing.
Это называется hub & spoke, hub это центральный VPS, spoke — это клиенты
Здравствуйте, Vetal_ca, Вы писали:
V_>Конкретно, для надежной связи желательно настроить NAT-free внутреннюю VPN сеть. Это исходящее VPN от PC за NAT (любого их количества) и внешний сервер, который держит VPN сервер и обеспечивает routing.
Небось, если бы создатели скайпа так рассуждали, фиг бы их купил за бешеные бапки е-бай, а после микрософт.
Здравствуйте, Qulac, Вы писали:
Q>Да ни чего особенного, соединить один ком с другим через интернет. Проблема в том, что у меня только один комп для тестирования, в этом случае мне лучше положиться на какую ни будь библиотеку или использовать стандартные настройки для этого. Вот не знаю, вот эта настройка решит мои проблемы или нет?
Если только оди из них за натом, то можно попробовать через SOCKS прокси
Q>Просветите плиз в чем собственно проблема, т.е. если я за nat-ом подыму tcp сервер и передам клиентам его внешний(за nat-ом) ip, то они не смогут к нему подключиться? Или нет?
Если роутер с NATом умеет в UPNP, то прежде чем долбиться в UDP как выше писали, можно попытаться примерно так
Кстати, умеющие в UPNP роутеры обычно позволяют это умение включить/выключить в своих настройках.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, Слава, Вы писали:
С>Надеюсь, когда-нибудь внедрение IPv6 прикончит всё это безобразие.
Да хоть IPv9000 — ничто не запрещает сегментировать сети. И нормальные люди будут использовать это сегментирование, как для удобной себе организации сети, так и для уменьшения доступной для атаки поверхности.
Здравствуйте, Pzz, Вы писали:
Pzz>Это плохая идея, посылать пакеты веером сразу на 1000 портов. У NAT'ов вполне конечный размер таблиц, и когда таблица переполняется, может быть все, что угодно — вплоть до зависания роутера. Роутеры "за 50 баксов из ближайшего компьютерного супермаркета" особенно этим страдают, а большинство роутеров именно такие.
А железки противоположного ценового сегмента задетектят это как потенциальную атаку и забанят этот веерный IP.
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, Vetal_ca, Вы писали:
V_>>Конкретно, для надежной связи желательно настроить NAT-free внутреннюю VPN сеть. Это исходящее VPN от PC за NAT (любого их количества) и внешний сервер, который держит VPN сервер и обеспечивает routing.
Pzz>Небось, если бы создатели скайпа так рассуждали, фиг бы их купил за бешеные бапки е-бай, а после микрософт.
Скайп вполне себе юзает NAT-PMP, и правильно делает. И только если ничего не помогает, тогда уже начинает тупой foreach по диапазону портов (у меня старый DLink в итоге вешался от такого, в логах инкременты портов видны на ура).
