ホワイトハッカーへの道 #11

 

Wiresharkでネットワークの裏側を探る！

 

DNS・IPv6・ARP・ICMPv6の実践解析


 

    学習記録：2026年10月30日のWiresharkキャプチャ

 


 


 

はじめに

 

    ホワイトハッカーを目指して、ネットワークの仕組みを

    基礎から学んでいます。

 

 

    今回はMacのWi-Fiインターフェース「en0」を使い、

    Wiresharkで実際の通信をキャプチャしました。

 

 

    普段何気なく使っているインターネット。

    その裏側ではIPアドレス、MACアドレス、DNS、UDP、

    ICMPなど、さまざまなプロトコルが連携しています。

 

 

    実際のパケットを一つずつ確認しながら、

    ネットワークの仕組みを調べていきます。

 


 


 

1. ARPでLAN内の機器を発見する

 

    ARP（Address Resolution Protocol）は、

    IPv4アドレスに対応するMACアドレスを調べる仕組みです。

 


  

Who has 192.168.1.6?
Tell 192.168.1.22


 

    この通信は、192.168.1.22の機器が

    192.168.1.6のMACアドレスを問い合わせています。

 


 

機器 IPv4アドレス
Mac 192.168.1.6
NECルーター 192.168.1.1
別のLAN機器 192.168.1.22

 


 

    ARP RequestとARP Replyの両方を確認できました。

    ただし、192.168.1.22が具体的にどの機器なのかは

    特定できていません。

 


 

2. DNSでドメイン名をIPアドレスに変換する

 

    次にDNS（Domain Name System）を解析しました。

 


  

a1319.dscr.akamai.net


 

DNS Responseでは次のIPv4アドレスが返されました。

 

       

  • 23.55.51.73

    •    

  • 23.55.51.98

    •  


 

AAAAレコードでは次のIPv6アドレスを確認しました。

 

       

  • 2600:140b:ac00::b81e:1ea1

    •    

  • 2600:140b:ac00::b81e:1eca

    •  


 

    DNSでIPアドレスが返ってきても、

    必ずそのIPアドレスへ通信するとは限りません。

    今回のキャプチャでは、これらのIPアドレスを宛先とする

    パケットは確認できませんでした。

 


 

3. DNSの応答時間を測定する


  

Transaction ID: 0x176f


Response Time: 10.023 milliseconds


Flags: 0x8180
Standard query response, No error


 

フラグ 値 意味
QR 1 DNS応答
AA 0 非権威応答
RD 1 再帰問い合わせ要求
RA 1 再帰問い合わせ対応
RCODE 0 エラーなし

 


 

    今回のDNS応答時間は約10ミリ秒でした。

    DNSには、問い合わせと応答を対応付ける

    Transaction IDが存在することも確認できました。

 


 

4. DNSの問い合わせ先はNECルーターだった

 

    DNS Queryの宛先IPv6アドレスとEthernetの宛先MACアドレスを調べました。

 

 

    MACアドレスは、以前確認したNECルーターのものと一致しました。

 

 

    つまり、MacからのDNS問い合わせは、

    NECルーター宛てに送信されていたことが分かります。

 

 

    ただし、ルーター自身が名前解決したのか、

    上流のDNSサーバーに転送したのかは確認できません。

 


 

5. UDPのポート番号を解析する


 

通信 送信元 宛先
DNS Query 50061 53
DNS Response 53 50061

 


 

    問い合わせと応答で、送信元と宛先の

    UDPポート番号が入れ替わっています。

 


  

Checksum: 0xe7d3 [correct]


 

    WiresharkでUDPチェックサム検証を有効にしたところ、

    正常と判定されました。

    ただし、チェックサムの正常性は通信相手の信頼性を保証しません。

 


 

6. パケットサイズを計算する


  

UDP Length: 79


IPv6 Payload Length: 79
Frame Length: 133


 

項目 サイズ
Ethernetヘッダー 14バイト
IPv6ヘッダー 40バイト
UDPヘッダー 8バイト
DNSデータ 71バイト
合計 133バイト

 


 

    14 + 40 + 8 + 71 = 133バイト。

    実際のフレーム長と計算結果が一致しました。

 


 

7. IPv6ヘッダーを解析する


 

項目 確認結果
Version 6
Traffic Class 0x00
DSCP CS0
ECN Not-ECT
Flow Label 0x63e09
Next Header UDP (17)
Hop Limit 64

 


 

    Flow Labelは、IPv6の通信フローを識別するためのフィールドです。

    今回はDNS QueryとResponseで異なる値が設定されていました。

 

 

    また、Hop LimitはIPv4のTTLに相当し、

    パケットがネットワーク内を無限に循環することを防ぎます。

 


 

8. IPv6のNeighbor Discoveryを調べる

 

    IPv6では、ARPの代わりに

    Neighbor Discovery Protocol（NDP）が使われます。

 


  

icmpv6.type == 135


 

    このフィルターでNeighbor Solicitationが3件見つかりました。

 


 

1件目のパケットは次のとおりです。


  

Source:


fe80::cc0:26d8:bb7a:4d1f





Destination:


fe80::10ff:8775:b761:af8a





Target Address:
fe80::10ff:8775:b761:af8a


 

    送信元と宛先はリンクローカルアドレスです。

    宛先とTarget Addressが一致しており、

    特定の近隣機器に対するユニキャスト通信でした。

 

 

    近隣機器の到達可能性確認（NUD）と整合しますが、

    このパケットだけでは目的を断定できません。

 


 

9. Neighbor DiscoveryのHop Limitは255


  

Hop Limit: 255


 

    Neighbor Discoveryでは、受信したパケットの

    Hop Limitが255であることが要求されます。

 

 

    ルーターを経由して転送されるとHop Limitが減少するため、

    リンク外からのNeighbor Discoveryメッセージを

    排除するために利用されます。

 

 

    ただし、同じLAN内の機器による偽装を

    防止できるわけではありません。

 


 


 

10. 今回の学習で分かったこと


 

       

  • ARPによるIPv4とMACアドレスの対応

    •    

  • DNSのAレコードとAAAAレコード

    •    

  • DNS QueryとResponseの対応付け

    •    

  • UDPのポート番号とチェックサム

    •    

  • Ethernet・IPv6・UDP・DNSのデータ構造

    •    

  • IPv6のFlow LabelとHop Limit

    •    

  • ICMPv6によるNeighbor Discovery

    •  


 

    Wiresharkでパケットを一つずつ確認すると、

    教科書で学んだネットワークの仕組みが、

    実際の通信として見えてきます。

 

 

    特に重要だと感じたのは、

    確認できた事実と、まだ確認できていないことを区別すること

    です。

 

 

    ホワイトハッカーに必要なのは、

    ツールを操作する技術だけではありません。

    取得したデータを正しく読み取り、

    根拠を持って判断する力も必要だと思います。

 


 

次回に向けて

 

    次はNeighbor Advertisement（NA）を解析し、

    IPv6の近隣機器がどのように応答するのかを調べます。

 

 

    さらに、LAN内の不審な通信を発見する方法についても

    学んでいきたいと思います。

 


 

ホワイトハッカーへの道は、まだまだ続きます！


 


 

参考資料

 


 

    本記事は2026年10月30日に取得したWiresharkキャプチャをもとに作成しました。

    ネットワーク機器の識別情報は公開用に一部省略しています。