ARPをパケットで確認する|WiresharkでRequest・Replyを読み解く

ネットワーク中級編 33/全50記事

この記事は、 「ネットワーク中級編|構築・検証・障害切り分けを身につける」 の第33回です。

前回学んだWiresharkの基本操作を使い、ARP RequestとARP Replyを実際のパケットから読み解きます。

ARPをパケットで確認する|WiresharkでRequest・Replyを読み解く

「Who has ~?」と「~ is at ~」は何を表しているのか。 WiresharkでARP通信を取得し、ブロードキャストのRequest、ユニキャストのReply、 EthernetヘッダーとARPヘッダーの各項目を、障害切り分けにつながる形で確認します。

対象レベル Level 2・中級
想定読了時間 約25分
身につく成果 ARPの正常・異常をパケットで判断できる
前提知識 ARPの仕組み/Wiresharkの基本
演習環境 PC+Wireshark+同一LAN上の機器

ARPは、IPv4アドレスから同一リンク上で使用するMACアドレスを調べる仕組みです。 用語として理解していても、実際のパケットを見ると「どのアドレスがブロードキャストなのか」 「Replyは誰に返るのか」で迷うことがあります。

この記事では、ARPキャッシュを確認・削除し、pingを発生させ、WiresharkでRequestとReplyを読む ところまでを一連の検証として行います。

この記事を読み終えるとできること

  • ARP RequestとARP ReplyをWiresharkで見分けられる
  • EthernetヘッダーとARPヘッダーの宛先を区別できる
  • 同一セグメント通信と別セグメント通信でARP対象が変わる理由を説明できる
  • ARP Requestだけが繰り返される状況から原因候補を絞り込める

ARPをパケットで確認すると何が分かるのか

今回の結論

正常なARPでは、端末がブロードキャストでMACアドレスを問い合わせ、 対象機器が通常はユニキャストで自分のMACアドレスを返します。

IPv4通信では、IPパケットをEthernetフレームに格納して同一リンク上へ送るため、 次に渡す相手のMACアドレスが必要です。端末がそのMACアドレスを知らない場合にARPを使用します。

ARP RequestとARP Replyの基本動作

💻 PC-A 192.168.10.10
00:11:22:33:44:55
🌐 デフォルトゲートウェイ 192.168.10.1
aa:bb:cc:dd:ee:ff
Request Who has 192.168.10.1? Tell 192.168.10.10
「192.168.10.1を持っている機器は、192.168.10.10へ教えてください」
Reply 192.168.10.1 is at aa:bb:cc:dd:ee:ff
「192.168.10.1のMACアドレスはaa:bb:cc:dd:ee:ffです」

パケットキャプチャーでARPを確認すると、単に「pingが失敗した」という結果だけではなく、 その前段階である同一リンク上の相手を見つけられているかを判断できます。

ARP Replyまで返っていれば、少なくとも対象MACアドレスを解決できる範囲のLayer 2通信は成立しています。

その後にpingが失敗する場合は、IP設定、ICMP制御、ACL、ファイアウォール、ルーティングなどへ確認範囲を進めます。

ARPはIPv4で使用されます。IPv6ではARPではなく、ICMPv6を利用するNeighbor Discovery Protocol(NDP)が同様の役割を担います。

今回の検証構成

最も再現しやすいように、PCから同一LAN上のデフォルトゲートウェイへpingを送ります。 実際のIPアドレスやMACアドレスは、利用している環境に読み替えてください。

検証用の構成例

💻 検証PC IP:192.168.10.10/24
MAC:00:11:22:33:44:55
──
🔀 スイッチ/無線LAN 同一ブロードキャストドメイン
──
🌐 ルーター IP:192.168.10.1/24
MAC:aa:bb:cc:dd:ee:ff
項目 今回の値 確認方法の例
検証PCのIPv4アドレス 192.168.10.10/24 Windows:ipconfig
デフォルトゲートウェイ 192.168.10.1 Windows:ipconfig
PCのMACアドレス 00:11:22:33:44:55 Windows:getmac または ipconfig /all
ARP確認対象 192.168.10.1 同一LAN上のルーター

