次のように、受信側で転送を行うマルチキャスト ルーティングを設定しています (すべて 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
ポート 53 のマルチキャスト グループ 239.1.2.3 に UDP パケットを送信します。具体的には、パケットは 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 に ping すると、エコー パケットは 10.8.0.2 から発信され (239.1.2.3 からは発信されない) ことがわかりました。(ping の場合はポート転送は行われないことに注意してください。) UDP の場合に同じ動作を実現するにはどうすればよいでしょうか。