У меня настроена многоадресная маршрутизация с пересылкой на принимающей стороне следующим образом (все 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 пакет не передается первоначальному отправителю первого пакета, и отправитель думает, что пакет не был передан. Это приводит к нескольким ненужным повторным попыткам и большому количеству логов.
Theвопросесли возможно openvpn-clientпоручитьПерепишите исходный адрес ответа 10.8.0.2на. Точнее, я бы хотел, чтобы это был адрес, связанный с интерфейсом tun0, чтобы все оставалось в порядке в случае, если повторное подключение VPN приведет к изменению IP-адреса.
Я подозреваю, что это возможно, потому что iptables MASQUERADE делает то же самое (но для соединений, исходящих из application). Кроме того, я полагаю, что если я это настрою, ответный пакет будет доставлен. Возможно ли это?
Я заметил, что когда я отправляю ping с 10.8.0.1 на 239.1.2.3, эхо-пакет отправляется с 10.8.0.2 (а не с 239.1.2.3). (Обратите внимание, что случай ping не подразумевает переадресацию портов.) Как мне добиться того же поведения для моего случая UDP?