Путаница с сервером оглушения

Вы не опубликовали результаты своего stunclient запуска, но я думаю, что они выглядели примерно так:

$ stunclient --mode full --localport 9999 stun.stunprotocol.org
Binding test: success
Local address: 192.168.1.8:9999
Mapped address: 1.2.3.4:9999
Behavior test: success
Nat behavior: Endpoint Independent Mapping
Filtering test: success
Nat filtering: Address and Port Dependent Filtering

Я предполагаю, что ваш поведенческий тест «независим от конечной точки», а тест фильтрации был «зависим от адреса и порта», поскольку они наиболее распространены в домашних условиях и в основном совпадают с тем, что вы описали выше. (иначе как «NAT с ограничением портов»).

В любом случае это означает, что вы создали сопоставление портов между собой и сервером STUN. В приведенном выше примере мой общедоступный IP-адрес — 1.2.3.4. И часто, но не всегда, мой локальный порт (9999) совпадает с публичным портом.

Внутри ваш NAT хранит логическую таблицу, например следующую:

------------------------------------------------------------------------------------
||     LOCAL IP    | LOCAL PORT ||  EXT PORT    ||   REMOTE IP      | REMOTE PORT ||
||================================================================================||
||   192.168.1.8   | 9999       ||  9999        ||  107.23.150.92   | 3478        ||
------------------------------------------------------------------------------------

Поскольку вы отправили пакет с порта 9999 на stun-сервер (107.23.150.92), NAT на несколько минут создает в своей таблице запись сопоставления портов. Когда пакет поступает на NAT/маршрутизатор из Интернета, он сверяется с таблицей. Когда ответ пришел с IP-порта сервера STUN, NAT смог перенаправить его на ваш компьютер за NAT на основе «удаленных» полей в таблице выше.

Но между вами и «другой общедоступной машиной», с которой вы надеетесь получать данные, нет сопоставления портов. Предположим, что IP-адрес этой другой машины — 2.4.6.8, и она пытается отправить данные со своего локального порта 8888. В таблице NAT по-прежнему нет ничего, что могло бы сопоставить трафик с 2.4.6.8:8888 с хостом позади. НАТ. Таким образом, когда трафик поступает в NAT от хоста, не включенного в таблицу, NAT знает только, что пакет нужно отбросить. Существует классификация NAT, известная как «Cone NAT», где это может работать, но они не так распространены.

В вашем случае есть простой обходной путь. После получения сопоставления портов с сервера STUN отправьте другую дейтаграмму с того же локального порта (9999) на удаленный хост (и удаленный порт), с которого вы хотите получать данные. Удаленный хост может просто проигнорировать эту дейтаграмму, но фактически создает другую запись сопоставления портов в вашем NAT.

------------------------------------------------------------------------------------
||     LOCAL IP    | LOCAL PORT ||  EXT PORT    ||   REMOTE IP      | REMOTE PORT ||
||================================================================================||
||   192.168.1.8   | 9999       ||  9999        ||  107.23.150.92   | 3478        ||
||   192.168.1.8   | 9999       ||  9999        ||  2.4.6.8         | 8888        ||
------------------------------------------------------------------------------------

Этот простой 1-байтовый пакет данных на адрес 2.4.6.8:8888 позволяет NAT перенаправлять трафик обратно с этого адреса на ваш хост за NAT.

Другими словами, используя собственную номенклатуру сетевых потоков:

My machine:9999 ---->[STUN BINDING REQUEST]--->stun server:3478

My machine:9999 <----[STUN BINDING RESPONSE mapped IP:port]<--- stun server:3478

My machine:9999 [Open socket on port 9999]

My machine:9999 ---->[1 byte datagram] -------> 'other:8888'

My machine:9999 <---- [UDP to public IP:port obtained in step 2]<----'other:8888'

Как правило, в обычном потоке P2P обе конечные точки работают с сервером STUN для обнаружения своего сопоставления портов. А затем используйте другой сервис для обмена информацией IP:port между собой. Из того, что вы описываете, вы вручную обмениваетесь этими значениями между своими программами, что подходит для тестирования.

Если другая машина находится в общедоступном Интернете, вам технически не нужен STUN. Первая машина (за NAT) может просто отправить прямо на удаленный IP-адрес и порт, чтобы сказать «отправьте мне некоторые данные». Удаленная сторона просто проверяет одноранговый адрес и порт этого сообщения, чтобы решить, куда отправить обратно. Сопоставление портов уже создано. Некоторые клиенты RTSP предполагают, что сервер является общедоступным.

Мой ответ по основам обхода NAT сокетов находится здесь.

Я случайно знаю разработчика STUNTMAN. Он довольно приятный парень, красивый и очень умный. Они также говорят, что мы с ним похожи друг на друга и наши имена пишутся почти одинаково. Вы всегда можете написать ему напрямую, если у вас есть вопросы о STUN и обходе NAT.