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

Question

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

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

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

Answer 1

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

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

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

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