[index] CentreCOM AR410 V2 コマンドリファレンス 2.6

IP/ARP

  - 概要
   - ARP
   - Inverse ARP
  - ARPエントリーの手動登録
  - ARPキャッシュログ
  - プロキシーARP
   - 自動的に設定される例
   - 手動で設定する例

IPアドレスから物理アドレスを検索するARP（Address Resolution Protocol）関係の機能について説明します。Ethernet上でのARPに加え、フレームリレーインターフェース上でDLCIから対向ルーターのIPアドレスを調べるInverse ARPおよび静的ARP登録についても解説します。

 

概要

 

ARP

Ethernet上での通信は、たとえ上位でIPを使用していたとしても、最終的にはEthernetアドレス（MACアドレス）を使って行われます。ARPはこれを支援するIPの重要なサポートプロトコルです。

同じEthernet LANに所属する2台のホストがIPで通信する場合を考えます。ホスト192.168.10.1はTelnetサーバー、ホスト192.168.10.100がTelnetクライアントだとします。

Telnetセッションを開始しようとするクライアントは、最初にARP Requestパケットをブロードキャストして、サーバーのIPアドレス「192.168.10.1」に対応するMACアドレスを要求します。これに対し、サーバーはARP Replyパケットでクライアントに自分のMACアドレスを伝えます。これで初めて、クライアントはサーバーにIPパケット（TCP Synパケット）を直接送信できるようになります。

ルーター越えの通信でもARPは使用されます。なぜならば、別のIPネットワーク上にあるホストと通信するためには、ルーターにパケットを送りつけてIPパケットの転送を依頼しなくてはならないからです。ルーターにIPパケットを送る手順は、前述したクライアント、サーバー間の通信と何ら変わりません。ルーターにIPパケットを届けるためには、最初にルーターのMACアドレスを知らなくてはならないからです。

通常IPホストは、ARPによって学習したMACアドレスとIPアドレスの対応付けをARPキャッシュと呼ばれるテーブルに保存しています。これは、ARPパケットのブロードキャストを減らすためです。IP通信の開始時には、最初にARPキャッシュを検索し、検索に失敗したときだけARPリクエストをブロードキャストします。また、ARPエントリーにはタイマーが設定され、一定時間通信のなかったエントリーは削除（エージング）されるようになっています。

 

Inverse ARP

フレームリレーは、物理回線上に複数の論理パス（DLC）を設定することにより、1インターフェースで複数拠点との接続が可能なネットワークです。フレームリレー上でIPを使用する場合は、1つのフレームリレーインターフェース上に複数のIPホストが存在する可能性があるため、送信先のIPアドレスを持つ機器がどの論理パス上にあるかを知るしくみが必要になります。

Ethernetでは、ARP Requestパケットのブロードキャストによって、IPアドレスからMACアドレスを検索することができます。IPアドレスを持つ機器がARP Requestを受け取った場合は、自分自身のMACアドレスで応答します。

しかし、フレームリレーにおける物理アドレス（DLCI）はユーザーと網（フレームリレー交換機）の間でしか意味を持たないため、この仕組みは使えません。そこで、フレームリレー上では、仕組みの異なるInverse ARPというプロトコルが使用されます。これは、ARPとは逆に、物理アドレス（例：DLCI）からプロトコルアドレス（例：IP）を調べるためのプロトコルです。

たとえば、フレームリレー網によって接続されている2台のルーターを考えます。ここで、ルーターA（192.168.10.1）がルーターB（192.168.10.100）にパケットを送るとしましょう。

通信を開始しようとするルーターAは、最初にARPキャッシュを検索し、ルーターBのIPアドレス（192.168.10.100）に対応するDLCIが登録されているかどうかを調べます。対応するDLCIが登録されている場合は、そのDLCI宛てにIPパケットを送信します。IPアドレスに対応するDLCIが不明な場合、IPアドレスが不明なすべてのDLCIに対してInverse ARP requestを送信し、各DLCIの対向に位置するホストのIPアドレスを取得し、その後IPパケットを該当DLCIに送信します。

 

ARPエントリーの手動登録

通常、ARPキャッシュはプロトコルスタックの働きによって動的に構築・維持されていくため、管理者が手動で行うべきことはありません。しかしながら、状況に応じて手動でARPエントリーを登録することもできます。

■ スタティックARPエントリーを追加するには、ADD IP ARPコマンドを使います。

