UDP Hole Punching невозможно с NAT с плохим поведением?

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

Единственный способ сделать традиционное перфорирование UDP - это угадать удаленную конечную точку. Однако, поскольку существует более 65 000 портов, этот метод не очень надежен. Итак, я читал, что такие приложения, как Skype, которые, как известно, способны обмениваться данными практически через любой тип NAT, используют для этого ретранслятор. Вот мои вопросы:

Реле - это просто сокет, который передает входящие данные из одного сокета в другой, верно? Существуют ли другие способы сделать дырокол UDP по непослушным NAT, не прибегая к диким догадкам или не используя реле (что больше не является «дыроколом»)?

Неверный термин NAT с неправильным поведением - любое устройство NAT, использующее PAT (преобразование адресов портов) для объединения нескольких частных адресов в один общий адрес, будет повторно сопоставлять исходные порты. Это то, что «Адрес порта» относится к PAT.

Было бы невозможно, чтобы два внутренних устройства использовали один и тот же адрес источника в одном и том же месте назначения и ожидали, что порт источника останется неизменным после NAT, и это не принесет пользы безопасности, когда попытается сохранить согласованность порта источника при нацеливании. несколько направлений. Так что, как правило, это не та цель, которую имеют брандмауэры в своей конструкции.

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

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