パケットキャプチャーは、自分が管理する端末・検証環境、または許可を得たネットワークで実施してください。

業務ネットワークでは、通信内容や端末情報が含まれるため、取得範囲・保存先・共有方法にも注意が必要です。

WiresharkでARPを取得する手順

ARPキャッシュに対象のMACアドレスが残っていると、新しいARP Requestは発生しません。 そのため、現在のキャッシュを確認し、対象エントリーだけを削除してから通信を発生させます。

  1. 検証PCのIPアドレスとゲートウェイを確認する Windowsではコマンドプロンプトを開き、ipconfigを実行します。
  2. 現在のARPキャッシュを確認する arp -aを実行し、対象IPアドレスのエントリーがあるか確認します。
  3. 対象のARPキャッシュを削除する 管理者権限のコマンドプロンプトで、対象IPアドレスだけを削除します。
  4. Wiresharkで使用中のインターフェースを選ぶ EthernetまたはWi-Fiのうち、現在通信に使用しているインターフェースでキャプチャーを開始します。
  5. 表示フィルターへ arp を入力する ARPだけを表示し、RequestとReplyを見つけやすくします。
  6. 対象IPアドレスへpingを実行する 今回はデフォルトゲートウェイの192.168.10.1へpingを送ります。
  7. キャプチャーを停止し、2つのARPパケットを確認する 通常はRequestに続いてReplyが表示されます。

1.IP設定を確認する

Windows コマンドプロンプトIP設定の確認
C:\> ipconfig

イーサネット アダプター Ethernet:

   IPv4 アドレス . . . . . . . . . . : 192.168.10.10
   サブネット マスク . . . . . . . . : 255.255.255.0
   デフォルト ゲートウェイ . . . . . : 192.168.10.1

2.ARPキャッシュを確認・削除する

Windows コマンドプロンプトARPキャッシュの確認
C:\> arp -a

インターフェイス: 192.168.10.10 --- 0x8
  インターネット アドレス  物理アドレス          種類
  192.168.10.1             aa-bb-cc-dd-ee-ff     動的

対象エントリーが表示されている場合は、管理者権限で次のコマンドを実行します。

管理者権限のコマンドプロンプト対象エントリーの削除
C:\> arp -d 192.168.10.1

arp -d *で全エントリーを削除する方法もありますが、業務端末では不要な通信再発生につながります。 検証では、可能な限り対象IPアドレスだけを削除してください。

3.Wiresharkでキャプチャーを開始する

Wiresharkを起動し、通信量のグラフが動いているインターフェースを選択します。 キャプチャー開始後、表示フィルターへ次を入力します。

Wireshark 表示フィルターARPのみ表示
arp

ARPの後に続くpingまで一緒に確認したい場合は、次の表示フィルターを使用します。

Wireshark 表示フィルターARPとICMPを表示
arp || icmp

4.pingで通信を発生させる

Windows コマンドプロンプト通信の発生
C:\> ping 192.168.10.1

ARPキャッシュが削除されていれば、最初のICMP Echo Requestを送る前にARPによるMACアドレス解決が発生します。

Wireshark – Packet List
arp || icmp
No. Time Source Destination Protocol Info
1 0.000000 192.168.10.10 Broadcast ARP Who has 192.168.10.1? Tell 192.168.10.10
2 0.000846 192.168.10.1 192.168.10.10 ARP 192.168.10.1 is at aa:bb:cc:dd:ee:ff
3 0.001118 192.168.10.10 192.168.10.1 ICMP Echo (ping) request
4 0.001509 192.168.10.1 192.168.10.10 ICMP Echo (ping) reply

一覧の流れがARP Request → ARP Reply → ICMP Echo Request → ICMP Echo Replyとなっていれば、 MACアドレスを解決してからpingが開始されたことを確認できます。

ARP Requestの読み方

ARP Requestは、問い合わせ対象のMACアドレスが分からない状態で送信します。 どの機器が対象IPアドレスを持っているか分からないため、Ethernetフレームの宛先MACアドレスは ブロードキャストになります。