■ ARPエントリーを削除するには、DELETE IP ARPコマンドを使います。スタティックエントリーだけでなく、ダイナミックエントリーを削除することも可能です。


■ ARPキャッシュの内容を確認するには、SHOW IP ARPコマンドを実行します。


 

ARPキャッシュログ

本製品は、ARPキャッシュの変更（登録・削除）をログに記録できます。

■ ARPキャッシュログを有効にするには、ENABLE IP ARP LOGコマンドを使います。デフォルトは無効です。


■ ARPキャッシュログを表示するには、SHOW LOGコマンドを使います。SHOW LOGコマンドでは他のログメッセージも表示されますが、「TYPE=ARP」を指定すればARP関連のログだけを見ることができます。



ログメッセージ本体（Message）の表示項目は、左から順にIPインターフェース名、イベント（addかdel）、MACアドレス、IPアドレスです。

Note - あるIPアドレスに対応するMACアドレスが変更された場合は、delイベントとaddイベントが生成されます。

■ ARPキャッシュログの有効・無効はSHOW IPコマンドで確認できます。「IP ARP LOG」欄をご覧ください。


 

プロキシーARP

プロキシーARPは、実際にIPアドレスを所有しているホストに代わって、ルーターが自分自身のMACアドレスで代理応答する機能です。おもに、同じIPサブネットに所属しているものの、物理的には同一LAN上でないためARPが届かない機器同士の通信を可能にする目的で使用されます。

SLIPやPPPでLANに接続しているリモートホストと、実際にLAN上にいるホストとの通信を可能にしたり、サブネットマスクをサポートしていないデバイスをサブネット環境で使用する場合などに使われます。また、Ethernet・Ethernet間でNATを使用する場合にも、プロキシーARPが必要なケースがあります。

デフォルトでは、Ethernet上のすべてのIPインターフェースでプロキシーARPが有効になっており、受信したARP Requestの対象アドレス（への最適経路）が受信インターフェースとは異なるインターフェース上にあることを知っている場合、自分自身のMACアドレスで代理応答し、代理応答に基づいて送られてきたパケットを実際の宛先にルーティングします。

■ プロキシーARPの有効・無効はADD IP INTERFACEコマンド、SET IP INTERFACEコマンドのPROXYARPパラメーターで変更できます。ONを指定した場合は有効に、OFFを指定した場合は無効になります。デフォルトはONです。


マルチホーミングを使って同一Ethernet上に複数の論理インターフェースを作成している場合、プロキシーARPの有効・無効はすべての論理インターフェースに共通して適用されます。

■ プロキシーARPの状態は、SHOW IP INTERFACEコマンドで確認できます。「PArp」欄の表示が「On」なら有効、「Off」なら無効です。

 

自動的に設定される例

プロキシーARPの使用例として、ダイヤルアップPPP接続のケースを考えます。


この例では、ホストBがISDNなどの交換回線網経由でルーターAに接続します。ルーターAでは、着信時にPPPインターフェースを動的作成し、LAN側アドレスの1つをホストBに割り当てます（ここでは192.168.10.241）。これにより、ホストBは遠隔地にありながらも、LAN（192.168.10.0/24）に直接接続されているかのように他のホストと通信できるようになります。

ホストBから見た場合、送信するすべてのパケットがルーターAを経由しなくてはならないことは明らかです。ホストBでは、ネットワークとの唯一の接点であるダイヤルアップPPPインターフェースの方向をデフォルト経路に設定します。

一方、LAN上のホストにとっては状況が異なります。ここでは、ホストA（192.168.10.8）をLAN上ホストの代表として取り上げます。

ホストAがホストBとのIP通信を開始するとします。ホストAは、管理者が設定したIPアドレスとサブネットマスクの情報から、自分の所属するIPネットワークが192.168.10.0/24（アドレス範囲は192.168.10.0〜192.168.10.255）であることを認識しています。通信相手であるホストBのIPアドレス192.168.10.241もこの範囲に収まるため、ホストAはホストBが同一ネットワーク上にあると見なして、192.168.10.241に対するARP Requestをブロードキャストします。

しかし、実際にはホストBはルーターAとISDN網経由で接続されているため、LAN上にブロードキャストされたARP Requestを受け取ることができません。そのため、このままではホストAとホストB間のIP通信が成立しません。

