我有一个在接收端转发的多播路由设置，如下所示（所有 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 数据包发送到端口 53 上的多播组 239.1.2.3。具体来说，这些数据包是 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 ping 到 239.1.2.3 时，回显数据包源自 10.8.0.2（而不是来自 239.1.2.3）。（请注意，ping 情况不涉及端口转发。）如何才能使我的 UDP 情况实现相同的行为？