ARP Request – Packet Details
  • ▼ Ethernet II
  • Destination: ff:ff:ff:ff:ff:ff (Broadcast)
  • Source: 00:11:22:33:44:55
  • Type: ARP (0x0806)
  • ▼ Address Resolution Protocol (request)
  • Hardware type: Ethernet (1)
  • Protocol type: IPv4 (0x0800)
  • Hardware size: 6
  • Protocol size: 4
  • Opcode: request (1)
  • Sender MAC address: 00:11:22:33:44:55
  • Sender IP address: 192.168.10.10
  • Target MAC address: 00:00:00:00:00:00
  • Target IP address: 192.168.10.1

確認ポイント1:Ethernetの宛先はブロードキャスト

Ethernet IIのDestinationはff:ff:ff:ff:ff:ffです。 同じブロードキャストドメインにいる機器へ広く配信し、対象IPアドレスを持つ機器に応答を求めます。

確認ポイント2:Opcodeはrequest(1)

ARPヘッダーのOpcodeが1であればARP Requestです。 Wiresharkではrequest (1)と表示されます。

確認ポイント3:Target MAC addressはゼロ

Requestを送る時点では対象MACアドレスが分からないため、ARPヘッダー内のTarget MAC addressは 00:00:00:00:00:00です。

Ethernetヘッダーの宛先MACと、ARPヘッダー内のTarget MACは別の項目です。

Requestでは、Ethernetの宛先はff:ff:ff:ff:ff:ff、ARP内のTarget MACは 00:00:00:00:00:00となる点を区別してください。

Info欄を日本語にするとどうなるか

Wiresharkの表示 意味
Who has 192.168.10.1? 192.168.10.1を持つ機器は誰か
Tell 192.168.10.10 回答は192.168.10.10へ返してほしい

ARP Replyの読み方

Requestを受信した機器のうち、Target IP addressを自分が持っている機器がReplyを返します。 Requestから送信元PCのMACアドレスが分かるため、Replyは通常、そのPCだけを宛先としたユニキャストです。

ARP Reply – Packet Details
  • ▼ Ethernet II
  • Destination: 00:11:22:33:44:55
  • Source: aa:bb:cc:dd:ee:ff
  • Type: ARP (0x0806)
  • ▼ Address Resolution Protocol (reply)
  • Hardware type: Ethernet (1)
  • Protocol type: IPv4 (0x0800)
  • Hardware size: 6
  • Protocol size: 4
  • Opcode: reply (2)
  • Sender MAC address: aa:bb:cc:dd:ee:ff
  • Sender IP address: 192.168.10.1
  • Target MAC address: 00:11:22:33:44:55
  • Target IP address: 192.168.10.10

確認ポイント1:Ethernetの宛先はPC-AのMACアドレス

ReplyのDestinationは00:11:22:33:44:55です。 Requestの送信元MACアドレスを使い、問い合わせ元へ直接返しています。

確認ポイント2:Opcodeはreply(2)

ARPヘッダーのOpcodeが2であればARP Replyです。 Requestの1とセットで覚えると判断しやすくなります。

確認ポイント3:Sender MACが求めていた答え

ReplyのSender IP addressが192.168.10.1、Sender MAC addressが aa:bb:cc:dd:ee:ffです。つまり、PC-Aが知りたかった対応関係は次のとおりです。

ARPで学習する対応関係

192.168.10.1 = aa:bb:cc:dd:ee:ff

このReplyを受信したPC-Aは、対応関係をARPキャッシュへ一定時間保存します。 直後の通信ではキャッシュを利用できるため、毎回ARP Requestを送る必要はありません。

ARPヘッダーの各フィールド

障害切り分けでは、Info欄だけでなくARPヘッダーの詳細も確認できると、 「誰が、何を問い合わせ、誰へ答えたか」を正確に整理できます。

