インフラまわりのプロになりたい

---

ARP

本体に入る前に、冒頭の答えが 「ブロードキャストアドレス」 である理由をメモします。

一般的に ARP フレームはセグメントを越えられません。 セグメントをまたがせた通信を行うときは、デフォルトゲートウェイ (DG) に向けてフレームを送信します。 ということは ARP キャッシュが初期化されているノード A は、まずはじめに DG の MAC アドレスを解決する必要があります。 けれども ARP Request の場合、フレームを例外なく全ノードへ向けて送信します。 じゃぁ正解は……そう、 Broadcast ですよね。

イチ人間としても意志が弱く、そして読解力に乏しいワタクシは、どうやら 引っかけ問題のカモ のようです。。
では、そろそろ本題に入りましょうかね。。 OTL


前述もしましたが、ARP の動作につきましては 「Neighbor Discovery（2013-12-13）」 にてメモいたしましたので、動作の仕組みにつきましてはメモをスキップいたします。 以下からは、ARP の概要などをメモします。

Cisco ルータでは ARP テーブルを [ p# show arp ] または [ p# show ip arp ] コマンドから表示させ、また [ p# clear arp-cache ] コマンドからキャッシュ情報を削除します。 以下は今回のテスト環境と、その環境で稼働するルータの ARP テーブルを表示させたものです。


↑図1： Cisco ルータでは MAC アドレスをカンマで区切るんですね


次にノード A からルータの eth0 インターフェースへ向けて送信した ARP Request フレームと、そのレスポンスとなる ARP Reply フレームを Wireshark にて解析すると、以下のような中身が確認できます。



↑図2： ARP フォーマットも確認できる


ARP の動作を理解していれば、図2の中身を細かく解析する必要はないですね。
個人的に気になったポイントと言えば、"Opcode (Operation Code)" の数値によって ARP の動作が変わること。 そして ARP フレームでは、Ethernet ヘッダーに "Padding" が使われること。 この二つでしょうか。


Opcode

ARP Request	1
ARP Reply	2

◆ARP セグメント越え

ARP の概要はここまでにして、次に 「セグメントをまたぐ ARP」 についてメモします。
いわずもがな、冒頭にも書いた Ping-T で心を折られた問題ですね。

頭で理解していても、インターナルバスがタコ糸で作られているようなショボイ脳 を持つ僕ですから、やっぱり体で覚える必要があります。 分かり切ったことでも、ゼロからやり直してみることで、なにか新しい発見があるかもしれない。 そう無理やり自分に言い聴かせることで自我を保ちながらメモします。 (´・ω・｀)


図1の環境にて 「ノード A → ノード B の Ping 通信」 を行うと、以下のような ARP フレームの流れがあります。

まずノード A のコマンドプロンプトから [ pign 10.1.2.1 ] コマンドを実行すると…… 'pign' は、内部コマンドまたは外部コマンド、操作可能なプログラムまたはバッチ ファイルとして認識されていません。 と表示されます。 そうです。 pign ではなく "Ping" コマンドですので、みなさん間違えないようにしましょうね （僕は見事に間違えましたorz）。


（つまらんネタが多くてスンマセン…）。

では気を取り直して。

ノード A から [ ping 10.1.2.1 ] コマンドを実行すると、ICMP パケットが生成されます。 このパケットの IP ヘッダーには、ルーティングに必要な各種情報が格納され、ペイロードには ICMP の情報が格納されます。


↑図3： ping コマンド


このパケットを送信するため、ノード A は自身が持つルーティングテーブルからノード B への経路を探し出しますが、ノード B は別セグメントに属しますので、パケットをデフォルトゲートウェイへ送信しなければなりません。


↑図4： route print コマンド


ここまでは L3 の役割でしたが、ここからは L2 の役割に変わります。

ノード A は ICMP パケットを Ethernet フレームのペイロードとしてカプセル化し、また MAC ヘッダーにノード A とデフォルトゲートウェイの MAC アドレスを指定します。 ところが自身が持つ ARP テーブルからデフォルトゲートウェイの MAC アドレスを探しますが、ARP キャッシュが空っぽなのでアドレスを解決できません。


↑図5： arp -a コマンド


ここからが ARP の動作です。

ノード A はデフォルトゲートウェイの MAC アドレスを解決するために ARP Request フレームを生成します。 このとき生成される ARP Request と、ルータからのレスポンスである ARP Reply フレームは、図2のモノが使われます。 このフレームの送受信により、ノード A の ARP テーブルにはデフォルトゲートウェイのエントリーが追加されます。


↑図6： ARP キャッシュが更新された


デフォルトゲートウェイの MAC アドレスを解決できたノード A は、ICMP パケットをカプセル化したフレームの MAC ヘッダーに、この MAC アドレスを指定します。 ここでようやくフレームを送信する準備が整います。 たったひとつのフレームを送信するだけなのに、裏ではこういう動きをしています。 裏方仕事の大切さが分かりますね。

Ping データが格納されたフレームはルータに届きます。 ルータはフレームを L3 まで紐解いていき、宛先ネットワークを自身のルーティングテーブルから探します。 Cisco ルータでは [ p# show ip route ] コマンドを使います。 余談ですが [ p# show ip protocols ] との違いがイマイチわからないワタクシ。 いつかは分かることを信じて次に進みます。。


↑図7： ルータのルーティングテーブル


ルーティングテーブルから送信ネットワークに最適なルート （今回はインターフェース） が判明したら、ルータは再びパケットをカプセル化してフレームを生成します。 ここでもノード A のときと同様に ARP キャッシュからノード B またはネクストホップの MAC アドレスを探します。 ルータの ARP テーブルは図1で確認できますので、ここの情報を MAC ヘッダーの宛先アドレスに書き換えます。

こうしてルータが eth1 からフレームを送信し、ようやノード B に Ping データが格納されたフレームが届きます。
Ping を受け取ったノード B の ARP キャッシュに、ルータとの ARP 情報がない場合は、これと全く逆の手順を追ってノード A へ Ping リプライを返します。 シンプルですけど、無駄のない動きですよね。

ちなみにですが、ノード B が受け取ったフレームの送信元 MAC アドレスはルータのアドレスが指定されています。 物理的な MAC アドレスは、ノードを経由するたびに書き換わることを忘れないようにしましょう。 これを忘れてしまうと （え、なんで MAC アドレスが書き変わってるの!? ……あ、そうか書き換わるんだった…） と僕のように毎回疑問に思ってしまい、些細ですが無駄な時間を過ごす羽目になってしまいますわよ。(///)



◆ 寄り道 Ethernet ヘッダーについて

ちょいと寄り道、雑談というかコラムというか、ただのメモです。

図2の ARP フォーマットを確認したとき、少しだけ "Padding" を強調しました。
なぜ Padding を強調したかというと、この Padding の発見は個人的に 「大きな収穫」 があったからです。 もともと Padding の存在は知っていましたが、それでも漠然としたイメージしか持っていませんでした。 しかし、図2の画像をキャプチャしているときに……

（あぁ！そういうことね！！）

と、分かったことが2点ありましたので、この場を借りてチョイメモをしていきます。
ちなみに ARP とはかけ離れたメモなので、興味ない方はすっ飛ばしてくださいましw (^ω^*)


▼1．Ethernet の最小フレーム長が 64 Byte ということ

ネットや書籍から Ethernet フレームについて調べていると、「Ethernet のフレーム長は最小 64 Byte」 といった表記が沢山見受けられます。 これについては 「暗記」 と言う面では覚えていましたが、内心は （どういう意味じゃ？） とよく分からず、悶々とする日々が続いておりました。

そんな中、図2の ARP Reply の Padding フィールドに格納された 「0 の連続」 を見つけました。 普段、こういった 0 の羅列を意識しないのですが、なぜかこのときは （この 0 って何個あるんだろう？） と疑問に思いました。 そこで数えてみたところ、この 0 が 「36個」 であることに気づきました。

（00 が 8bit / 1Byte だから 18Byte ってことか…。 たしか Ethernet ヘッダーは 14 Byte だから……あ、ってことは ARP データは 32 Byte か！ これでピッタリ 64 Byte だな！）

と思っていましたが、それは間違いでした。
Wireshark から確認しても、書籍などを参考にしても、ARP フォーマットは 28 Byte です。 じゃぁ残りの 4 Byte ってなに？ 最初はなかなか分かりませんでしたが、思い出しました。 そうです、Ethernet フレームの末尾に 「トレーラー」 としてくっつく "FCS (Frame Check Sequence)" ですね。 Wireshark では確認できないからすっかり忘れていましたが、確かに FCS は 4 Byte でした。

こうやって地道な足し算をしていくことで （そうか！ Ethernet フレーム長の最小 64 Byte ってそういう意味だったのか！） と、ようやく気づくことができました。 テキストで覚えた 「暗記」 という意味ではこれらを理解していましたが 「体で覚える」 という意味では今回が初めてでしたので、とてもいい経験になりましたね。


↑図8： ARP フレームの合計サイズ


▼2．Wireshark がフレームをキャプチャするタイミング

図2の ARP Reply フレームには、前述した Padding が記載されています。
しかし ARP Request フレームには Padding の記述がありません。 これってなぜでしょうか。

この疑問を追究する前に、あるひとつの出来事を書きます。

今から2年ほど前でしょうか、僕が Wireshark を触りたてのころです。 ネットから Wireshark の操作方法について調べていたところ、以下のサイトから Wireshark の記事を発見しました。 以下の記事では Wireshark でフレームを解析するポイントを丁寧に解説されていますが、一部の文章にこのようなことが書かれています。


　Wiresharkでの最小フレーム長は60バイトのはずだが、18バイト足りない。フレームでは、データ長が最小値に足りない場合には「パディング」というダミーのデータを付加する。このパディングを付加するタイミングと、Wiresharkがキャプチャするタイミングに差があるためにこのような問題が生じている。

　参考サイト：Ethernetのフレーム構造を理解しよう
　http://ascii.jp/elem/000/000/427/427324/index-2.html


当時 （今もですけど） の僕はとても知識が乏しかったので、こちらの文章を読みながらも （なに言ってんのかよく分からん…） と思ってしまい、失礼ながら途中でこのページを閉じました。

しかし時は流れて今回、 Padding についてネットから調べていたところ、偶然にもまさにこのページを発見しました。 そしてリベンジがてら、こちらの記事を読んだところ （わかる、わかるぞ…ッ！！） と、全部を理解できたじゃありませんか。 まさに奇跡。。 やはり 「継続は力なり」 でございますね。

……といったことを 簡潔 に書きたかったのですが、いかんせん歳をとると話が長くなってタマランねぇ。。。


話を戻しますが、ARP フレームの Padding 有無は Wireshark がフレームをキャプチャするタイミングが関係していたのです。 ARP Request を送信するときは、Padding データを付加する前に Wireshark がキャプチャしていたようです。 ということは、ARP Request だから Padding が記録されない、ARP Reply だから Padding 記録される、というわけではなく、送信フレームだから、受信フレームだから という分け方が正しいのでしょうね。



↑図9： Wireshark がフレームを解析するタイミング


こうやって見てみると Ethernet の仕組みって奥深いですね。

「プリアンブル」 という言葉が出てきましたが、個人的にはこのプリアンブルを理解することが Layer1（物理層） を理解する第一歩だと 思っています。 なぜ 思っています と強調したのかというと、これは僕がまだ理解していないからです。 そう、それだけの理由だったりw (^ω^*)

---

RARP

Ping-T の憂さ晴らしに ARP について 「これでもか!!」 というくらいメモしてやりました。
すこし気持ちがスッキリしたので、本題の Proxy ARP / GARP をメモする前に "RARP" についてメモしますw

RARP は "Reverse Address Resolution Protocol" の略でして、Reverse ARP というその名称の通り 「ARP とは逆の動作」 を行う技術です。 ARP は IP アドレスから MAC アドレスを解決しますが、RARP では MAC アドレスから IP アドレスを解決します。

そんな RARP の使い道ですが、これは 「IP アドレスの自動設定」 に使われます。 IP アドレスの自動設定には DHCP という便利なプロトコルがありますが、この RARP はもっと低いレイヤーで IP アドレスの自動設定を実現します。 もちろん ARP が L2 であるように、RARP も L2 で動作します。



↑図10： DHCP とは動作レイヤーが違う


IP アドレスを自動構成するなら DHCP で事足りるはずなのに、なぜ RARP というプロトコルが存在するのでしょうか。 歴史的背景についての詳細は分かりませんが RFC 番号が RARP の方が DHCP より若いので、今となっては過去の産物なのでしょう。

ではなぜ、その過去の産物である RARP についてメモするのか。 それはこのRARP がネットワーク機器を中心に未だ現役だからです。 少なくとも私が仕事で使っているヤマハルータには、この RARP クライアント機能がデフォルトで搭載されています。 多くの RTX シリーズでは、工場出荷状態の場合に IP アドレスがルータに設定されておらず、RS-232C コンソールケーブルなくして設定できません。 こういった問題の最終手段として、RARP によるネットワーク機器の IP アドレス割り当てが活用されます。


　rtpro - RARPって？
　http://www.rtpro.yamaha.co.jp/RT/FAQ/Intro/rarp.html


そんな RARP フレームには、通常の ARP と同様に Request/Reply の2種類が存在します。 Request フレームは IP アドレスを要求する RARP クライアントが、Reply フレームは IP アドレスを配布する RARP サーバがそれぞれ送信します。

以下の図11に RARP Request のキャプチャ画像を貼りますが、注目すべき点は2点あります。 それは opcode に "3" （Reply には "4"） が指定されていること。 そして Sender/Target MAC address に RARP Request 自身の MAC アドレスが指定されていることです。



↑図11： RARP クライアントは、このフレームをブロードキャスト送信する


ブロードキャストされた Request フレームを受け取った RARP サーバは、クライアントに配布する IP アドレスが記述された設定ファイルをもとに RARP Reply フレームを生成し、それを RARP クライアントにユニキャスト送信します。 このフレームを受け取ることで RARP クライアントは IP アドレスを自動生成できます。

ちなみに RARP サーバは IP アドレスのみ配布し、DG などの情報は一切配布しませんので、こりゃ DHCP に主導権を握られるのも頷けますよね。


余談ですが、僕がはじめて RARP という用語を知ったとき、こう思いました。

　（MAC アドレスから IP アドレスを解決して、なんの意味があんの???）

ただこういう疑問を持つようでは、まだまだ ネットワークの本質を見つめられていない未熟者 です。 本質を理解しているネットワークエンジニア、または想像力や発想力が豊富な人からすれば、RARP という用語をはじめて耳にしても （あ、なるほど RARP ってそういうことね） といった “ひらめき” があるのでしょうね。 うらやましい。。。(´・ω・`)

---

GARP

ここで GARP という仕組みについて少しメモします。

GARP は "Gratuitous ARP" の略ですが、そもそも Gratuitous の意味がよく分からず、そして （ギャープって読むの？ いやさすがにジーアープだよなぁ…） なんて、動作概念よりも読み方に大きな疑問を持ってしまいました。

さっそくですが、この GARP は 「IP アドレスの競合を防止」 するための仕組みです。

たとえば、あるノードに IP アドレスを設定する場合、それが DHCP などの自動割り当て機能を利用しているならば、基本的には IP アドレスが重複する可能性が低いです。 けれども固定アドレス、すなわち人間が手動で IP アドレスを設定する場合などは、ちょっとした不注意によって IP アドレスを重複させて設定してしまうことがあります。

そんな僕は、まだ IP アドレスの重複設定に涙したことはありません。 それよりも僕はノードに IP アドレスを手動で設定したとき 「デフォルトゲートウェイの設定」 をしょっちゅう間違えます。 （あれれー?? なんで Ping がセグメント越えないのォ!?） なんてことに永遠と悩んで、結果的に給料泥棒だった経験は沢山あったり。。



↑図12： こんなアラート見たことありません？ これね GARP の苗木。


そんな GARP の動作を以下にメモします。

GARP も基本的には ARP と同じように Request はブロードキャスト、Reply はユニキャストでフレームを送受信しますが、特徴的なところは ARP Request のデータ部分に "Sender IP address" と "Target IP address" に自ノードの IP アドレスが指定されることです。 この IP アドレスを先行して設定しているノードがこのフレームを受信すると 「このアドレスは私が既に使用していますよ」 といった ARP Reply を送信元ノードへ送り返します。 そして、この ARP Reply を受信した送信元ノードは 「あぁ、この IP アドレスは使われているんだな」 と判断し、その IP アドレスを無効にします。



↑図13： GARP の ARP Request フレーム


GARP の概要を初めて目にしたとき （なんか難しそう…） と構えてしまいましたが、実のところ GARP の目的は IP アドレス競合の防止ですから、確かに自ノードの IP アドレスを指定した ARP Request をブロードキャスト送信すれば、レスポンスがあった場合にそれが重複 IP アドレスであることが分かりますね。 すげーシンプルなんですねぇ。。

そんな GARP には、もうひとつの使い道として 「ARP キャッシュのリフレッシュ」 があるようです。 今の僕はこちらを検証するすべがないため、具体的な検証結果を載せることができませんが、早い話 「メアド変わったんで皆さん登録よろしくねーｗ」 の ARP キャッシュ版だと思っていただければと思いますｗ (^ω^*)

---

Proxy ARP

では、本メモのラストとなる "Proxy ARP" についてメモします。

少し駄弁を弄しますが、はじめて Proxy ARP という存在を知ったのは L3 スイッチの設定画面を眺めていたときでした。 当時の僕は新米エンジニアだったので Proxy ARP はもちろん ARP も知らない、それどころか L3 スイッチさえもナンなのかよく知らなかったこともあり、（ナニコノ難しそうな仕組み……おれ、ネットワークエンジニア辞めてルーチンワーカーで一生を終えようかな…） と、一種の挫折に近い感情を味わったことを覚えています。

そんな Proxy ARP についてメモする日が来るとは、まったく想像していませんでした。 人生って何が起こるか分かりませんね……なんてノスタルジックになりながら、以下を書いていきます。


Proxy ARP は 「ルータがノードに代わって ARP を処理する」 仕組みです。

たとえばノード A から ノード B へ ARP Request を送信する場合を考えますと、これらのノードが同じセグメントに属していれば ARP Request の送受信には問題ありません。 しかし、ノード B がルータを挟んだ別セグメントに属して締まった場合は、ノード A がブロードキャスト送信した ARP Request はルータを越えることができず、通信に失敗してしまいます。 そこでルータに Proxy ARP を設定させることで、ルータがノード B に代わって ARP Request を代理応答し、これらの問題を解決できます。



↑図14： ルータが ARP 処理を代行してくれる


……自分自身で書きながらも、我は疑問に思った。

（でも、どうしてセグメント間の通信にルータが ARP を代理応答させるのだろう？ ルーティング機能で通信しちゃえばいいじゃナイ ・ω・?）

「ARP とはセグメント内だけで完結するものだ」 と信じて疑わなかった自分は、この Proxy ARP の存在に終始 （イミフwwwうはwww無駄な機能www） と思っていました。 しかし 「例外がある」 という考えまでに意識を導けない自分は、まだまだ脳内の引き出しが少ないようです。。

どうやら Proxy ARP は 「例外」 的な環境で使われる機能のようです。

その例外の一例として 「ネットワークプレフィックスの違い」 があります。 たとえばプレフィックス /24 のネットワークセグメントには、プレフィックス /24 の IP アドレスを設定したノードが属するのが一般的です。 しかし、大人の事情によってプレフィックス /24 のネットワークに "/16" の IP アドレスを設定したノードが存在することもあるようです。

プレフィックスが対応する IP 個数は /24 が 256個 で、/16 は 65,536個 です。 これから分かるように /24 のネットワーク範囲は第3オクテットで認識しますが、/16 の場合は第3オクテットは同一セグメントと認識してしまいます。 早い話、プレフィックス /24 のネットワークに /16 のノードが属してしまうと /16 のノードがネットワーク範囲の勘違いを起こしてしまうのですね。



↑図15： プレフィックス /16 のネットワーク範囲は巨大


上図15を例にノード間の通信動作をメモしますと、ノード A からノード B へ向けて通信するときは、互いが同一セグメントですのでノード B を ARP 処理します。 また、ノード B からノード C へ向けた通信は、互いが別セグメントに属しますのでルータを ARP 処理します。 ここまではいつも通りですね。

さて、問題はここからです。 ノード A からノード C に対して通信を行なうとき、本来ならばノード B と同様にノード A はルータを ARP 処理すればよいですが、なんせノード A のプレフィックスは /16 ですから、ノード C を 「同一セグメントに属したノード」 と勘違いしたまま、ARP Request をノード C へ向けて送信してしまいます。 しかし、ルータは ARP Request をセグメント越えさせませんので、ノード C はフレームを受け取ることができず、結果的に通信は失敗に終わります。



↑図16： ノード A は何も悪くない。 悪いのはそういう環境を作らせた人…


このような状況を助けてくれるのが、この Proxy ARP です。

上図16 の状況にて、ルータに Proxy ARP を設定した場合の動作をメモします。 先ほどと同様に、ノード A からノード C へ向けて ARP Request をブロードキャスト送信すると、ルータはこのフレームを受信します。 するとルータはProxy ARP 機能が ON になっていますので、その ARP Request の宛先であるノード C へのルートが確立されていることを確認できたら、「ノード C への通信はオレが代わりに転送してやるわい!!」 と言わんばかりに、ルータが ARP Reply を投げ返します。

Proxy ARP の説明として 「ARP フレームを転送するしくみ」 という表現をよく目にしますが、それよりも 「ARP フレームが届かないノードに代わって ARP 処理を代行した上で、そのノードへパケットを転送するしくみ」 という表現の方が正しいような気がしますね。



↑図17： Proxy ARP は ARP の代理応答かつパケットの転送


ちなみにですが、ルータが放った ARP Request フレームを受け取ったノード A の ARP キャッシュには、ノード C へ繋がる機器の MAC アドレスに、ルータの MAC アドレスが登録されます。 当たり前っちゃ当たり前なのですが、念のために以下に ARP テーブルの画像をペチャリと貼り付けておきます。



↑図18： ルータの MAC アドレスは "00-1b-53-70-af-7e"



以上、Proxy ARP の説明でございました。

いつもならここでメモを終わりますが、今回はもう少し続きます。 というか、個人的にはここからが本題です。 本メモの冒頭で 「Ping-T に心折られた反省として本メモを書く」 みたいなことを書きましたが、実は 「ある疑問」 の答えを出すために、本メモを書きはじめました。 「反省としてメモを書く」 といった動機だけでメモを書いていたら、仕事も人生も失敗ばかりしている、そもそも生まれてきたことが失敗だったと自負しているミスター・フェイラーの僕は、いつまで経ってもメモの呪縛から解放されない人生を過ごすことになります。

…でも 「失敗メモ」 を書き続ける人生も楽しいかも。 ただそれはあまりにも時間がかかりそうだから、これは老後の楽しみとして取っておこうかな。。 なんて30年後の自分を想像しながら 「ある疑問」 を紐解いて本メモを終わろうと思いますw (^ω^*)



◆疑問： ヤマハルータの PPTP サーバで Proxy ARP コマンドを設定する理由

経験者ならピンとくるかもしれませんが、ヤマハルータを PPTP サーバとして動かすとき、ルータに Proxy ARP 有効化コマンドを実行します。 「ある疑問」 とは、まさにコレ。 はじめて PPTP サーバを構築したときから （なんで Proxy ARP が必要なのだろう？） と疑問に思っていました。

ところが今回 Proxy ARP のメモを書いているとき、ふと気づきました。 （あ！ Proxy ARP が必要な理由って……もしかして？） といった具合に。 ただ、このときは “漠然” とした理解でしかありませんでした。 じゃあせっかくだから、この漠然とした理解を 「しっかりとした理解」 に変えてしまおう――と思い立ち、本メモを残す次第であります。

では、さっそく検証スタートです。

はじめに以下のような PPTP 環境を構築しました。 よくある普通の PPTP 環境ですので Config は割愛しますが、Proxy ARP だけは “無効” にしています。 まずはこの Proxy ARP が無効化された状態での通信の動きを見てみます。



↑図19： 一般的な PPTP 環境。 ただし Proxy ARP は無効化


図19は、ノード A が PPTP サーバのヤマハルータ (192.168.123.254) へ PPTP 接続を試みると、PPTP クライアントとして 10.1.1.100 の IP アドレスを割り当てる環境です。 この環境で試そうとしている内容は、PPTP クライアントとしてルータにリモート接続したノード A から、同一セグメントに属するノード B へ Ping を送信したらどうなるかです。

さっそくノード A からノード B へ Ping (ping 10.1.1.101) を送信したところ、レスポンスはありませんでした。 繋がっていないようです。 ただ、このときノード B の Wireshark を確認するとノード A からの ICMP Request パケットは受信できています。 しかし続くノード B の ARP Request フレームがタイムアウトを起こしています。 このことから、ノード B はノード A の ARP 解決に失敗していることが分かります。



↑図20： Ping のリクエストは通る。 けどリプライ前の ARP Request が失敗する


なぜノード A の ARP 解決に失敗しているのか。 それを順を追って確認していきます。

まずノード B が ARP Request を送信する理由は、ARP キャッシュにノード A の MAC アドレスが未登録だからなのは言うまでもありませんね。 よってこの ARP Request の Target IP Address フィールドには、ノード A の IP アドレスである 10.1.1.100 が指定されます。 ノード B はこのフレームをブロードキャスト送信します。



↑図21： Target IP Address にはノード A の IP アドレスが指定されるが…


次にノード A は、このフレームを受信しなければなりません。 ですが、よく考えてみるとノード A は PPTP クライアントですから、ノード A の物理インターフェースには ARP Request が届きません。 ではどのインターフェースに届くのか？ それは PPTP サーバであるヤマハルータのインターフェースです。 ところがヤマハルータのインターフェースには 10.1.1.254 が割り当てられていますので、Target IP Address にノード A の IP アドレス 10.1.1.100 が指定されたこの ARP Request は、ルータは 「自分宛てのモノではない」 と認識し、受信したフレームを破棄してしまいます。



↑図22： ルータ Proxy ARP 機能を無効化しているため ARP Request を破棄する


これを解決するには、PPTP サーバであるヤマハルータがノード A 宛の ARP Request を代理応答しなければなりません。 そう、その機能が Proxy ARP なのです。 なるほど、ようやく Proxy ARP の疑問が解けました！

ちなみに、このときルータの Proxy ARP 機能をすると Ping 通信が確立されます。 また Ping 通信確立にノード B の ARP キャッシュを確認すると、ノード A 宛に登録された MAC アドレスにはルータの MAC アドレスが登録されていました。



↑図23： 同じ MAC アドレスを使う。 当たりまえっちゃ当たり前だけど、その当たり前が素晴らしいのです


ただ、また別の疑問も残りました。

ヤマハルータでは "Proxy ARP" という機能ですが、Cisco ルータには Proxy ARP の他に "Local Proxy ARP" という機能が搭載されていました。 Local Proxy と表現するくらいですから、同一セグメントを対象とした ARP 通信、今回のような PPTP クライアントとの ARP 通信が Local Proxy にあたり、それ以外の別セグメントを対象とした ARP 通信が Proxy ARP なのでしょうね。

これらの違いも追究しようかと思いましたが、ヤマハルータの疑問が解決した瞬間にバーンアウト症候群モードに突入してしまったことから、この疑問は闇に葬ることにします。 こういう詰めの甘さが自分の欠点だと確認しながらも、その欠点をまったく直すつもりもない自分に （三つ子の魂百まで。ナマケモンの性格は改善せんなぁ） と楽観視しながら、本メモを終えようと思いますｗ (///)

---

最後に

僕は今、インフラエンジニアとして日本社会に小さく貢献しています。

ところが今月から、僕は 「プログラマ」 として社会に貢献することになります。


突然ですが、わたくしはアプリケーション開発チームに転属しました！！


インフラまわりのプロになりたい、というスローガンを胸に刻みながら、
ネットワークやサーバまわりの知識・経験を豊富にしようと、今までずっと努めてきました。

それなのになぜ、プログラマに転属したのでしょうか？
飽きっぽい僕のことですから、インフラまわりに飽きたのでしょうか？

詳細や経緯などは、また別の機会に書こうと思っていますが、
早い話、以下のようなやり取りがありました。


　ぼく 「インフラまわりのプロになりたい！」

　主任 「いいねぇー。 ちなみに聞くけど、システム開発の経験は？」

　ぼく 「一年ほどプログラマ経験がありますが、そういえば設計書とか書いたことないですねぇ…」

　主任 「本格的な開発経験はゼロか……うーん…」

　ぼく 「インフラまわりのプロって開発経験は必要ですか？」

　主任 「うん、正直に言おう。 もしインフラのエキスパートを目指したいなら、本格的な開発を経験するべきだね」

　ぼく 「（インフラのプロじゃなく…エキスパート…だと…？）」

　主任 「なぜインフラエンジニアなのに本格的な開発が必要なのかっていうと、それはね―――」

　ぼく 「（インフラの…エキスパート……エキスパート…）」　

　主任 「―――ってなわけ。 あ、そういえばウチの開発チームはメンバーを募集してるけど、よかったらくる？」


　ぼく 「いきます！！！」




………。



ってな、感じです。

今回、アプリケーション開発に携わるに至ったのは、あくまでインフラまわりを極めるためです。
ということで、これからシステム開発関係の記事が増えるかもしれません （とくに JAVA）。

今後、もし僕が 「システム開発系の記事」 を更新していたら、
（おぉ、仕事頑張ってんなぁ） と温かい目で見てやってください。

今後、もし僕が 「ネットワーク系の記事」 を更新していたら、
（あぁ、コイツ仕事サボってんなぁ） とナマヌルイ目で見てやってくださいw (^ω^*)