Как перенаправить весь трафик, поступающий на данный порт, на другой порт?

Как мне перенаправить весь трафик, поступающий на данный порт, на другой порт?

Определите схему и проблему

Схема

Вот схема того, что я пытаюсь сделать...

+--------+         +---------------------+         +----------------+
|  WAN   |  <--->  | 6789                |         |                |
| Client |         |       Gateway       |         |      Host      |
|        |         |                4567 |  <--->  |  2345 Service  |
+--------+         +---------------------+         +----------------+

Я хочу прозрачно перенаправить весь трафик, поступающий на порт 6789, на порт 4567. Клиент в WAN и служба на хосте ничего не должны знать о шлюзе.

Шлюз - Debian 10 с firewalld.

Проблема

Я не могу заставить трафик, поступающий на порт 6789 на шлюзе, перенаправляться на порт 4567.

Текущая настройка

Шаг 01 - Открыть порт на брандмауэре и подтвердить, что порт открыт.

Откройте порт на шлюзе

1. Выполните команду firewall-cmd: firewall-cmd --add-port=6789

2. Проверьте состояние брандмауэра...

root@gateway:~# firewall-cmd --list-all
public (active)
  target: default
  icmp-block-inversion: no
  interfaces: etho0
  sources: 
  services: dhcpv6-client http https ssh
  ports: 6789/tcp
  protocols: 
  masquerade: yes
  forward-ports: 
  source-ports: 
  icmp-blocks: 
  rich rules:

3. Убедитесь, что порт открыт.

• На шлюзе запустите слушателя: nc -vvlp 6789 &
• Убедитесь, что слушатель запущен...

root@gateway:~# netstat -tulnp | grep 6789
tcp        0      0 0.0.0.0:6789              0.0.0.0:*               LISTEN      2274/nc

• С клиента попытайтесь связаться со шлюзом:

client@client123:~$ nc -vvN gateway.example.org 6789
Connection to gateway.example.org 6789 port [tcp/*] succeeded!

Заключение: Порт 6789 открыт на брандмауэре.

Очистите систему, убив процесс nc на клиенте и шлюзе.

Шаг 02 - Подтвердите соединение между шлюзом и службой на хосте

root@gateway:~# telnet localhost 4567
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 backendhost.backendhost MyService (Debian/GNU)

Заключение: Туннель между шлюзом и службой на хосте работает.

Шаг 03 - Добавляем проброс порта на шлюзе и проверяем состояние брандмауэра

root@gateway:~# firewall-cmd --add-forward-port=port=6789:proto=tcp:toport=4567`
root@gateway:~# firewall-cmd --list-all
public (active)
  target: default
  icmp-block-inversion: no
  interfaces: etho0
  sources: 
  services: dhcpv6-client ssh
  ports: 6789/tcp
  protocols: 
  masquerade: no
  forward-ports: port=6789:proto=tcp:toport=4567:toaddr=
  source-ports: 
  icmp-blocks: 
  rich rules: 

Вывод: Порт форвард находится в брандмауэре.

На данном этапе, если я попытаюсь подключиться к хосту по telnet с клиента, я получу...

client@client123:~$ telnet gateway.example.org 6789
Trying <IP_of_gateway>...
telnet: Unable to connect to remote host: Connection refused

На данном этапе я хочу увидеть то, что я видел в Шаге 02 выше.

Вопросы

Вот здесь я не уверен...

Когда я запускаю netstat -tulnp на шлюзе, он НЕ показывает ничего, прослушивающего порт 6789. Я и не ожидал этого, поскольку у меня нет ни одной запущенной службы, которая бы слушала порт 6789.

Нужна ли мне какая-то служба для прослушивания порта 6789? Если да, то какая? Или я что-то упускаю в настройках брандмауэра? Нужен ли мне какой-то прозрачный прокси, как упоминается здесь?

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

Edit

В ответ на @A.B

Хост работает за брандмауэром. Когда хост запускается, он автоматически создает туннель к шлюзу, используя SSH port forward.

Вот команда, которую хост выполняет при загрузке: ssh -N -R 4567:localhost:2345 tunnel@gateway.example.org

Этот туннель работает, что подтверждается в Шаге 02. И хотя я не упоминал об этом ранее, клиент работает, когда он находится в той же локальной сети, что и хост.

Я пытаюсь добиться того, чтобы трафик, поступающий на шлюз, успешно проходил на хост. Шлюз должен быть "прозрачным". Сертификат безопасности хранится на хосте, и клиент должен думать, что он разговаривает непосредственно с хостом.

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