ルートテーブルの影響を受けたLinuxブリッジネットワーク

0

私はLinuxブリッジについて実験をしていました、そして私のネットワークトポロジーは以下のようです

ご覧のとおり、LANにはHost1（10.74.68.58）とHost2（10.74.68.47）の2つのホストがあります。 Host1に、ブリッジを作成しました br0 それにIPを割り当てました（192.168.3.101）。それから私は取り付けました eth0 橋へ：

[root@10.74.68.58:~] # bridge link
2: eth0 state UP : <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 master br0 state forwarding priority 32 cost 2

デフォルトルートを次のように設定します。 br0 そしてそれは大丈夫です ping 10.74.68.47：

[root@10.74.68.58:~] # ip r
default dev br0  scope link
172.17.0.0/16 dev docker0  proto kernel  scope link  src 172.17.42.1
192.168.3.0/24 dev br0  proto kernel  scope link  src 192.168.3.101

しかし、物事は説明できなくなった デフォルトルートをに設定したとき eth0 ：

[root@10.74.68.58:~] # ip r
default dev eth0  scope link
172.17.0.0/16 dev docker0  proto kernel  scope link  src 172.17.42.1
192.168.3.0/24 dev br0  proto kernel  scope link  src 192.168.3.101

いつ eth0 これはデフォルトのルートインタフェースで、2つの異なる方法でhost2にpingを送信します。

1、 ping 10.74.68.47

失敗しました。 tcpdumpファイル（インターフェイスbr0でキャプチャ）を確認したところ、br0がARP応答しか受信しないことがわかりました。そのため、インターフェースeth0にはARP情報がないため、host2のmacを取得できません。 これは正しい行動だと思います、私の理解は正しいですか？

2、それから私は試した ping -I br0 10.74.68.47

デフォルトの経路を避けるために-Iオプションを使用したいのですが、失敗しました。 tcpdumpファイル（インターフェイスbr0でキャプチャ）を確認したところ、次のファイルが見つかりました。 icmpエコー要求とエコー応答パケットのペアがすでにあります。 これは私をとても混乱させた。 br0がエコー応答を受け取ったので、なぜhost2に正常にpingできないのですか？

[root@10.74.68.58:~] # ping -I br0 10.74.68.47
2 packets transmitted, 0 received, 100% packet loss, time 1006ms

皆さん、教えてください。

— ruanhao
ソース

3

ブリッジは、あなたがそれが機能すると思うようには機能しません。 :-)

橋はただ関係している OSI レベル2（イーサネットフレーム）このレベルでは、IPアドレスなどは存在しません。概念的には、ブリッジはイーサネットインターフェースの集まりと考えることができます。各インターフェイスはポートと呼ばれ、1つのポートに入るパケットは他のすべてのポートに出ます。（実際には、Linuxの実装では、見られたMACアドレスのテーブルを保持する最適化がありますが、概念的には、それは問題ではありません）。

そのため、ブリッジはいくつかのイーサネットセグメントを1つの大きなセグメントに接続（「ブリッジ」）できます。

それでは、「LinuxブリッジにIPアドレスを割り当てる」とはどういう意味ですか？ Linuxの実装では、ブリッジは別のハードウェアデバイスではなく（元々存在していたように）、ホスト自体からもアクセス可能です。つまり、多くのポートを持つ一種の「スーパーイーサネットインターフェース」のように動作しますが、カーネルに入ったり、このカーネルから出たり入ったりするパケットは、 どれか これらのポートのうちの1つは単一のIPアドレスでLinux OSに到達します。

イーサネットインターフェースをブリッジのスレーブ（ポート）にするとすぐに、それはそれ自身のアドレスを持つことをやめます。重要なのは、ブリッジのIPアドレスだけです。

言い換えれば、単一のポートだけでブリッジを作っても意味がありません（あなたはそれ自身でインターフェースを使ったかもしれません）。パケットをブリッジのポートにルーティングしようとしても意味がありません（カーネルに関する限り、ブリッジは単一のデバイスです）。

もしあなたが橋で遊びたいのなら、このような構造が必要です。

  10.0.2.1/23    10.0.2.2/23    10.0.3.254/23     10.0.3.1/23    10.0.3.2/23 

  ............   ............   ...............   ............   ............
  .  Host A  .   .  Host B  .   .  Host X     .   .  Host C  .   .  Host D  .
  .          .   .          .   . <-- br0 --> .   .          .   .          .
  .   eth0   .   .   eth0   .   . eth0   eth1 .   .   eth0   .   .   eth0   .
  .....|......   .....|......   ...|......|....   .....|......   .....|......
       |              |            |      |            |              |      
  -----+--------------+------------+      +------------+--------------+------

  <-------- left Segment  --------->      <------- right Segment ----------->

ここで、ホストAとBの左側のセグメントはホストXによってホストCとDの右側のセグメントにブリッジされており、各ホストは単一のIPアドレス（インターフェイスまたはブリッジ全体に割り当てられている）によってアクセス可能です。

— dirkt
ソース

ご指導ありがとうございました。あなたの言うとおり、私のここでのトポロジーはLinuxブリッジの正しいやり方ではありません。ブリッジが存在するときにパケットがどのように流れるかを調べるために、この奇妙なトポロジを設定しました。しかし、Linuxカーネルに関する資料をいくつか読んだ後、私の質問は 'rp_filter'オプションと関係があることがわかりました。これは非常に奇妙なトポロジですが、 'rp_filter'機能をテストするための実験環境になる可能性があります:)

— ruanhao

私の知る限り、 rp_filter これは「リバースパスフィルタリング」であり、レベル2（イーサネットフレーム、ブリッジング）ではなくレベル3（IPパケット、ルーティング）で機能するので、接続があるとは思いません。 Linuxカーネルのルーティングをテストしたい場合は、ブリッジではなくルーターとして設定する必要があります。

— dirkt

1

ありがとうございました！これは素晴らしい答えです。ネットワークブリッジングについて誤解していたことをいくつか解決しました。

— gcarvelli

-1

あなたが ping -I br0 10.74.68.47、 Protocol stack ip（10.74.68.47）はbr0と同じLANにはないので、eth0を通してARPを送信します。しかし、eth0はbr0をアタッチし、プロトコルスタックを接続することはできません、eth0はbr0にARP応答を送信します、そしてbr0はmacが一致しないのでfind、それをドロップします。そのため、プロトコルスタックはARP応答を取得しません。
br0のipを10.74.68.x / 24に変更できます。大丈夫でしょう。

— Panpan Zhang
ソース