はじめに
この実験では、Linux 環境におけるネットワーク層（レイヤー 3）とデータリンク層（レイヤー 2）の基本的な相互作用を探求します。一般的な ping および arp コマンドラインユーティリティを使用して、アドレス解決プロトコル（ARP）の動作を観察します。主な目的は、ローカルネットワーク上のデバイスの IP アドレスを物理 MAC アドレスに解決する方法と、リモートホストとの通信をどのように処理するかを理解することです。
まず、ARP キャッシュの状態を調べます。次に、ローカルデバイス（デフォルトゲートウェイ）およびリモートデバイス（google.com）と通信するために ping を使用します。これらの操作の前後に ARP キャッシュを観察することで、システムがローカル通信に MAC アドレスをどのように使用し、リモートトラフィックにデフォルトゲートウェイにどのように依存するかを確認できます。
arp -a で初期 ARP キャッシュを表示する
このステップでは、システムの Address Resolution Protocol (ARP) キャッシュの初期状態を確認します。ARP キャッシュは、同じローカルネットワーク上のデバイスのレイヤー3 (IP) アドレスと対応するレイヤー2 (MAC) アドレスのマッピングを格納する、重要なネットワークコンポーネントです。
まず、arp コマンドを使用して ARP キャッシュの現在の状態を確認しましょう。-a フラグは、すべての現在のエントリを表示するようにコマンドに指示します。
すでに ~/project パスにあるターミナルで、以下のコマンドを実行してください。
arp -a
おそらく、1 つ以上のエントリが表示されるでしょう。デフォルトゲートウェイがすでにキャッシュに存在することは一般的です。出力は以下のようなものになる可能性があります。
_gateway (172.16.50.253) at ee:ff:ff:ff:ff:ff [ether] on eth0
? (172.16.50.251) at ee:ff:ff:ff:ff:ff [ether] on eth0
LabEx 環境の仮想化された性質により、ARP キャッシュを完全にクリアすることが常に可能とは限らないことに注意することが重要です。そのため、最初からプリポップされたキャッシュが表示される可能性が高いです。典型的な非仮想化環境では、最初の通信の前にゲートウェイに対して空または
<incomplete>のエントリが表示される可能性が高くなります。
この出力は、ARP キャッシュの初期状態を示しています。これは、ネットワークアクティビティをトリガーし、このテーブルがどのように使用されるかを観察する次のステップのベースラインとして機能します。
ローカルデバイスに ping を実行して ARP リクエストをトリガーする
このステップでは、ping コマンドを使用してローカルネットワーク上の別のデバイスとの通信を開始します。このアクションは、必要に応じて ARP（Address Resolution Protocol）マッピングを使用します。システムがローカル IP アドレスにパケットを送信しようとすると、まず ARP キャッシュを確認します。対応する MAC アドレスが見つからない場合、ブロードキャスト ARP リクエストを送信します。エントリが既に存在する場合、キャッシュされた MAC アドレスを使用します。
これを行うには、まずローカルネットワーク上のデバイスの IP アドレスを特定する必要があります。この環境で最も信頼できるターゲットは、デフォルトゲートウェイ（仮想ルーター）です。ルーティングテーブルを調べることで、その IP アドレスを見つけることができます。
ターミナルで、次のコマンドを実行してルーティングテーブルを表示します。
ip route show
出力にはデフォルトルートが表示されます。default via で始まる行を探してください。そこに記載されている IP アドレスがゲートウェイです。
default via 172.16.50.253 dev eth0 ...
...
上記の例の出力から、ゲートウェイの IP アドレスは 172.16.50.253 です。次に、この IP アドレスを使用して ping パケットをいくつか送信します。-c 4 オプションは、ping に 4 つのパケットを送信して停止するように指示します。172.16.50.253 を、実際に見つけたゲートウェイの IP アドレスに置き換えてください。
ping -c 4 172.16.50.253
各パケットに対して成功した応答が表示され、システムがゲートウェイと通信できたことを確認できるはずです。
PING 172.16.50.253 (172.16.50.253) 56(84) bytes of data.
64 bytes from 172.16.50.253: icmp_seq=1 ttl=64 time=0.066 ms
64 bytes from 172.16.50.253: icmp_seq=2 ttl=64 time=0.060 ms
64 bytes from 172.16.50.253: icmp_seq=3 ttl=64 time=0.055 ms
64 bytes from 172.16.50.253: icmp_seq=4 ttl=64 time=0.045 ms
--- 172.16.50.253 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3060ms
rtt min/avg/max/mdev = 0.045/0.056/0.066/0.007 ms
この単純な操作により、システムは ARP ルックアップを実行しました。次のステップでは、ARP キャッシュを再度調べて結果を確認します。
ARP キャッシュでローカル IP-MAC 解決を確認する
このステップでは、先ほど実行した ping コマンドの直接的な結果を確認するために、ARP キャッシュを再確認します。システムがローカルゲートウェイと正常に通信できたため、有効な IP-MAC アドレスのマッピングがあったはずです。テーブルが変更されたかどうかを見てみましょう。
再度 ARP キャッシュを調べます。ターミナルで、最初のステップと同じコマンドを実行します。
arp -a
今回は、エントリがまだ完了していなかった場合のみ、出力が異なります。この場合、ステップ 1 でエントリが既に解決されていたため、出力は同一になります。
_gateway (172.16.50.253) at ee:ff:ff:ff:ff:ff [ether] on eth0
? (172.16.50.251) at ee:ff:ff:ff:ff:ff [ether] on eth0
この出力をステップ 1 の出力と比較してください。同一です。これは、ゲートウェイのエントリが、ping を送信する前に既に完了していたためです。システムは新しい ARP リクエストを実行する必要はなく、単にキャッシュ内の情報に依存しました。
これは重要な原則を示しています。ARP キャッシュは冗長な ARP リクエストを防ぎます。エントリが <incomplete> であったり、欠落していたりした場合、この ping コマンドによってそれが入力され、出力に変更が見られたでしょう。
デフォルトゲートウェイを介して外部ホストに ping を実行する
このステップでは、ローカルデバイスとの通信からインターネット上のホストとの通信に移行します。これは基本的なネットワークの概念を示しています。つまり、コンピューターが自身のローカルネットワーク外の宛先に到達するために、どのようにデフォルトゲートウェイを使用するかということです。
宛先の IP アドレスがコンピューターと同じサブネットにない場合、システムは直接パケットを送信できないことを認識します。代わりに、指定されたデフォルトゲートウェイにパケットを送信する必要があります。ゲートウェイ（ルーター）は、インターネット全体でパケットを最終的な宛先に転送する責任を負います。
これを実際に確認するために、よく知られた外部ホストである google.com に ping を実行します。
ターミナルで、次のコマンドを実行します。
ping -c 4 google.com
google.com というドメインが IP アドレスに解決され、そのアドレスから応答が返ってくるのが表示されます。
PING google.com (142.250.189.174) 56(84) bytes of data.
64 bytes from sfo03s24-in-f14.1e100.net (142.250.189.174): icmp_seq=1 ttl=118 time=4.38 ms
64 bytes from sfo03s24-in-f14.1e100.net (142.250.189.174): icmp_seq=2 ttl=118 time=4.40 ms
64 bytes from sfo03s24-in-f14.1e100.net (142.250.189.174): icmp_seq=3 ttl=118 time=4.35 ms
64 bytes from sfo03s24-in-f14.1e100.net (142.250.189.174): icmp_seq=4 ttl=118 time=4.39 ms
--- google.com ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 4.353/4.380/4.401/0.017 ms
google.com と正常に通信できましたが、コンピューターは Google の IP アドレスに対して ARP リクエストを実行しませんでした。必要なのはローカルゲートウェイの MAC アドレスだけであり、これは前のステップで既に検出されていました。次のステップでは、ARP キャッシュを分析してこの動作を確認します。
リモート通信のための ARP キャッシュを分析する
この最終ステップでは、リモートホストとの通信をシステムがどのように処理するかを確認するために、ARP キャッシュを最後に分析します。これにより、ローカルネットワーク通信とリモートネットワーク通信の違いが明確になり、デフォルトゲートウェイの役割が強調されます。
google.com への ping が成功したところで、再度 ARP キャッシュを確認しましょう。ターミナルで arp -a コマンドを実行します。
arp -a
出力を注意深く調べてください。前のステップのキャッシュ状態と同一であるはずです。
_gateway (172.16.50.253) at ee:ff:ff:ff:ff:ff [ether] on eth0
? (172.16.50.251) at ee:ff:ff:ff:ff:ff [ether] on eth0
google.com またはその IP アドレス（例：142.250.189.174）のエントリが存在しないことに気づくでしょう。存在する唯一の重要なエントリは、依然としてデフォルトゲートウェイのエントリです。
これがこの実験の重要なポイントです。ARP はレイヤー 2 で動作し、ローカルネットワークセグメント上の MAC アドレスを見つけるためにのみ使用されます。コンピューターがリモート宛先にパケットを送信するとき、宛先がローカルではないことを認識しているため、パケットをネクストホップ（デフォルトゲートウェイ）の MAC アドレスに送信します。ルーターは、IP パケットを最終的な宛先に転送する責任を負います。コンピューターは google.com の MAC アドレスを知る必要はありません。パケットを転送できるデバイスの MAC アドレスを知っているだけで十分です。
まとめ
この実験では、Linux の ping および arp コマンドを使用して、レイヤー 3（IP）とレイヤー 2（MAC）ネットワーキングの基本的な相互作用を探りました。まず arp -a でアドレス解決プロトコル（ARP）キャッシュの状態を調べ、デフォルトゲートウェイのような重要なデバイスのエントリが既に含まれている場合があることを確認しました。ローカルゲートウェイに ping を実行することで、システムがローカル通信のためにこのキャッシュされた情報を使用し、冗長なアドレス検索を回避していることを確認しました。
さらに、リモートホストとの通信がどのように異なるかを調査しました。外部 IP アドレスに ping を実行した際、システムは最終宛先に対して ARP リクエストを実行しないことを観察しました。代わりに、パケットはローカルネットワーク外へのルーティングのためにデフォルトゲートウェイに送信されます。最終的な ARP キャッシュの分析により、この概念が強化され、リモートホストのエントリは追加されなかったことが示されました。関連する唯一のエントリはデフォルトゲートウェイのままであり、外部ネットワーク宛てのすべてのトラフィックの中継役としてのその重要な役割が強調されました。
