Как работает UDP hole punching?

https://habr.com/ru/articles/509730/

Я ни разу не интересовался смыслом этого «термина», но могу предположить, что речь идёт о приёме входящих udp-подключений за натом. Если так, то скорее всего способ такой:

1) программа открывает udp-сокет (на своём сером айпи), шлёт с него пакет куда-то в интернет на известный сервер

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

3) сервер отвечает программе, присылает ей белый айпи:порт, с которого ему пришёл пакет

4) программа теперь знает, под каким айпи:портом виден её серый сокет в интернете, этот айпи:порт она сообщает ещё кому-то (пока что - опять через третий сервер, который есть в инете), чтобы тот мог к нему подключиться

5) пока через этот канал идёт регулярный обмен трафиком, наты его не забудут и всё будет работать, а после паузы придётся проводить операцию заново

На практике я это не проверял, но других способов придумать не могу.

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

В UDP тоже есть порт. Вот по порту и понимает.

Да, две программы один порт слушать не могут.

https://github.com/ValdikSS/nat-traversal-github-actions-openvpn-wireguard

Да, две программы один порт слушать не могут.

Могут, вообще говоря: https://www.man7.org/linux/man-pages/man7/socket.7.html#:~:text=so_reuseport%20(since%20linux%203.9)

SO_REUSEPORT (since Linux 3.9)

Permits multiple AF_INET or AF_INET6 sockets to be bound to an identical socket address. This option must be set on each socket (including the first socket) prior to calling bind(2) on the socket. To prevent port hijacking, all of the processes binding to the same address must have the same effective UID. This option can be employed with both TCP and UDP sockets.

For TCP sockets, this option allows accept(2) load distribution in a multi-threaded server to be improved by using a distinct listener socket for each thread. This provides improved load distribution as compared to traditional techniques such using a single accept(2)ing thread that distributes connections, or having multiple threads that compete to accept(2) from the same socket.

For UDP sockets, the use of this option can provide better distribution of incoming datagrams to multiple processes (or threads) as compared to the traditional technique of having multiple processes compete to receive datagrams on the same socket.

я уж думал что-то придумали интересное, а нет, для symmetric nat не работает.

ЕМНИП это немного о другом, точнее о том же самом в целом, только работающем по другому.