ルーティングしようとしていましたが、単独では解決できない問題に直面しました。
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、問題を解決できました。