LinuxブリッジとローカルIPルールを理解しようとしています。
Linuxラップトップに次のトポロジがあります。
br0
___________|__________
| |
|tap0 tap1|
|________Application_______|
上記のアプリケーションは、2つのタップインターフェイスtap0とtap1を作成しています。
ブリッジを作成し、タップインターフェイスをブリッジに接続します。
brctl addif br0 tap0
brctl addif br0 tap1
Pingを機能させるには、インターフェイスにIPアドレスを追加する必要があるため、192.168.13.1 to tap0
と192.168.13.2 to tap1
を追加します
アプリケーションは、両方のインターフェースについて、1つのインターフェースから読み取り、別のインターフェースに書き込みます。
「ping 192.168.13.2 -I tap0」を実行すると
PING 192.168.13.2 (192.168.13.2) from 192.168.13.1 tap0: 56(84) bytes of data.
From 192.168.13.1 icmp_seq=1 Destination Host Unreachable
tcpdumpがarpを解決できないことを示していたため、静的ARPエントリを追加しました。
arp -i tap0 -s 192.168.13.1 62:34:58:e7:8a:3a
arp -i tap1 -s 192.168.13.2 4a:6d:fa:51:7d:2d
brctl showmacs br0
port no mac addr is local? ageing timer
2 4a:6d:fa:51:7d:2d yes 0.00
2 4a:6d:fa:51:7d:2d yes 0.00
1 62:34:58:e7:8a:3a yes 0.00
1 62:34:58:e7:8a:3a yes 0.00
ブリッジもMACアドレスを学習したようです。
ただし、アプリケーションとtcpdumpは引き続きARPパケットがまだ解決されていないことを示す42バイトのパケットを受信し、pingを実行するとホストに到達できないというメッセージが表示されます。
私の現在のルーティングテーブルは:
ip route ls table main
169.254.0.0/16 dev virbr0 scope link metric 1000 linkdown
192.168.13.0/24 dev tap1 proto kernel scope link src 192.168.13.2
192.168.13.0/24 dev tap0 proto kernel scope link src 192.168.13.1
192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 linkdown
私の現在のローカルルーティングテーブル:
broadcast 192.168.13.0 dev tap1 proto kernel scope link src 192.168.13.2
broadcast 192.168.13.0 dev tap0 proto kernel scope link src 192.168.13.1
local 192.168.13.1 dev tap0 proto kernel scope Host src 192.168.13.1
local 192.168.13.2 dev tap1 proto kernel scope Host src 192.168.13.2
broadcast 192.168.13.255 dev tap1 proto kernel scope link src 192.168.13.2
broadcast 192.168.13.255 dev tap0 proto kernel scope link src 192.168.13.1
ルーティングはここでは考えられないかもしれません。これはレイヤー2のブロードキャストドメインであるためです。しかし、私はLinuxブリッジングに精通していないため、続行するにはいくつかのアドバイスが必要です。
Tap0とTap1の間でpingを機能させるにはどうすればよいですか。
ありがとうNayan
tun/tap interfaces の役割と使用法を理解していないと思いますが、それが問題の原因です。説明させてください。
tap0インターフェースを、2つの側面を持つ仮想ワイヤの終わりと見なします。可視側:tap0、および非可視側アプリケーションのワイヤー:この非表示の側は、アプリケーションによって完全に処理される必要があります。アプリケーションは、ファイル記述子で読み取ったデータペイロードとしてイーサネットフレームを受信します。必要に応じて、このデータをイーサネットとして(タップモードであるため)、ARPまたはIPとしてデコードし、必要なイベントに反応します。簡単に言うと、アプリケーションはpingに応答するためにTCP/IPネットワークスタックを必要とします。
Tun/tapデバイスを使用するそのようなアプリケーションの例は openvpn またはQEMU + VM + OSの組み合わせです(QEMUは、このデータペイロードをこのドライバーと同じ方法でVMのOSのネットワークデバイスドライバーに提供するためのものです)実際のネットワークデバイスから表示されます)。
tap0とtap1をブリッジにスレーブ化すると、それらはブリッジポートになります。これはヒントですIPを受信してはなりません(24ポートスイッチの各ポートにIPを割り当てることは理にかなっていますか?):これらのIPは、ホスト:scope localを持つルートがlocalルーティングテーブルに追加されます。これらのIPをloループバックインターフェイスに追加すると、同じ結果が得られます。これ以外に、それらで動作するルートはありません インターフェース ブリッジポート、今重要なのはそのマスターbr0です。
あなたがすべきことは、ブリッジ自体にIPを追加することです(ルートはbr0インターフェースを使用します)、または代わりにvethペアにして、一方の側をブリッジにスレーブ化し、もう一方の側にIPを追加します。ルートは、vethインターフェースを使用し、そのIPを使用します(ブリッジを離れます)よりクリーンなIPhoなし)。
残りの部分はすべて、アプリケーションに依存します。ICMPエコー要求に応答する前に、それらの192.168.13.1および192.168.13.2 IP自体を最初にARP要求に応答することも含めて処理する必要があります。
アプリケーションの役割がtun/tapインターフェースを作成することだけではないことに気付いた場合は、アプリケーションとtun/tapインターフェースの使用を忘れてください:use network namespaces これは、ネットワークスタックと同じ数だけ複製します必要に応じて、必要に応じてブリッジを作成し、それらの名前空間全体に veth インターフェイスを作成します。 ip netns
および ip link
add ... type veth ...
ですべてテストできます。
bridgeおよびvethインターフェースをネットワーク名前空間と使用するチュートリアルの最初の3つの部分へのリンクをいくつか示しますip netns
は使用しない方が簡単です)。
名前のないLinuxネットワーク名前空間でvethデバイス、Linuxブリッジ、VLANをお楽しみください– [〜#〜] i [〜#〜][〜#〜] ii [〜#〜][〜#〜] iii [〜#〜]