フィールド 今回の値 意味
Hardware type Ethernet(1) 使用するリンク層の種類
Protocol type IPv4(0x0800) 解決対象となるネットワーク層プロトコル
Hardware size 6 MACアドレスの長さ。6バイト
Protocol size 4 IPv4アドレスの長さ。4バイト
Opcode Request=1/Reply=2 問い合わせか応答かを識別
Sender MAC address 送信者のMAC このARPを送信した機器のMACアドレス
Sender IP address 送信者のIPv4 このARPを送信した機器のIPv4アドレス
Target MAC address Requestでは通常ゼロ 対象機器のMACアドレス
Target IP address 調べたいIPv4 MACアドレスを知りたい対象IPアドレス

EtherTypeにも注目する

Ethernet IIヘッダーのTypeは0x0806です。これは、Ethernetフレームの中身がARPであることを示します。 一方、ARPヘッダー内のProtocol typeは0x0800で、解決対象がIPv4であることを示します。

Ethernet Type:0x0806

このEthernetフレームのペイロードがARPであることを表します。

ARP Protocol type:0x0800

ARPによって対応するアドレスを調べるネットワーク層プロトコルがIPv4であることを表します。

どちらにも「Type」が登場しますが、確認している階層と意味が異なります。 パケット詳細では、どのヘッダー内の項目かを意識してください。

別セグメント宛て通信では誰をARPするのか

ARPで最も重要な理解ポイントの一つが、別ネットワーク上のサーバーへ通信するときの動作です。

重要

宛先が別セグメントにある場合、PCは遠隔サーバーのMACアドレスではなく、 次にパケットを渡すデフォルトゲートウェイのMACアドレスをARPで調べます。

別セグメント上のWebサーバーへ通信する例

💻 PC-A 192.168.10.10/24
🌐 デフォルトゲートウェイ 192.168.10.1/24
🗄️ Webサーバー 203.0.113.20
ARP対象 Who has 192.168.10.1? Tell 192.168.10.10
IP宛先 IPパケットのDestinationは 203.0.113.20
通信先 ARPで調べる対象 理由
同一セグメント上の端末 最終宛先端末のMACアドレス Ethernetフレームをその端末へ直接届けるため
別セグメント上の端末 デフォルトゲートウェイのMACアドレス まずルーターへEthernetフレームを渡すため

サブネットマスク設定ミスがARPに現れることがある

PCのサブネットマスクが誤って広く設定されていると、本来は別セグメントにあるIPアドレスを 「同一セグメントにいる」と判断し、その遠隔IPアドレスへARP Requestを送ることがあります。

例:PCが192.168.10.10/16と誤設定されている場合、192.168.20.50を同一セグメントと判断し、 ゲートウェイではなく192.168.20.50自身をARPしようとします。

Requestが繰り返されてもReplyが返らず、通信できません。パケットからサブネットマスク設定ミスを疑える典型例です。

ARPが表示されないときの確認ポイント

pingを実行してもARPが表示されない場合、必ずしも異常とは限りません。 まず、端末がすでにMACアドレスを知っていないか確認します。

原因1:ARPキャッシュが残っている

対象IPとMACの対応関係がキャッシュにあるため、新しいRequestを送らずに通信できます。 arp -aで確認し、対象エントリーを削除して再試行します。

原因2:別のインターフェースをキャプチャーしている

有線LANで通信しているのにWi-Fiを選択しているなど、実際の送信インターフェースとキャプチャー対象が一致していない可能性があります。

原因3:表示フィルターが誤っている

arp以外の条件が組み合わさっていると、取得済みでも表示されない場合があります。一度フィルターを削除して確認します。

原因4:通信が発生していない

pingコマンドの対象IPを間違えた、コマンドが実行されていない、アプリケーションがキャッシュを利用しているなどを確認します。

キャッシュあり・なしの違い

状態 最初に見えるパケット 説明
ARPキャッシュなし ARP Request MACアドレスを解決してからIP通信を開始する
ARPキャッシュあり ICMPやTCPなど 保存済みMACアドレスを使用するためARPを省略できる

ARPを使った障害切り分け

