У меня есть настройка многоадресной маршрутизации с пересылкой на принимающей стороне, как показано ниже (все Linux):
+----------------+ +----------------+ +-------------+
| openvpn-server |tun0 tun0| openvpn-client | forward port 53 | application |
| 10.8.0.1 |============| 10.8.0.2 |-------------------| 172.16.3.3 |
+----------------+ +----------------+ +-------------+
joined 239.1.2.3
multicast group
В этой настройке openvpn-server
Сторона отправляет пакеты UDP в группу многоадресной рассылки 239.1.2.3 на порт 53. В частности, пакеты являются сообщениями DNS NOTIFY, но я не думаю, что это имеет значение здесь. (Есть несколько примеров openvpn-client
вот почему используется многоадресная передача.)
openvpn-client
затем перенаправляет трафик на application
. Этот хост подтверждает получение пакета, отвечая другим пакетом UDP.
Пакет ответа отправляется обратно openvpn-client
где Linux переводит исходный IP-адрес обратно в целевой IP-адрес исходного пакета, когда он поступал. от openvpn-server (при условии, что исходный пункт назначения теперь будет отправителем ответа), т.е. 239.1.2.3. Это проблема: Из-за этого IP-адреса источника пакет не передается исходному отправителю первого пакета, и отправитель думает, что пакет не был передан. Это приводит к нескольким ненужным повторным попыткам и большому количеству журналов.
В вопрос если можно проинструктировать openvpn-client
к перепишите исходный адрес ответа на 10.8.0.2
вместо. В частности, я хотел бы, чтобы это был адрес, связанный с интерфейсом tun0
, чтобы все оставалось в порядке на случай, если повторное подключение VPN приведет к смене IP-адреса.
Я подозреваю, что это возможно, потому что iptables MASQUERADE делает то же самое (но для соединений, происходящих из application
). Кроме того, я считаю, что если я настрою это, ответный пакет будет доставлен. Это возможно?
Я заметил, что когда я пингуюсь от 10.8.0.1 до 239.1.2.3, эхо-пакет исходит от 10.8.0.2 (а не от 239.1.2.3). (Обратите внимание, что случай ping не включает переадресацию портов.) Как я могу добиться того же поведения для моего случая UDP?