Как перенаправить udp порт или туннель для него сделать?

Question

[historydev]

win11 pro, не server

Нужно всё что идёт на 0.0.0.0:port перенаправить на x.x.x.x:port.
- Гуглинг дал твёрдо понять, что штатными средствами этого не выйдет, но найти программу для этого не получается.

Что делать?

Comments

[Ziptar]

Скорее всего kerio умеет, но это из пушки по воробьям. Фаервол с нат нужен, крч.

[historydev]

Ziptar, нагуглил 3proxy какой-то: https://en.softcomputers.org/blog/how-to-port-forw...
https://3proxy.ru/

[historydev]

Ziptar, kerio control нужен, верно? Как понять из пушки? Можно небольшую инструкцию?

[Ziptar]

historydev, да. Хотя я его очень давно щупал, он тогда ещё kerio winroute назывался. Из всего инструментария там нужен src-nat, как бы он ни был реализован конкретно в керио под виндой. Только адрес интерфейса, через который трафик идет, придется статичный задать, маскарад не подойдет тут, даже если есть. Хотя от реализации зависит, под виндой нат может существенно различаться с линью.

нагуглил 3proxy какой-то

Наверное можно и с прокси... Попробовать так будет проще и быстрее, чем корячить сторонние фаерволы, во всяком случае. Для меня тут неочевидно как это правильно настроить, потому что на уровне винды весь трафик придется заворачивать на прокси, а уже на самом прокси фильтровать по порту, а остальной трафик пускать дальше своим путем. Но я вообще с прокси плохо знаком.

Как понять из пушки?

Громоздко. Всю сетевую инфраструктуру в винде под себя подомнет. Всякие проблемы с другим софтом, работающим с сетью, могут случиться.

[historydev]

Ziptar, а по другому никак? Чушь какая-то, почему для tcp всё есть, а для udp нет)

[Ziptar]

historydev, а что для tcp есть? С udp вообще всегда сложнее работать. Где-то его особенности (отсутствие состояний соединения, подтверждений доставки) скомпенсированы разными ухищрениями, где-то нет.

[historydev]

Ziptar,

netsh interface portproxy add v4tov4 listenport=<listen_port> listenaddress=<listen_address> connectport=<connect_port> connectaddress=<connect_address>

В каждой второй статье

[Ziptar]

historydev, мс, вероятно, посчитала, что не нужно, но я все равно не понимаю, как это помогло бы, если у самого прокси нет внутреннего функционала для фильтрации по порту. У тебя в условии обращение к любому адресу, для этого сначала весь трафик придется завернуть на прокси, а на самом прокси уже разруливать по порту, если у конкретного прокси есть такой функционал