ARPは、Layer 2とLayer 3の境界を確認するうえで非常に有効です。 パケットの有無とRequest/Replyの組み合わせから、確認範囲を段階的に絞り込みます。

ARP Request
送信されるか
ARP Reply
返るか
IPパケット
送信されるか
応答
戻るか
1RequestもReplyも見えない

主な確認ポイント

  • 正しいインターフェースをキャプチャーしているか
  • 対象IPのARPキャッシュが残っていないか
  • 端末が対象を同一セグメントと判断しているか
  • 通信を実際に発生させているか
  • 表示フィルターで除外していないか
2Requestは出るがReplyが返らない

主な原因候補

  • 対象機器が停止している、またはネットワークへ接続されていない
  • PCと対象機器が異なるVLANに所属している
  • アクセスポートのVLAN設定、トランク許可VLAN、無線LANの収容先が誤っている
  • 対象IPアドレスが誤っている、または重複・未設定である
  • PCのサブネットマスクが誤り、本来は遠隔のIPを直接ARPしている
  • ポートセキュリティ、Dynamic ARP Inspection、端末間分離などで通信が制限されている

同じRequestが一定間隔で繰り返される場合、端末は「MACアドレスを解決できず、再問い合わせしている」と判断できます。

3Replyは返るがpingが失敗する

分かったこと

  • 対象IPとMACの対応関係は解決できている
  • ARPを送受信できる範囲のLayer 2到達性はある

次に確認する項目

  • PCと対象のIPアドレス、サブネットマスク
  • ICMPを拒否する端末ファイアウォール
  • ACL、ファイアウォールポリシー、ルーティング
  • 戻り経路
4異なるMACアドレスからReplyが返る

主な原因候補

  • IPアドレスが重複している
  • VRRPやHSRPなどの仮想MACアドレスを使用している
  • Proxy ARPが動作している
  • 機器交換・冗長切り替え後にMACアドレスが変化した
  • ARPスプーフィングなど、不正なARP応答が発生している

IPアドレスとMACアドレスの対応が短時間に何度も変化する場合は、単純な通信障害だけでなく、 IP重複、冗長化動作、セキュリティインシデントも含めて調査します。

現場での確認順序

  1. 端末のIPアドレス・サブネットマスク・デフォルトゲートウェイを確認する
  2. ARPキャッシュに期待するIPとMACの対応があるか確認する
  3. WiresharkでRequestの送信を確認する
  4. Replyの有無と送信元MACを確認する
  5. Reply後にICMP、TCP、UDPなどのIP通信が続いているか確認する
  6. スイッチのMACアドレステーブルやVLAN設定と照合する

調査結果の報告例

【事象】
PC-Aからデフォルトゲートウェイ 192.168.10.1 へ通信できない。

【確認結果】
・PC-AからARP Requestは送信されている。
・RequestのTarget IP addressは192.168.10.1で正しい。
・同一Requestが再送されているが、ARP Replyは確認できない。
・PC-AのIPアドレス/サブネットマスクは設計値と一致している。

【判断】
PC-AはゲートウェイのMACアドレスを解決できていない。
PC-AからRequestを送信できているため、ゲートウェイ側の停止、VLAN不一致、
または途中スイッチの収容設定に原因がある可能性が高い。

【次の確認】
・ゲートウェイインターフェースの稼働状態
・PC-A接続ポートとゲートウェイ接続ポートのVLAN
・スイッチのMACアドレステーブル
・ポートセキュリティ/ARP検査機能のログ

Gratuitous ARPとARP Probe

WiresharkでARPを見ていると、通常の「相手のMACアドレスを知りたい」という通信以外も表示されます。 代表的なものがGratuitous ARPとARP Probeです。

Gratuitous ARP

自分自身のIPアドレスとMACアドレスの対応を周囲へ通知するARPです。 IP重複の検知、ARPキャッシュの更新、冗長ゲートウェイ切り替え後の通知などに利用されます。

Wiresharkでは、Sender IPとTarget IPが同じアドレスになっているパケットとして見えることがあります。

ARP Probe

