NAT трансляция не работает изнутри сети (состояние шпильки) - PullRequest
4 голосов
/ 18 мая 2011

Я пишу приложение P2P. Узлы регулярно пропингуют главный сервер, чтобы обновить свой текущий IP / порт, поэтому, когда узел хочет связаться с другим, он может запросить у сервера эту информацию. На данный момент одноранговые узлы используют UPnP для настройки NAT (для классических домашних установок), чтобы они были доступны извне.

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

Пока я думаю о двух решениях:

  • запрос NAT с помощью UPnP, чтобы увидеть, на какой локальный IP-адрес перенаправляется порт
  • хранить на главном сервере внутренние IP-адреса пиров

Можете ли вы придумать другие решения? Какие стратегии используют основные P2P-приложения для решения этой проблемы?

Ответы [ 2 ]

6 голосов
/ 19 мая 2011

Так как в этом случае клиент пытается достичь своего «внешнего» (общедоступный) IP-адрес из-за NAT, NAT не делает порт переадресации и не может направить пакет IP.

Это известно как состояние шпильки. Не все маршрутизаторы / NAT решают это правильно. Решения:

a) Проверьте, можно ли настроить роутер / NAT для включения «заколки волос». Это решение работает, если вы контролируете все маршрутизаторы / NAT в своем развертывании.

б) Купите другой маршрутизатор / узел, разрешающий это. Как и а), он работает, если вы контролируете все маршрутизаторы / NAT в вашем развертывании.

в) Если вы можете получить информацию о порте для UPnP, это тоже решение, но не все маршрутизаторы / NAT знают или поддерживают UPnP. Он не распространяется на все случаи большого развертывания.

d) Использование многоадресной рассылки для «обнаружения» других узлов в локальной сети и даже для связи с ними является распространенным решением этой проблемы. Вам нужно согласовать IP-адрес и попросить его прослушать его.

e) Хранение частного IP-адреса на сервере также является решением, но для него требуется больше места на сервере, чем для решения d. Существует также тайм-аут (то есть истечение срока действия данных) для обработки.

f) Использовать TURN-подобную связь между одноранговыми узлами (т.е. связь между узлами проходит через центральный сервер). Это решение является надежным, но не самым эффективным с точки зрения потребления полосы пропускания.

Надеюсь, это поможет.

0 голосов
/ 27 апреля 2017

Система интерактивного подключения (ICE) была специально разработана для решения проблем NAT такого типа.Он использует STUN и TURN для достижения результата и используется в современных приложениях p2p.(например, Voicechat)

Библиотека PJNATH имеет документ , объясняющий

, в отличие от автономного решения STUN, она (ICE) решает проблему закрепления, поскольку она также предлагаетпринимающие кандидаты.

...