Программирование игр, создание игрового движка, OpenGL, DirectX, физика, форум
GameDev.ru / Программирование / Форум / Не могу пробить NAT, UDP создает канал (4 стр)

Не могу пробить NAT, UDP создает канал (4 стр)

Страницы: 1 2 3 4 5 6 7 Следующая »
ZabПостоялецwww11 дек. 201722:27#45
25cm
Эта схема работает только если все NAT'ы находятся в режиме Full Cone.
В Restricted Cone облом, принимать клиент может лишь с того адреса, куда сам посылал, т.е. с сервера.
Впрочем, NAT'ы по умолчанию обычно Full Cone.
CoderInTankПостоялецwww12 дек. 20173:39#46
Все элементарно. 2 Клиента узнают адреса друг друга через сервер с белым ip. Один из клиентов отправляет на адрес второго клиента 65536 пакетов с портами назначения от 0 до 65535. Второй клиент отправляет на любой из портов первого клиента пакет. Первый клиент получает пакет от второго. Все, канал установлен. Не благодарите)
25cmПользовательwww13 дек. 20177:30#47
Zab
Читайте внимательно. Клиент принимает другого клиента без проблем, так как он ему сам послал на 8 этапе.
Согласно схеме работы любого NAT, даже самого злого port-restricted-cone, после 8 этапа клиентБ может достучаться до клиентаА.
Схема проверена и лично мне неизвестны случаи когда она не работает.
RammПостоялецwww13 дек. 20178:52#48
25cm
И там и тут ответили)
Самый злой NAT не пробьет по одной простой причине:
сервер имеет адрес клиента Б и клиента А, которые NAT для них выделил - это раз.
Эти адреса бесполезно отправлять другим.
Вот пример, может возникнуть такая ситуация: создаю сервер с двумя сокетами (белый IP), создаю клиента с одним сокетом, отправляю 2 пакета серверу, по 1 пакету на адрес сокета. Сокет 1 сервера определяет адрес отправителя как X_IP:32273, а сокет 2 как X_IP:32785.
У меня такая ситуация через раз возникает.

Я не пробовал, но если я решу связаться со вторым сервером через существующий сокет, даже с белым IP - я думаю, что NAT выделит другой порт. Т.е. посылая пакет клиенту Б, некоторые типы натов могут предоставить клиенту А новый порт. А в это время нат клиента Б может отсекать пакеты с неизвестного адреса:порта.

Если все расписать, то в случае с непробиваемым натом все может выглядеть так:
1. Клиент А отправляет серверу пакет, сервер определяет его адрес как IP1:20000;
2. Клиент Б отправляет серверу пакет, сервер определяет его адрес как IP2:25000;
3. Сервер отправляет клиенту А адрес IP2:25000, а клиенту Б адрес IP1:20000 (обмен адресами);
4. Клиент А пытается достучатся до клиента Б, отправляет пакеты на адрес IP2:25000, но NAT клиента А выделил для этого новый порт 26666.
5. NAT клиента Б не знает кто это лезет и режет все пакеты с IP1:26666 нахрен.
6. Клиент Б пытается достучатся до клиента А, отправляет пакеты на адрес IP1:20000, но NAT клиента Б выделил для этого новый порт 25001.
...
Т.е. клиенту Б надо стучаться на IP1:26666, а клиенту А на IP2:25001, но они этого не знают.

CoderInTank
> Все элементарно. 2 Клиента узнают адреса друг друга через сервер с белым ip.
> Один из клиентов отправляет на адрес второго клиента 65536 пакетов с портами
> назначения от 0 до 65535. Второй клиент отправляет на любой из портов первого
> клиента пакет. Первый клиент получает пакет от второго. Все, канал установлен.
> Не благодарите)
Отличная шутка, но NAT не зарезервирует за клиентом все 65 тысяч портов, скорее всего он этого клиента заблочит после первых 500 пакетов.

Есть еще варианты?

Вторая проблема, 2 ПК стоят за одним роутером и одним NAT-ом. Сервер получает из внешние адреса (они всегда одинаковые, они отличаются только портами), оба ПК узнают их...
Вопрос, как NAT провайдера справится с этим, ведь для него конечная точка одна - роутер, с его двух портов идут пакеты на внешний адрес...
Короче, это абсурд получается.
Ну вот например, моя локальная сеть устроена таким образом, что у роутера IP 192.168.0.1, а клиентам он выдает адреса 192.168.0.Х. Клиенты могут отправлять друг другу пакеты напрямую, по нужному адресу, но слать их на IP роутера бессмысленно.
Железо провайдера определит, что от него требуется в таком случае?

Правка: 13 дек. 2017 9:12

ZabПостоялецwww13 дек. 20178:59#49
Ramm
Схема от 25cm должна сработать для "самых злых NAT'ов". Когда отсылается пакет по адресу переданному сервером, он не дойдет, естественно, но нам и не надо, чтобы он доходил. Надо чтобы с отправляющей стороны нат в этот адрес был пробит, а он пробьется независимо от успешности или неуспешности доставки.
DampireУчастникwww13 дек. 20179:03#50
25cm
> Схема проверена и лично мне неизвестны случаи когда она не работает.
Symmetric NAT - Symmetric NAT
Port Restricted - Symmetric NAT
Ramm
> Я не пробовал, но если я решу связаться со вторым сервером через существующий
> сокет, даже с белым IP - я думаю, что NAT выделит другой порт.
Ты уже раздражать начинаешь. Ты думаешь? Или ты уверен? Почитай доки для начала.
Zab
> Схема от 25cm должна сработать для "самых злых NAT'ов".
Эту схему от 25cm я кинул на предыдущей еще странице. Она работает для большинства, но не для всех натов. Схемы панчинга, которая работает для всех натов просто не существует.