端末がIPアドレスを正式に使用する前に、そのIPアドレスがすでに使われていないか確認するためのARPです。

送信元IPアドレスが0.0.0.0、Target IPが確認したい候補アドレスとして表示されます。

冗長化切り替え時にARPを見る

VRRPやHSRPなどでアクティブ機器が切り替わると、仮想IPに対応するMACアドレスの情報を更新するため、 Gratuitous ARPが送信されることがあります。

切り替え後も通信が旧機器へ向かう場合、Gratuitous ARPが送信されたか、端末やスイッチのテーブルが更新されたかを パケットと機器情報の両方から確認します。

Gratuitous ARPは実装や製品によってRequest形式・Reply形式など見え方が異なる場合があります。 単にOpcodeだけで判断せず、Sender IP、Target IP、MACアドレス、送信タイミングを合わせて確認してください。

理解度チェック

記事の内容を確認するため、次の5問に答えてください。

問題1.通常のARP Requestで、Ethernetヘッダーの宛先MACアドレスはどれですか。

  1. 00:00:00:00:00:00
  2. ff:ff:ff:ff:ff:ff
  3. 送信元PCのMACアドレス
  4. 遠隔サーバーのMACアドレス
解答を見る
正解:B

対象MACが不明なため、同じブロードキャストドメインへブロードキャストで問い合わせます。

問題2.ARP RequestのARPヘッダー内にあるTarget MAC addressは、通常どの値ですか。

  1. ff:ff:ff:ff:ff:ff
  2. 00:00:00:00:00:00
  3. デフォルトゲートウェイのMACアドレス
  4. 送信元PCのMACアドレス
解答を見る
正解:B

Request時点では対象MACアドレスが分からないため、ゼロで表現されます。

問題3.別セグメント上の203.0.113.20へ通信するとき、PCが通常ARPで調べる対象はどれですか。

  1. 203.0.113.20のMACアドレス
  2. DNSサーバーのMACアドレス
  3. デフォルトゲートウェイのMACアドレス
  4. 自分自身のMACアドレス
解答を見る
正解:C

PCは最初にIPパケットを渡す次ホップであるデフォルトゲートウェイのMACアドレスを解決します。

問題4.ARP Requestは確認できるものの、同じRequestが繰り返され、Replyがありません。何が分かりますか。

解答を見る

送信元端末は対象IPのMACアドレスを解決できていません。 対象機器停止、VLAN不一致、IP設定誤り、サブネットマスク誤り、セキュリティ機能による制御などを確認します。

問題5.ARP Replyは正常に返っていますが、pingは失敗します。次に確認すべき項目を3つ挙げてください。

解答を見る

回答例:

  • 送信元・宛先のIPアドレスとサブネットマスク
  • 端末ファイアウォールによるICMP拒否
  • ACLやファイアウォールポリシー
  • ルーティングと戻り経路

実践演習:ARPパケットから通信状態を判断する

演習1.正常なRequestとReplyを取得する

自分のPCで次の手順を実施してください。

  1. ipconfigでデフォルトゲートウェイを確認する
  2. arp -aで現在のARPキャッシュを確認する
  3. 対象エントリーを削除する
  4. Wiresharkで使用中インターフェースのキャプチャーを開始する
  5. 表示フィルターへarp || icmpを入力する
  6. デフォルトゲートウェイへpingする
  7. RequestとReplyの各フィールドを記録する
記録項目: RequestのSender IP/Sender MAC/Target IP/Ethernet Destination ReplyのSender IP/Sender MAC/Target IP/Ethernet Destination
確認すべきポイントを見る
  • RequestのEthernet Destinationがff:ff:ff:ff:ff:ff
  • RequestのOpcodeが1
  • RequestのTarget MACが00:00:00:00:00:00
  • ReplyのEthernet Destinationが自分のPCのMACアドレス
  • ReplyのOpcodeが2
  • ReplyのSender MACがゲートウェイのMACアドレス
  • ARP完了後にICMP Echo Requestが送信される

演習2.パケット一覧を読み取る

次のパケットが取得されました。