しかし、本製品はデフォルトでプロキシーARPが有効であるため、ホストAが送信したARP Requestを受け取ると、ホストBが別インターフェース（ppp0）上にあることを認識して、代理のARP ReplyをホストAに返します。ホストAは本製品をホストBだと思ってパケットを送信してきますが、本製品はこれをppp0側のホストBに転送します。これでホストAからホストBにパケットが届きました。

今度は戻りです。ホストBは自分宛てでないパケットをすべてルーターAに転送します。ルーターAはホストBから受け取ったパケットの宛先が自分でない場合、経路表を参照して適切に配送します。このように、プロキシーARPの働きによって、LAN上のホストAとWAN経由でLANに接続しているホストBが、個々のホストで特別な設定を行うことなく透過的に通信できるようになります。


もう1つ例を挙げましょう。今度は、異なるLAN上にあるホストAとホストBを考えます。ホストAはサブネットマスクをサポートしていない旧式のIPホスト、ホストBはサブネットマスクをサポートしている普通のIPホストです。

ルーターのeth0とvlan1インターフェースには、それぞれクラスBのプライベートアドレスが設定され、サブネットマスクとして24ビットの255.255.255.0が設定されています。また、ホストAには172.16.10.2（サブネットマスクなし）、ホストBには172.16.20.100（サブネットマスク255.255.255.0）が設定されています。


ここで、ホストAがホストBとのIP通信を試みるものとします。ホストAはサブネットマスクをサポートしていないため、自分の所属するIPネットワークを172.16.0.0であると認識しています。また、通信相手であるホストBのIPアドレス172.16.20.100も、ホストAにとっては同じ172.16.0.0所属と認識されるため、ホストAはホストBが同一ネットワーク上にあると見なし、172.16.20.100に対するARP Requestをブロードキャストします。

しかし、実際にはホストBは別のLAN上にあるため、通常であればARP Requestが届くことはなく、ホストAにARP Replyが返ることもありません。そのため、このままではホストAとホストBはIPによる通信ができません。

しかし、本製品はデフォルトでプロキシーARPが有効であるため、ホストAが送信したARP Requestを受け取ると、ホストBが別インターフェース（vlan1）上にあることを認識して、代理のARP ReplyをホストAに返します。ホストAは本製品をホストBと思ってパケットを送信してきますが、本製品はこれをvlan1側のホストBに転送します。これでホストAからホストBにパケットが届きました。

今度は戻りです。ホストBはサブネットマスクをサポートしているため、ホストAが別サブネットにいることを認識できます。そのため、ホストAと直接MACアドレスで通信しようとはせずに、ルーターにパケットの転送を依頼します。

このようにして、ホストAとホストBは個々のホストで特別な設定を行うことなく透過的に通信ができます。

 

手動で設定する例

今度はプロキシーARPを効かせるために手動で設定を行う例として、Ethernet・Ethernet間のNATで、グローバルアドレスにインターフェースアドレス以外を使うケースを考えます。


ルーターBには、ホストAのプライベートアドレス「192.168.10.5」をグローバルアドレス「1.1.1.5」に固定的に変換するスタティックNATの設定が施されています。グローバル側のホストにとって、ホストAはルーターAとルーターBの間、すなわち、サブネット1.1.1.0/29（1.1.1.0〜1.1.1.7）に存在するように見えます。これは、先ほどのPPP接続の例において、LAN側ホストにはPPPホストが同一LAN上にあるように見えたのとよく似た状況です。

しかし、先ほどの例と異なるのは、ルーターBのルーティングモジュールがホストAの所在を知らないことです。本製品は、その仕様上NATの設定だけでは自分宛てでないARP Requestに代理応答しません。Ethernet・PPP間のNATならばARPを使わないためこのような問題は起きませんが、Ethernet・Ethernet間のNATではこの点に気を付ける必要があります。

最初に、この構成でNATの設定だけを行った場合の動作について解説します。例として、ルーターAがホストAとIPの通信を行うとします（実際にはルーターA経由で外部のホストがアクセスしてきたとお考えください）。

ルーターAにとって、ホストAのアドレスは1.1.1.5です。ルーターAはホストAが同一Ethernetセグメントに所属するものと見なして、1.1.1.5に対するARP Requestをブロードキャストしますが、ホストAは別セグメント上にあるため応答できません。また、ルーターBも、1.1.1.5が自分のアドレスではないため応答しません。そのため、ルーターAはホストAのMACアドレスを知ることができず、通信が成立しません。

