0xFF

С UDP принципиально сложнее. Для того, чтобы понять, для какого из узлов за транслятором предназначен пришедший из Интернет пакет, транслятор должен или использовать статическое перенаправление по номеру порта UDP (что легко сделать в NAT своего домашнего маршрутизаторе и нельзя в NAT оператора связи), или сначала отследить инициирование того или иного протокола узлом сети, находящимся за транслятором адресов. Учитывая, что сам протокол UDP не подразумевает наличия "сессии" как у TCP, задача не решаемая.

Особо умный NAT провайдера, может анализировать протокол приложения, например, SIP, FTP в пассивном режиме и прочие. Но он может не иметь понятия о протоколах ваших приложений, если они не совпадают со стандартными.

Например, я видел (и конфигурировал) устройство, которое для передачи одного большого потока информации, использовало десятки честных соединений SIP, имитируя телефонный вызов, ответ на него и продолжающийся разговор. Такое мимикрирование под известный протокол, позволяет пакетам UDP успешно проходить через NATы к их внутренним хостам. Имейте ввиду, что в некоторых случаях, например, в случае протокола SIP, NAT может произвольно поменять внешний номер порта пакета от внутреннего узла, меняя номер порта, в том числе, и в сообщениях SIP.

Так что ключевое значение для прохождения пакетов UDP через NAT ко внутреннему клиенту, имеет поддержка NAT'ом протокола приложения верхнего уровня. К сожалению, далеко не все протоколы поддерживаются или корректно распознаются. Например, я не могу инициировать из-за NAT'а сессию протокола OpenVPN между портами UDP 1194. Ответные пакеты UDP ко мне просто не проходят NAT'а мобильного оператора связи. В то же время, замена протокола транспортного уровня на TCP, позволяет успешно и долго работать, так как от NAT уже не требуется анализ протокола уровня приложения. В протоколе TCP уже содержится вся необходимая информация для успешной трансляции адресов и маршрутизации. Но и тут важно помнить, что внешние порты могут отличаться от используемых узлом, находящимся за транслятором. Поэтому приложение узла в Интернет, должно корректно обработать пакеты TCP, использующие не тот номер порта, который фактически используется узлом за NAT. Используйте другие способы проверки пакета, нежели проверку номера порта источника и назначения. И принимайте пакеты, в том числе, и с тех портов, которые не могли быть инициированы узлом за транслятором, так как транслятор мог поменять номера портов.