Exercise Capture
arp
No. Time Source Destination Protocol Info
10 0.000000 192.168.30.25 Broadcast ARP Who has 192.168.30.1? Tell 192.168.30.25
11 1.018453 192.168.30.25 Broadcast ARP Who has 192.168.30.1? Tell 192.168.30.25
12 2.041725 192.168.30.25 Broadcast ARP Who has 192.168.30.1? Tell 192.168.30.25

質問:この端末で何が起きていますか。原因候補を3つ挙げてください。

ここに判断と原因候補を書いてください。
解答例を見る

192.168.30.25は、192.168.30.1のMACアドレスを問い合わせていますが、Replyを受信できず再送しています。 そのため、ゲートウェイへEthernetフレームを送信できません。

原因候補:

  • 192.168.30.1のインターフェースが停止している
  • PCとゲートウェイが異なるVLANに収容されている
  • ゲートウェイIPアドレスが誤っている
  • 途中スイッチのアクセスポート/トランク設定が誤っている
  • 端末間分離やARP検査機能によって通信が破棄されている

演習3.別セグメント通信のARP対象を答える

PC-Aの設定は次のとおりです。

PC-A10.10.10.20/24
デフォルトゲートウェイ10.10.10.1
通信先サーバー10.20.20.50

質問:PC-Aが最初にARPでMACアドレスを調べるIPアドレスはどれですか。また、その理由を説明してください。

ARP対象:__________ 理由:________________________
解答を見る

ARP対象:10.10.10.1

10.20.20.50はPC-Aと異なるセグメントにあるため、PC-Aは最終宛先のMACアドレスを直接調べません。 最初にIPパケットを渡す次ホップであるデフォルトゲートウェイ10.10.10.1のMACアドレスをARPで解決します。

自分の言葉で説明する課題

後輩から「別ネットワークのWebサーバーへアクセスするのに、なぜゲートウェイへARPするのですか」と質問されました。 60秒程度で説明してください。

ここに自分の説明を書いてください。
説明例を見る

ARPは、同じリンク上で次にEthernetフレームを渡す相手のMACアドレスを調べるために使います。 Webサーバーが別ネットワークにある場合、PCはサーバーへ直接フレームを届けられません。 まず同じネットワークにいるデフォルトゲートウェイへフレームを渡し、ルーターに中継してもらいます。 そのため、IPパケットの宛先はWebサーバーのままですが、Ethernetフレームの宛先MACはゲートウェイになります。

まとめ

  • ARPは、IPv4アドレスと同一リンク上で使用するMACアドレスの対応を解決する
  • ARP RequestはEthernetブロードキャストで送信され、Opcodeは1
  • RequestのEthernet宛先はff:ff:ff:ff:ff:ff、ARP内のTarget MACは通常00:00:00:00:00:00
  • ARP Replyは通常、問い合わせ元へユニキャストで返され、Opcodeは2
  • 別セグメント宛て通信では、最終宛先ではなくデフォルトゲートウェイのMACアドレスをARPで調べる
  • Requestだけが繰り返される場合、MACアドレスを解決できていない
  • Reply後に通信できない場合は、IP設定、ICMP制御、ACL、ファイアウォール、ルーティングへ確認を進める
  • ARPが見えない場合は、ARPキャッシュ、キャプチャー対象インターフェース、表示フィルターを確認する

ARPパケットを読めるようになると、「通信できない」をLayer 2の到達性と、その後のIP通信に分けて調査できます。

次の記事:TCP通信をパケットで確認する

今回は、IP通信を始める前に必要となるARP RequestとARP Replyを確認しました。

次の記事では、TCPの3ウェイハンドシェイク、シーケンス番号、ACK番号、フラグをWiresharkで確認し、 TCP接続がどの段階で失敗しているかをパケットから判断する方法を学びます。

ネットワーク中級編 33/全50記事

中級編では、構築・検証・障害切り分けに必要な技術を、設定、コマンド出力、パケット、報告の順に学びます。

よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!

この記事を書いた人

コメント

コメントする

目次