このようなケースでは、管理者が手動で設定を行うことにより、ルーターBに代理応答をさせることができます。レンジNAT（IP NAT）とファイアウォールNATでは設定方法が異なるため、以下ではそれぞれのケースについて解説します。

■ 前記の構成でレンジNATを使っている場合は、ADD IP ROUTEコマンドでホストAへの経路を明示的に登録し、ルーターBにホストAの場所を知らせます。ここでは次のようにします。MASKにはホスト経路であることを示すため32ビットマスクを指定し、INTERFACEにはホストAが存在するインターフェース（vlan1）を指定します。PREFERENCEは経路の優先度を指定するもので、0はもっとも優先度の高い経路であることを示します。


これにより、ホストA（1.1.1.5）に対するプロキシーARPが有効になり、ルーターAからのARP Requestに代理応答するようになります。

■ 一方、ファイアウォールNATを使っている場合はもう少し複雑な手順になります。

  1. 最初にグローバル側（eth0）インターフェースをマルチホーミングし、代理応答したいアドレス（ホストAのアドレス）を32ビットマスクで割り当てます。


  2. 次に作成した論理インターフェースをファイアウォールポリシーに追加します。ここでは、PUBLIC（外部）インターフェースとして設定しています。


  3. PUBLIC側からのパケットはデフォルトで遮断されるため、これを通過させるためのルールを設定します。ホストAに対するすべてのパケットを許可する場合は次のようにします。GBLIPはNAT変換後のグローバルアドレス、IPはNAT前のプライベートアドレスです。


    また、セキュリティーを重視するなら、特定のサービスだけを許可するほうがよいかもしれません。HTTPサービスだけを許可するには次のようにします。


  4. さらに、ホストAから通信を開始した場合もスタティックNATが有効に働くように、ホストAからのパケットがスタティックNATインターフェース（eth0-1）にルーティングされるよう、ポリシーフィルターを設定します。


    このフィルターは必須というわけではありませんが、設定しなかった場合、ホストAから外部への通信を開始した場合に、始点アドレスがスタティックNATアドレス（ここでは1.1.1.5）ではなく、ダイナミックENAT用のアドレスに変換されてしまうことがあります。詳細については、「ファイアウォール」の章の「スタティックNAT」の説明をご覧ください。この動作は、ファイアウォールNATの仕様となっています。

これにより、ルーターAから1.1.1.5へのARP Requestに対して、ルーターBが応答するようになります。1.1.1.5はルーターB自身のアドレスなので厳密には代理応答と呼べないかもしれませんが、NAT設定にしたがいルーターBは受け取ったパケットの終点アドレスを変換してホストAに転送します。


手動設定の例をもう1つ挙げましょう。今度は非常に極端な例です。現実のネットワークでこのような設定を行う直接的なメリットはありませんので、あくまでも設定を説明するためだけの例とお考えください。

ここでは、例として異なるLAN上にあるホストAとホストBを考えます。eth0側のホストAには192.168.10.2、vlan1側のホストBには192.168.10.200が設定されているものとします。ホストBのアドレスは、192.168.20.200の間違いではありません。たとえば、本来eth0（192.168.10.0/24）側にあったホストBが、何らかの理由でvlan1（192.168.20.0/24）側に移動されたと考えましょう。


ここで、ホストAがホストBとのIP通信を試みるものとします。ホストAは、通信相手であるホストBのIPアドレス192.168.10.200が同一IPネットワーク上にあると見なし、192.168.10.200に対するARP Requestをブロードキャストします。

しかし、実際にはホストBは別のLAN上にあるため、ARP Requestが届くことはなく、ホストAにARP Replyが返ることもありません。そのため、このままではホストAとホストBはIPによる通信ができません。また、先ほどの例とは異なり、ルーターはホストBがeth1側にいることを知らないため、代理応答も行われません。

このような状況では、ADD IP ROUTEコマンドを使って、ホストBへの経路を明示的に登録し、ルーターにホストBの存在場所を知らせる必要があります。ここでは次のようにします。MASKにはホスト経路であることを示すため32ビットマスクを指定し、INTERFACEにはホストBが存在するインターフェース（vlan1）を指定します。PREFERENCEは経路の優先度を指定するもので、0はもっとも優先度の高い経路であることを示します。


これにより、ホストBに対するプロキシーARPが有効になり、ホストAとホストBは個々のホストで特別な設定を行うことなく透過的に通信ができるようになります。






(C) 2002 - 2008 アライドテレシスホールディングス株式会社

PN: J613-M3048-01 Rev.M