Пробиваем дыры в NAT

По-моему вот с ними я связывался — спрашивал разрешения на публикацию перевода на Хабр. Очень понравилась статья, и описанную практику я повторил успешно (частично). Но они отказали

Спасибо большое за ссылку! После её прочтения данная статья воспринимается как потраченное время. Причем ещё и с противоречием, где я абсолютно согласен с выводом Tailscale:

Incidentally, this is why we said in the introduction that, if you want to implement this yourself, the NAT traversal logic and your main protocol have to share a network socket. Each socket gets a different mapping on the NAT device, so in order to discover your public ip:port, you have to send and receive STUN packets from the socket that you intend to use for communication, otherwise you’ll get a useless answer.

Так как меня следующее объяснение очень подталкивает к мысли "несколько сокетов = несколько локальных портов", соответсвенно разных квинтуплетов

В отличие от UDP, которому требуется лишь один сокет для коммуникации с S и любым количеством пиров одновременно, с использованием TCP каждому клиенту требуется несколько сокетов, привязанных к одному порту, как показано на рис.7. Каждому клиенту нужен сокет, для соединения с S, сокет, для входящих попыток соединения и два сокета для исходящих попыток соединиться с публичным и локальным эндпоинтами пира.

А вот оказывается почему:

Unfortunately things get confusing because there are two different definitions of socket out there. The TCP rfc uses the term socket to refer to a combination of address and port, but berkerly sockets and it's derivatives (the API used by pretty much every practical implementation of IP in use today) uses the term socket to refer to a type of operating system communications object.

ngrok

UDP socket в окружении любого ЯП)