Владимир Дубровин

OpenVPN (по умолчанию), wireguard используют UDP. Можно использовать либо просто VPN с роутингом трафика через него, либо любой VPN-протокол для точка-точка шифрования + SOCKSv5 прокси

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

С одной стороны, ваш провайдер прав - в любом случае при раборе через NAT/PAT необходимо настроить TCP KEEPALIVE, он настраивается в любом ssh-клиенте, например https://songhuiming.github.io/pages/2019/02/28/how... и это единственный гарантированный способ решения вашей проблемы.

С другой стороны, 240 секунд очень маленький таймаут (обычно используется время порядка 10 минут для UDP и порядка часа для TCP) а TCP KEEPALIVE умеют слать не все клиенты, поэтому стоит продолжить ругаться с техподдержкой чтобы таймаут или размер таблицы или диапазон NAT-портов увеличили дo разумных значений.

Используйте вместо SSH-туннеля VPN (например OpenVPN) со статическим назначением IP по пользователям. Конечный ресурс так же подключайте через VPN туннель.
Это
- быстрее
- на уровне VPN можно ограничивать пользователя по IP
- на уровне конечного ресурса можно разграничить по IP которые назначает VPN (т.е. фактически по пользователям).

для каждой пары ip:port клиента открывать отдельный слушающий сокет (на отдельном порту) в сторону сервера.

Можно, вызвав bind() для сокета и указав порт в структуре sockaddr_in.

int sock;
unsigned short port = 666;
struct sockaddr_in sin;

sock = socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP)
memset(&sin, 0, sizeof(sin));
sin.sin_family = AF_INET;
sin.sin_port = htons(port);
bind(sock,(struct sockaddr *)&sin, sizeof(sin));

P.S. не заметил PHP в тегах, но принцип тот же.
php.net/manual/en/function.socket-bind.php
указываете ненулевой порт.

Посмотрите
netstat -na | find "27500"
возможно у вас уже открыт порт из-под другого юзера?

https://msdn.microsoft.com/en-us/library/windows/d...

MSG_WAITALL не поддерживается на datagram-сокетах.

На уровне сети (IP) и транспорта (UDP, TCP) pid не передается. Процесс, которому предназначем полученные данные транспортного уровня, определяется по принадлежащему ему слушающему сокету, который определяется IP адресом, протоколом и портом.

При двойном туннелировании обязательно надо учитывать MTU и понижать MTU на вложенном туннеле. Для TCP проблема MTU более критична, т.к. обычно в TCP ставится флаг don't fragment. Если при этом у вас блокируются пакеты ICMP need frag, то вы получаете классическу проблему black hole.

Отследить маршрут UDP пакета на хост:порт 1.2.3.4:500 можно с помощью команды
traceroute -U -p 500 1.2.3.4

"Kernel bypass" может относиться к двум достаточно разным подходам: использование специальных ASIC на которые перекладывается задача обработки пакетов, например фильтрация или маршрутизация, или технологии, когда обработка сетевых пакетов полностью выносится в userspace. В любом случае, помимо аппаратной поддержки и/или специализированного оборудования, требуется поддержка технологии внутри приложения, причем во втором случае очень существенная, вплоть до реализации собственного стека TCP/IP, потому что все это идет мимо системного стека. Т.е. вы должны понимать, что вы будете получать "канальный" трафик, и работать примерно как через pcap-библиотеки.

UDP имеет смысл использовать в таких случаях:
1. На сервер будет отправлен единственный запрос и будет получен единственный ответ, который уберется в один пакет (передать данные проще чем установить TCP-соединение)
2. Идет поток данных в реальном времени, при этом в случае потери или задержки сетевого пакета, лучше вообще потерять эти данные чем заново отправлять (TCP соединение будет только мешать)
3. Планируются мультикастные реализации для этого протокола (TCP в принципе не годится)

Во всех остальных случаях лучше использовать TCP