UDP Hole Punching на мобильных клиентах (Symmetric NAT vs Symmetric NAT)

Возьми готовую библиотеку или подсмотри как там сделано. Вот (github.com), например. Есть сложнее, есть проще. Hole punch — это базовая концепция. Там по ссылкам есть RFC, описывающие Stun — то самое, что ты на самом деле хочешь сделать.

Я б такое делал только в учебных целях, а для прода брал библиотеки, ибо долго и сложно.

Я реализовывал для P2P игрушки. Помню что там 2 из 3 типов ната можно пробить. Там в первом случае отсылаешь прям на тот же порт присланный с третьей стороны. Во втором инкрементируешь ++ – и пытаешься найти(главное что бы провайдер на забанил). Третий случай помойму вообще для разных айпи разный ЮДП порт входа = в этом случае impossible.

чому невозможно?

т.е. работоспосбонсть будет формата «повезет-не повезет» :)
хреново. игрался как то со своим провайдером - не повезло. либо читал не то :)

вообще просто интересно както можно загодя узнать пробьется конкретный пров али нет ??

Когда я про это первый раз услышал, для меня было удивительно что оно вообще может работать. В моём понимании сессии должны открываться для строго определённого набора local_ip_port+external_ip_port+remote_ip_port при отправке local->remote. Именно так делают все наты для tcp, насколько я знаю. Зачем для udp многие сделали другую логику с игнорированием удалённого адреса, я так и не понял.

можно сказать, что если после 3-5 инкрементов_порта коннекта не происходит, то значит у тебя третий вариант. Ещё что важно сказать, что допустим есть два хоста HOST1, HOST2, и если у первого хоста «хороший» НАТ, а у второго «плохой» то коннект возможен от второго к первому. В целом когда это проверял 70% раз работало. Поправте меня гуру сетей, если неправ.

Просто TCP connection-ориентированный протокол, а UDP как бы начал слушать и принимай от кого хочешь. Но опять же некоторые ISP, реализуют именно ту логику, которую ты описал.

Потому что некоторые ISP так настраивают NAT. ты можешь для начала вообще без STUN делать. Просто базовый код на питоне набросать, арендовать VPS и там захостить третий хост(без которого, как ты понимаешь hole_gaching не возможен). Суть кода в том что бы в echo ответе отдавать ip+port. А потом уже с P2P хостов пытаться на эти полученные данные что то отправлять. STUN по сути это и делает, только более формализованно в виде протокола с RFC.

Для libp2p есть реализации на java и swift

Вроде нет такого.

https://libp2p.io/implementations/

https://github.com/swift-libp2p/swift-libp2p

https://github.com/libp2p/jvm-libp2p

реализация на swift, правда, отмечена как экспериментальная и давно не обновлялась.

Ну ты сам-то прочитал свою ссылку? Где ты там отрыл jvm и swift?

Так-то было спрошено про SymmNat vs SymmNat

Взялся за расчет.

0. Взял мобильный МТС

1. Уточнил характеристики NAT ExpireTime == 240 sec, MaxNumberTranslations ~ 2000, random ports - checked

2. Вбил данные в калькулятор https://www.wolframcloud.com/obj/9bc318d0-0d27-4131-9d0f-4fc894179b3d (Модификация парадокса дней рождений) Число портов: (2^16 - 1024) / 2 (откинуты well-known и взята половина четных или нечетных (хоть что-то согласно RFC))

Результат: 180 шагов за 12 часов для подброса монетки (1/2). (Если нужно поднять шансы до 2 девяток - 7x, 3 девяток - 10x, 4 девяток - 14x)

Чего не хватает: не хватает количества трансляшек или меньшего таймера. Увеличение числа трансляшек в 2 раза дает буст в 4 раза (2000 - 180 steps, 4000 - 45 steps, 8000 - 11 steps). Таймер просто прямо пропорционален затраченному времени.

Расчет выше (и калькулятор) верен для FullRandom NAT и 2 симметричных по параметрам nat клиентов.

На мобильном ростелекоме (теле2?) таймер в районе 10 минут, число трансляций около 1000, соблюдается четность. Первый четный порт мапится в 0xXX00, а первый нечетный порт мапится в 0xYY01 (Те выделяется сразу блок из 256). Второй четный порт в XX02, второй нечетный в YY03. Т.е. set уменьшен в 256 раз и ВСЛЕПУЮ коннект устанавливается за 1 шаг, а с информацией о блоках от посредника еще и ненужно расходовать сотни трансляций.

Теперь снова про МТС. Один и тот же sport мапится в тот же sport для разных dport.

Это соблюдение требования REQ-1 из RFC4787 (а также REQ-4 и др.) + pseudorandom function over port (RFC7768)

У рт аналогично соблюдение REQ-1 из RFC4787 (а также REQ-4 и др.) + contiguous block ports (RFC7768)

Итого: нат на двух мобильных операторах должен легко пробиваться олдовым stun.