Правка: 13 дек. 2017 9:07

ZabПостоялецwww13 дек. 20179:27#51
Проблемы будут также, если udp-сообщения не сумеют уйти с локальной машины. Если они до nat'а не дойдут, то и пробит он не будет. А такое очень даже может быть.
Наблюдавшиеся мной случаи были в таких условиях: Локальная сеть плотненько загружается перекачкой большого архива. Сетевые буфера у винды все забиты и udp-сообщения не отправляются вовсе, выкидываются в момент отсылки. В сети они не появляются вообще. И это не фиксируется как сбой, сообщение считается отправленным, просто не дошло, имеет право, udp все таки. Наблюдалось давно, WinXP, сеть 10 мбит. Выкидываются вообще все посылки, пока сеть не прочухается, это может продолжаться хоть несколько часов.
RammПостоялецwww13 дек. 20179:33#52
Dampire
> Почитай доки для начала.
Блин, доки чего? Оборудования своего провайдера?
Dampire
> Ты думаешь? Или ты уверен?
Ну блин нет у меня нескольких серверов с белым адресом, ток один. Как мне еще это узнать?
При тестировании из локальной сети, я ни разу не добился прямого коннекта, панчинг не проходил, ничего не выходит...
Dampire
> Ты уже раздражать начинаешь.
Ну сорян, вы с Zab-ом ооочень сильно помогли разобраться в этой кухне, спасибо, но я, блин, насильно не держу никого и помогать не заставляю, там внизу справа кнопочка "Отписаться" должна быть, нажми, если я тебя раздражаю своими глупыми вопросами.
ZabПостоялецwww13 дек. 20179:45#53
Ramm
Вряд ли у тебя restricted nat. Сколько с сетями работал, ни разу таких не видел. Должны быть веские причины, чтобы админы так настроили, по умолчанию все работают в full cone.
На тот редкий случай, если у игрока restricted nat обнаружится, можно просто предусмотреть альтернативную доставку через свой сервер-посредник, вместо p2p.
Может быть даже для этого прокси можно как-то использовать.
RammПостоялецwww13 дек. 201710:06#54
Zab
Да, я это попробую реализовать. Ну не получится - хрен с ним, куча игр есть, в которых свой сервер создать непросто, ну и нужно чтобы сеть удовлетворяла ряду условий.
DampireУчастникwww13 дек. 201711:25#55
Ramm
Тебе я и 25см уже сказали КАК пробить твой нат. Но ты с непробиваемым упорством талдычишь про рандомный порт. Не надоело ещё ныть? Может стоит проверить на практике последовательность пробития порт-рестриктед ната? Я гарантирую, что у тебя именно он.
DampireУчастникwww13 дек. 201711:26#56
Zab
Да ёб твою мать. Пробивается порт рестриктед. Легко и непринужденно. Не пробивается только симметрик. Если ты не понимаешь техники пробития - воспринимай как магию.

Правка: 13 дек. 2017 11:33

ZabПостоялецwww13 дек. 201713:10#57
Dampire
Я давно все понял. И признал это.

Так случилось, что никогда не сталкивался с этим. Про рестриктед наты знаю теоретически.
Зачем кому-то выставлять такой режим? Паранойя у него?
Или пытаются внутреннюю сеть максимально изолировать? Тогда там не просто нат будет, там прокси так настроят, чтобы пускал только html-пакеты и почтой пользоваться не корпоративной запретят. В общем, не поиграешь из-за такого занавеса вообще, нечего и пытаться.

DampireУчастникwww13 дек. 201713:31#58
Ты на SOHO роутерах умеешь типы натов настраивать? Научишь может? Вот у меня NETGEAR с port-restricted nat. Помоги его на full cone перевести.
RammПостоялецwww13 дек. 201713:36#59
Dampire
>
> Тебе я и 25см уже сказали КАК пробить твой нат. Но ты с непробиваемым упорством
> талдычишь про рандомный порт. Не надоело ещё ныть? Может стоит проверить на
> практике последовательность пробития порт-рестриктед ната? Я гарантирую, что у
> тебя именно он.
Проверил на практике - взял виртуалку, взял мобильник, настроил сеть на виртуалке через телефон. Итак, оба отправляют пакеты на сервак, сервак показывает их адреса и порты, причем порт виртуалки (мобильный инет) распознался именно тот, который я биндил, а не рандомный или какой-либо другой. Затем, с виртуалки начинаю отправлять пакеты на полученный адрес компа, с компа - на виртуалку. Прямой контакт есть, пакеты доходят. Да, нат как-бы пробит. Причем на первом пакете может выбить исключение, при попытке отправить на мобилку пакет с моего ПК, типа "Удаленный хост принудительно разорвал существующее подключение", это если мобилка первая не кинет пакет.

Теперь повторяю то же самое с родным инетом виртуалки (и с другого ПК за роутером, результат все равно один) - сервер получает 2 пакета с двух ПК, пакеты отличаются только портами, затем ПК 1 отправляет на адрес и порт ПК2 пакеты, тот пытается отправить пакеты на адрес и порт ПК1 - толку НОЛЬ, прямого соединения нет!

Dampire
Еще вопросы про потестить? И не матерись на Zab-а!

Страницы: 1 2 3 4 5 6 7 Следующая »

/ Форум / Программирование игр / Сеть

2001—2018 © GameDev.ru — Разработка игр