我有一個在接收端轉發的多播路由設置，如下（所有 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。 （有幾個例子openvpn-client就是使用多播的原因。）
openvpn-client然後將流量轉送到application.該主機透過回覆另一個 UDP 封包來確認收到封包。
回應包被傳送回openvpn-client哪裡Linux 將來源 IP 轉換回初始封包傳入的目標 IP 位址來自 openvpn-server（假設原始目的地現在是回應的發送者），即 239.1.2.3。這就是問題：由於這個來源 IP，資料包不會傳輸到第一個資料包的原始發送者，並且發送者認為該資料包沒有被傳輸。這會導致多次不必要的重試和大量日誌。
這問題是否可以openvpn-client指示將回應的來源位址重寫10.8.0.2為。更具體地說，我希望它是與 interface 關聯的位址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 案例實現相同的行為？