ブリッジルーティングと火星パケット

ブリッジルーティングと火星パケット

ルーティングしようとしていましたが、単独では解決できない問題に直面しました。

                              eth0 
                                |
                                |
                                |
    ------------------------   br0   ------------------------ 
    |                    (192.168.100.1)                    |
    |                                                       |
    |                                                       |
    |                                                       |
lxc_vpn_eth0                                          lxc_test_eth0                                              
(192.168.100.120)                                     (192.168.100.130)
    |
    |
   tun0

lxcコンテナ(テスト)から別のlxcコンテナ(vpn)にいくつかのパケット(udp)を送信し、そこからそのコンテナ内で実行されているopenvpnを介して送信したいと思います。これまでは動作しますが、何とかカーネルタグによってmartianとfallで応答が提供されます。オフブリッジbr0

パケットが通過した3つの「場所」すべてでtcpdumpを使用してテストし、結果は次のとおりです。 (
VPNコンテナから) #tcpdump -i eth0
21:25:12.043321 IP 192.168.100.1.55081 > XX.YY.UU.VV.6969: UDP, length 16
21:25:12.097040 IP XX.YY.UU.VV.6969 > 192.168.100.1.55081: UDP, length 16

ご覧のとおり、私はtun0でパケットをなりすましています。

したがって、テストコンテナのパケットがVPNコンテナに到着し、ton0を通過して応答を取得しますが、この応答パケットがブリッジに配置されるとすぐに、カーネルログに次のものが表示されます。
kernel: [c0] IPv4: martian source 192.168.100.120 from XX.YY.UU.VV, on dev br0

では、応答パケットがドロップされないようにルーティングをどのように設定する必要がありますか? IP 192.168.100.120のコンテナがあるブリッジにはすでに存在し、待機する必要があります。

お手伝いいただきありがとうございます。 より多くの情報をお寄せいただきます。

ベストアンサー1

この質問をして申し訳ありません...

数時間のトラフィックスニッフィング、パケット追跡、および多くの試行錯誤の最後に、私はbr0でパケットをなりすましていることに気づきました。おそらくコンテナの場合、ハードウェアスイッチにeth0にある必要がある2台のマシンがあるため、これを行ったようです。ルーティングのため。とにかく、これはパケットに奇妙なsrcヘッダーをもたらしました...

トラフィックを偽装イーサネット0代わりにbr0、問題を解決できました。

おすすめ記事