NET_ADMIN2 つの Docker コンテナ (機能付き)を備えたホストがあります。
backendインターフェースeth0（172.16.7.3）付きopenvpn-serverインターフェースeth0（172.16.7.2）とtun0（10.8.0.1）を備え、OpenVPNサーバー（tunモード）を実行
openvpn-clientインターフェースtun0( ) を持つ別のマシンに OpenVPN クライアントがあります10.8.0.2。VPN は動作しています。
追加ルートの設定:
backendルート10.8.0.0/24 via 172.16.7.2とがあります224.0.0.0/4 via eth0。openvpn-serverルート10.8.0.0/24 dev tun0とがあります224.0.0.0/4 dev tun0。
backend正常に ping できますopenvpn-client( を経由してルーティングされますopenvpn-server):ping 10.8.0.2問題なく動作します。
観察:
ping -t3 239.1.2.3で を実行するとopenvpn-server、それらは VPN トンネルを通過し、ICMP パケットが に到着するのを確認できますopenvpn-client(tcpdump -i tun0 net 224.0.0.0/4ではopenvpn-client)。
また、ping -t3 239.1.2.3で を実行するとbackend、 はそのホストから出てeth0、 に入りますopenvpn-server。を使用するeth0と、 でそれらを確認できます。openvpn-servertcpdump -i eth0 net 224.0.0.0/4
問題：
ping -t3 239.1.2.3を で実行しbackend、ping が に転送されるopenvpn-clientようにしたいと考えています10.8.0.2(最終的な目標は、 からbackendすべての VPN クライアントに UDP パケットをマルチキャストすることです)。
私の試み:
smcroute -d -n -j eth0 239.1.2.3 -a eth0 172.16.7.3 239.1.2.3 tun0
これでマルチキャスト ルートが設定されると思いましたが、実際には何も行われません。 の送信 ICMP パケットを確認できませんopenvpn-server。tun0-- 何が問題なのでしょうか?
pimdまた、3つのホストのうち2組、および3つすべてで設定してみました。その結果、iperfベンチマークを行うことができました（提案どおり）。ここ) はbackendとの間openvpn-server、およびopenvpn-serverとの間にもありますopenvpn-clientが、backendと の間にはありませんopenvpn-client。中間のホップを介した転送/ルーティングが何らかの理由で機能していないようです。(TTL を 5 に設定していたので、これは問題ではないはずです。)
必要であれば、より詳細な情報（出力などip route list）を提供できますが、質問を不必要に混乱させたくありませんでした。
答え1
問題は、 がマルチキャスト グループに参加していることを確認しなかったopenvpn-clientため、中間のルータ ( openvpn-server) がそこにマルチキャスト トラフィックを送信する必要があることを認識できなかったことです。
次の設定で十分です。
- で
backend、ルートを設定します224.0.0.0/4 via 172.16.7.2。これにより、マルチキャスト IP 範囲のトラフィックが確実に送信されますopenvpn-server(より狭い範囲を指定することもできます)。 - インストールして
pimd起動openvpn-server openvpn-clientマルチキャスト グループに参加する意思があることを通知していることを確認します。そのためには、次のような IGMP デーモンがscmroute必要です。これは 2 つのステップだけで動作します。smcroute -d-- デーモンを起動するsmcroute -j tun0 239.1.2.3-- グループに参加する
1 つのコマンドで両方を実行することはできないことに注意してください (
smcroute -d -j tun0 ...)。
こうすることで、すべてが期待どおりに動作します。
注記：OpenVPN が構成される前にpimdまたはデーモンを起動すると、動作しません。OpenVPN のフックを使用して起動するのが最適です。smcroutetun0route-up