Proxy ARP mini-HOWTO Al Longyear, December 5, 1994 川島 浩, October 1, 1996 Proxy ARP の設定方法 注意: この文書はかなり以前に書かれたものなので、いまどきの Linux 環境 にはあてはまらない箇所があります。 (JF Project) 1. イントロダクション このドキュメントは Linux 上で PPP や SLIP サーバデバイスとともにプロク シ ARP (Address Resolution Protocol) を使おうと考えている人を対象にし て書かれています。他の文献では、プロクシ ARP を 「gracious ARP」 (愛想 のよい ARP)などと呼んでいることもあります。プロクシ ARP を使いたいとい う要求はよく出ます。これが使えない場合、ソフトウエアの不良だと考え、な ぜ使えなくなってしまったのだろう、といぶかる人達もいます。 このドキュメントが助けとなって、プロクシ ARP はどのようなときに有用 で、どのようなときには使わなくてもよいのかをよく理解してもらえるよう 願っています。 プロクシ ARP を使うと、「(プロクシ)サーバ」における経路テーブルさえ変 更すれば、他のシステムでは経路テーブルを変更する必要がありません。この ことは、リモートシステムの動的なネットワーク接続が可能になるということ を意味しています。 ここで、「サーバ」と呼んでいるのは、ある意味では誤りかもしれません。 TCP/IP は、ピアーツーピアー(対等)のネットワーク環境だからです。他のシ ステムでは、サーバーが資源を提供することで、「共有」され、クライアント はこれを「利用」しますが、TCP/IP には、この手のクライアント／サーバー 関係はありません。とはいえ、「電話を取るコンピュータ」をサーバと呼び、 「電話を架けるコンピュータ」をクライアントと呼ぶのは便利ですよね。 Linux のネットワークソフトは プロクシ ARP を直接サポートしていますの で、他のシステムで使われている proxyarpd のような特別なデーモンは必要 ありません。 PPP をサポートするコード（pppd）と、SLIP をサポートするコード（の少な くとも一つ、dip-uri）の両方が proxy ARP をサポートしているはずです。こ れに加え、ネットワーク用プログラム ARP も経路テーブルを管理し、表示す ることができるはずです。 プロクシ ARP がどのように動作し、どんな時に使われるのかを理解するため には、一般的にネットワークがどのように機能するのかについて基本的理解が 必要です。以下の3つの章では TCP/IP ネットワークがどのように機能し、 ルーティングがどういう風に動作するのか、を簡単に述べます。 2. ハードウエア側から見たネットワーク イーサネットやトークンリングを使ったネットワークはすべて MAC (Media Access Control) アドレスを使って実現されています。これはそれぞれのコン トローラーに割り当てられたハードウエアアドレスであり、それぞれの MAC アドレスは世界中で唯一(unique)のものです。これはコントローラーのメーカ が割り当てます。ソフトウエアによって変更することも可能ですが、一般的な 意味ではルール違反です。 IP アドレスは 「ARP キャッシュ」 と呼ばれる、ソフトウエア上の特別な テーブルによって MAC アドレスに変換されます。ネットワークソフトが、 IP パケットを指定されたアドレスに送る時には、MAC アドレスを知るためにこの キャッシュを検索します。キャッシュの中になかった場合には、 IP アドレス から MAC アドレスに変換するために、ネットワークに接続されているすべて のシステムに対して特殊な要求を発行します。これが ARP (Address Resolution Protocol)要求と呼ばれているものです。 ARP 要求に対しては それに対応する MAC アドレスが返されます。この MAC アドレスは、次には ARP を使わなくて済むように、キャッシュに蓄えられま す。 プロクシ ARP はこの仕組みを使って、リモート接続をうまく処理することが できるわけです。 キャッシュの中のエントリーを削除するルールもありますが、このドキュメン トではそれについては触れません。これに関しては IP ネットワークに関する ドキュメントを参照して下さい。 (トークンリングは開発中で、テストベースでは利用可能ですが、 Linux の一 般的なネットワーク媒体という意味ではやはりイーサネットです。ですからこ こから先、「イーサネット」という言葉を使います。同様の機能はトークンリ ングでも使えます。トークンリングのソースルーティングに関わりなく。) 3. III. プロクシ ARP を使う理由 目的は、ひとつのネットワークアダプタに対して、2つ以上の IP アドレスを 割り当てることにあります。 これは、イーサネットコントローラのハードウエアアドレスに対応した、追加 の IP アドレスのエントリーを ARP キャッシュに生成することで実現されま す。これによって、 IP アドレスをハードウエア (MAC) アドレスに変換する ARP 要求に対して Linux システムはうまく応答することができるわけです。 4. TCP/IP ルーティング [前もっておことわりしますが、ここでは、「スパンニング・ツリー (spanning-tree)」ルーティングについて述べており、IP パケットの「ソー ス・ルーティング(source-routing)」ではありません。トークンリングでは ソースルーティングが使われますが、これは IP のソースルーティングではな く、（トークンリングの）MAC 層で行われてるものです。トークンリングで MAC ソースルーティングを行っているのは、それがトークンリングによるパ ケットの配送に必要だからです。一般的には IP ソースルーティングを使う事 は推奨できません。] プロクシ ARP についてもっと詳しく知るためには、IP パケットがネットワー ク上でどのようにルーティングされるのかを知る必要がありますが、ここでは あまり詳しく述べるつもりはありません。詳しい情報を知りたい方には、深く 解説された、たくさんの本があります。 (本が嫌いでしたら、RFC ドキュメン トをお読みください。) IP パケットは、それが経由するネットワークのそれぞれの段階でルーティン グされます。それぞれのホスト、ルーター、ゲートウエイは、それぞれが経路 テーブル情報のコピーを所有し、それにもとづいてそれぞれの IP パケットを どこに送ればよいかを決定します。 ルーティングは、「IP ネットワーク」 を使って行なわれます。それぞれの ネットワークインターフェースには、ユニークな IP ネットワークと、IP ア ドレス、ネットマスクが割り当てられています。「IP ネットワーク」 とは、 単純にIP アドレスと ネットマスクのビットごとの積をとったものです。例え ば、IP アドレス 10.124.35.40 で、ネットマスクが 255.255.0.0 の場合に は、「IP ネットワーク」 は、 10.124.0.0 となります。この例ではバイト単 位のネットマスクを使っていますが、バイト単位ではないネットマスク(訳注: 例えばサブネッティングした時など)の場合でも同様です。 Linux はネットマスクを経路エントリーと関連づけます。システムに経路を付 け加える時 (訳注: route コマンドなど) には、そのIP アドレスと関連する 行き先のデバイスを指定しますが、この際にネットマスクを指定しなけれ ば、ifconfig でそのデバイスを設定したときに指定したデフォールトネット マスクが使われます。 ルーティングに関しての理解を助けるために、次のような構成のシステムを考 えてみましょう。 Destination Netmask Gateway Flags Device 10.124.0.0 255.255.0.0 0.0.0.0 U eth0 10.125.0.0 255.255.0.0 0.0.0.0 U eth1 10.126.0.0 255.255.0.0 10.125.31.1 UG eth1 10.124.12.5 255.255.255.255 0.0.0.0 UH ppp0 0.0.0.0 0.0.0.0 10.124.25.1 U eth0 このシステムは3つのネットワークデバイスを持っています。 2つはイーサ ネットコントローラで、1つは PPP デバイスです。これら3つのいずれからも IP パケットは到着し、さらにこのシステムを通じて、 3つのどのデバイスに 対してもパケットは転送されます。 デフォールトの経路は、上のエントリーで示されている通り、 10.124.25.1 のゲートウエイデバイスです。ゲートウエイに送るためには eth0 コントロー ラが使われます。 PPP デバイスが1つ接続されており、その IP アドレスは 10.124.12.5 です。 eth0 デバイスは IP ネットワーク 10.124.0.0 上にあり、eth1 デバイスは IP ネットワーク 10.125.0.0上にあります。 さらに、IP アドレス 10.125.31.1 のゲートウエイを通じて利用可能な IP ネットワーク 10.126.0.0 へのネット経路が存在します。 ルーティングがどのように行われるのかを理解するために、10.125.45.1 に送 られる IP パケットを考えてみましょう。 Linux は経路テーブルを検索し、それぞれのエントリからネットマスクを取り だし、ビットごとの積をとり、行き先の IP アドレスと比較します。合致した ら、パケットはそのデバイスに送られます。 結果として、IP アドレス 10.125.45.1 のパケットは、eth1 デバイスに送ら れます。 同様に、 IP アドレス 10.124.12.6 のパケットは eth0 デバイスに送られる のですが、IP アドレス 10.124.12.5 のパケットは ppp0 デバイスに送られま す。なぜなら、ppp0 デバイスは 10.124.12.5 というただひとつの IP アドレ スだけしか受け取ることができないからです。 10.126.31.4 宛のパケットの場合はちょっと異なります。この場合には、この アドレスに接続された「ゲートウエイ」が存在するからです。上で述べたよう なのと同じ方法で検索されますが、ただ単に eth1 デバイスに送られるのでは なく、10.125.31.1 という IP アドレスのシステムに送られるのです。つま り、最終的な行き先のアドレス 10.126.31.4 ではなく、ゲートウエイの IP アドレス (10.125.31.1) に対応する MAC アドレスに送られるわけです。 10.125.31.1 のシステムに到着したら、そのシステムの経路テーブルを使っ て、最終的な行き先の 10.126.31.4 に転送されます (たとえばそのシステム の eth3 インターフェースを使って)。 このようなルーティングでは、いろいろな誤りが発生し得ます。それについて はここではあまり触れたくありませんが、たとえば、 10.126.31.1 が 10.126.31.4 のアドレスに対する経路を持っていなかった場合、もともとの送 り元に対して、ICMP (Internet Control Message Protocol) パケットを送り 返し、「そのホストに対する経路が無い」ことを知らせます。 5. プロクシ ARP によるルーティング さて、基礎として必要な部分については説明が終わったので、このドキュメン トの目的の部分に移ることにしましょう。 プロクシ ARP を実行している Linux が、IP アドレスおよび対応するハード ウエア MAC アドレスのエントリを ARP キャッシュに格納することと、この キャッシュが IP アドレスを MAC アドレスに変換するのに使われるというこ とを思い出して下さい リモートシステムが IP アドレス 10.124.12.5 に接続するときに、Linux は この IP アドレスと、eth0 コントローラに対応する MAC アドレスを ARP キャッシュに格納します。 その後に IP アドレス 10.124.12.5 を MAC アドレスに変換する要求 (ARP) を受け取った場合、このテーブルから得たエントリーを要求元に返します。そ の結果、この IP アドレスに送られたパケットは、いったんこのサーバに送ら れ、サーバはそれをリモートシステム (10.124.12.5) に転送します。 これが プロクシ ARP の仕組みです。サーバは リモートな IP アドレスに対 する proxy (つまり、代理人、でしゃばり屋、「表向きの」人などなど) とし て機能するわけです。つまり、ARP 要求に応答することで、リモートな IP ア ドレスに対するパケットを受け付け、それらを転送するわけです。 ところで、プロクシ ARP がうまく動作するためには、リモートな IP アドレ ス (この例では 10.124.12.5) は、(訳注:サーバに接続されている) ネット ワークアダプタの IP ネットワークのうちの一つでなければなりません。 これには二つの理由があります。 一つ目の理由は、コントローラの MAC アドレスは、それに対応する IP アド レスの ARP キャッシュに格納されるからです。ARP キャッシュは、IP アドレ スから MAC アドレスへの変換テーブルなので、ARP 割り当て (assignment) をおこなうためには、MAC アドレスが必要です。 二番目の理由は、ネットワーク上のすべてのシステムは、それぞれ独自にルー ティングをおこなっているという点です。しかし、それぞれのシステムは少な くとも、リモートな IP アドレスに対して IP パケットを送るためには、「そ れと同じ線につながっている」サーバのネットワークアダプタに送らなければ ならないことはわかっています。 (校正者注:リモート 10.124.12.5 に対する Proxy ARP をあてがうインター フェースは、10.124.0.0 ネットワークに接続されている必要がある、という ことでしょう。ほかのネットワークにあるシステムが 10.124.12.5 にパケッ トを送る場合、とりあえず 10.124.0.0 のネットワークまで要求を送り付けて くるはずなので、インターフェースが 10.123.0.0 ネットワークなどにあって も、そもそも ARP 要求があったことがわかりませんから。（ARP 要求はネッ トワークに対するブロードキャストとして実行されるのではなかったかと思い ます。）) 6. プロクシ ARP がうまく動作しない場合 リモートの IP アドレスが、10.124.12.5 ではなくて、例えば 10.200.3.1 の 場合を考えてみましょう。 1. リモートシステムは、このアドレスをどこに送ったらいいかわからない。 リモートシステムがわかっているのは、IP ネットワーク 10.124.0.0 に送 るためには eth0 に接続されているケーブルにパケットを送ればいい、と いうことだけです。しかし、10.200.0.0 という IP ネットワークはありま せん。この宛先のパケットをどこへ送ればいいのかわからないわけです。 2. ARP エントリーを作成する時に、サーバは対応する MAC アドレスに対し て、どのコントローラを使えばよいのかわからない。 これは、プロクシ ARP を使おうとしてもうまく動作しない場合に、最もよ くあるケースです。宛先の IP アドレスが、自分に接続されているネット ワークインターフェースに割り当てられている、いずれの IP ネットワー クアドレスとも異なるという場合です。 7. プロクシ ARP の問題点と避けなければいけないこと 1. 特定の IP アドレスに対して応答する プロクシ ARP エントリーはただ一 つでなければなりません。BSD の場合、あるアドレス範囲に対して プロク シ ARP をおこなう場合にはそのアドレス範囲が衝突しないことを保証する 必要があります。これはつまり、BSD ベースのネットワークでは、ある ネットワーク全体をひとつのサーバに割り当てる必要があることを意味し ます。 もう一度強調しておきますが、もし ARP 要求に対して複数の応答を受け 取った場合、BSD システムでは相当ひどいことになります。 2. すでにネットワーク中に存在しているアドレスに対して、プロクシ ARP を 実行してはいけません。 これは、上で述べた問題のちょっとしたバリエーションです。ネットワー ク上にすでに存在するIP アドレスに対する プロクシ ARP を実行すると、 ２つの応答が生成されることになります。つまり、サーバーがリモートシ ステムとの接続にプロクシ ARP を適用する場合に、現在ネットワークで使 用中の IP アドレスをリモート接続に流用したりしてはいけない、という ことです。 (校正者注:本来の IP アドレスのマシンへのコネクションをサーバが横取 りして proxy ARP に使ってしまう、つまり本来のコネクションが成立しな くなる、ということではないかと思います。) 8. プロクシ ARP を使う事はできないが、同様の機能を実現したい場合に は？ あなたが プロクシ ARP を使えない場合にはいくつかの代替手段があります。 もっとも簡単なのは、全てのリモートアドレスがそれぞれの IP ネットワーク アドレスを所有できるように、リモート IP アドレスをサブネット化してしま うという方法です。そして、それぞれのルーター (すべてのホスト上で、ゲー トウエイアドレスとして表示されているすべてのデバイスです。) 上にネット ワーク経路を付け加えるのです。 これによって、それぞれのリモート IP アドレスが接続されているサーバに対 してその IP ネットワーク宛の（パケットが)送られるようにできます。 (校正者注: リモートマシンのアドレスをまとめてサブネットに押し込む -> そのサブネットへの経路をゲートウェイ（サブネットへのゲートウェイマシン の、元々のゲートウェイ）に書く。-> サブネット化したネットワークへの接 続要求が、サブネットのゲートウェイにくるようになる。ということでしょう か。) この代わりに、ルーターと、サーバ上の gated を使うということもできま す。 IP ネットワークをサブネット化したくない場合には、すべてのホスト経路を 指定してしまう、という方法もあります。つまり、全てのリモート IP アドレ スそれぞれに対して、それぞれのルーターエントリーを指定してしまうので す。 ゲートウエイとルーター上の情報をアップデートする必要はありますが、ネッ トワーク上の全てのホストを変更する必要はありません。 それぞれのホストがルーターにパケットを送る時に使われるデフォールトルー トを通じて、「ICMP re-direct パケット」が、要求を発行したホストに送ら れ、その結果、それぞれのサーバ上にホスト経路が自動的に追加されるからで す。 9. 結論 プロクシ ARP がどのように動作し、どのようなものか、を少しでも説明でき たことを願っています。 pppd や dip-uri を使う場合には、この機械のような手順を知っている必要は （幸運なことに）ありません。これらのソフトウエアが自動的に実行してくれ るからです。 プロクシ ARP は万能の解決ではありません。いくつかの場合にうまく機能す る解決方法にすぎません。 あなたのネットワークの問題にこの機能が役に立つかどうか、自分で判断でき ることを期待しています。 もっと情報が必要な方には、W. Richard Stevens 氏による「TCP/IP Illustrated, volume 1」 "The protocols" (アジソンウエスレイ社刊) など がいいかもしれません。 読んでくれて、ありがとう！ 10. 日本語訳について これは、Linux MINI-HOWTO の、Proxy-ARP の翻訳です。意訳も多くあります が、ご容赦ください。また、誤訳や、もっとわかりやすい訳案などありました ら、ぜひ訳者までフィードバックをお願い致します。 日本語訳 : 川島 浩 (kei@sm.sony.co.jp) 校正 : 堀江 誠一 さん (shorie@ibm.net) 鴨澤 眞夫 さん (k957134@sci.u-ryukyu.ac.jp) 中野 武雄 さん (nakano@apm.seikei.ac.jp)