16.3. 代理 ARP を用いた擬似ブリッジ

単に擬似ブリッジを実装したいだけでしたら、 数節飛ばして「実装する」まで進んでください。 しかし実際の動作に関して少々読んでおくのは、 賢いことだと思います。

擬似ブリッジは少々違った動作をします。 ブリッジでは、デフォルトだとパケットは変更されずに、 あるインターフェースから別のインターフェースへと渡ります。 ブリッジが見るのはパケットのハードウェアアドレスだけで、 それで行き先を決めます。 これはつまり、Linux が理解できないトラフィックであっても、 ハードウェアアドレスを持っていさえすればブリッジできるわけです。

「擬似ブリッジ」は異なる動作をし、 ブリッジというよりは見えないルータに近いのですが、 しかしブリッジと同様、ネットワークの設計にはほとんど影響を与えません。

実際にはブリッジではない、ということの利点は、 パケットが実際にカーネルを通り、 したがってフィルタ・修正・リダイレクト・経路変更などができる、 というところにあります。

実際のブリッジにもこれらの機能を持たせることはできますが、 イーサネットフレームダイバータのような特殊なコードが必要だったり、 あるいは前述したようなパッチが必要です。

擬似ブリッジのもうひとつの利点は、理解しないパケットは通さないことです。 よって汚物まみれのネットワークを掃除できるのです。 このような汚物 (SAP パケットとか Netbeui とか) が必要な場合は、 本物のブリッジを使ってください。

16.3.1. ARP と代理 ARP

あるホストが、同じ物理ネットワークセグメントに存在する 別のホストと通信したくなると、 そのホストはアドレス解決プロトコルのパケットを送ります。これは簡単にいうと、 「誰が 10.0.0.1 を持ってるか 10.0.0.7 に教えてくれ」というようなものです。 これに対する反応として、10.0.0.1 は「ここだよ」という短いパケットを返します。

すると 10.0.0.7 は、「ここだよ」パケットが示すハードウェアアドレスへと パケットを送ります。またこのハードウェアアドレスは比較的長い間キャッシュされ、 キャッシュの期限が切れると、再び質問が発せられます。

擬似ブリッジを作るときは、ブリッジに対してこのような ARP パケットに返信するよう命じるのです。 よってネットワークのホストは、その後のパケットをこのブリッジに対して送信します。 するとブリッジはこれらのパケットを処理し、 適切なインターフェースへと送るのです。

つまり、簡単にいえば、ブリッジの一方にあるホストが、 逆側にあるホストのハードウェアアドレスを尋ねると、 ブリッジが「俺に渡せ」というパケットで答えるのです。

このようにして、すべてのデータトラフィックは正しい場所に配達され、 常にブリッジを経由するのです。

16.3.2. 実装する

以前あまり状況の良くなかった頃は、Linux カーネルに「代理 ARP」 の動作をするよう命令できるのは、あるサブネットに対してだけでした。 よって擬似ブリッジを設定するには、 ブリッジの両側に両方への正しい経路を指定して、 代理 ARP のマッチングルールを作る必要がありました。 これには大量の入力が必要で、また間違いも起こりやすく、 ブリッジが経路を知らないネットワークへの ARP 要求に応答することも起こりがちでした。

Linux 2.4/2.5 (おそらくは 2.2 も) では、この機能はなくなり、 /proc ディレクトリの 'proxy_arp' というフラグが取って代わりました。 よって擬似ブリッジを構築する手続きは次のようになります:

  1. 両側のインターフェース (ここでは 'left' と 'right' とします) に IP アドレスを割り当てる

  2. 経路を作り、left 側にどのホストがあり、 right 側にどのホストがあるのか、わかるようにする。

  3. echo 1 > /proc/sys/net/ipv4/conf/ethL/proxy_arp, echo 1 > /proc/sys/net/ipv4/conf/ethR/proxy_arp, によって両インターフェースの代理 ARP を有効にする。 ただし L と R は left 側、right 側各インターフェースの番号

また、ip_forwarding フラグを ON にするのも忘れないように! 本物のブリッジにはこのフラグは必要ないため、 移行してきたときにはこのフラグは OFF になっているかもしれません。

もうひとつ移行の際に注意しなければならないのは、 ネットワークの各コンピュータの ARP キャッシュをクリアしなければならない、 ということです。ARP キャッシュには、 前の古いブリッジのハードウェアアドレスが残っている (そしてそれはもう正しくない) でしょうから。

Cisco では、これは 'clear arp-cache' コマンドで実行できます。 Linux では 'arp -d ip.address' です。 キャッシュが期限切れになるのを待っていても良いですが、 これは比較的時間がかかります。

これを高速化するには、素晴らしいツール 'arping' が使えます。 これは多くのディストリビューションで 'iputils' パッケージに入っています。 arping を用いると、要求のなかった (unsolicited な) ARP メッセージを送りつけることができ、 リモートの ARP キャッシュを更新できます。

これは非常に強力なテクニックで、悪者がルーティングを崩壊させるのにも使えます!

Note: Linux 2.4 では、この「要求のなかった ARP メッセージ」を送信する前には、 'echo 1 > /proc/sys/net/ipv4/ip_nonlocal_bind' を実行する必要があるかもしれません。

また、ネットマスクを省略して経路を指定するクセのある (あった) 人は、 作業の結果ネットワーク設定が壊れてしまうかもしれません。 特定のバージョンの route はネットマスクを正しく推量していたかもしれませんし、 何も表示することなく間違っていたかもしれません。 前述したような外科手術的なルーティングをするときには、 ネットマスクをチェックするのは「生死」に関わります。