はじめに

インフラエンジニアとしてプロトコル（TCP/IPやOSI参照モデル）の勉強をしていると、教科書に必ず出てくる 「3ウェイハンドシェイク」 。
文字面では理解していても、「本当に裏でそんな握手が行われているのか？」を自分の目で確かめたくなり、パケット解析ツール Wireshark を使って実験してみました。

今回は、画面が1枚（シングルモニター）しかなく、VMwareなどの仮想環境とWindowsを行き来するのが手狭だったため、Windows上でサクサク動く WSL2（Kali Linux） を使って環境を構築しました。

手動でのパケット発生から、GUIでの解析、さらに実務を見据えた tshark によるCUI解析までの一連の流れをまとめます。

1. 環境構築と Permission denied との戦い

まずはKali LinuxにWiresharkをインストールします。

sudo apt update
sudo apt install -y wireshark

💡 インフラエンジニア視点での設定選択

インストール中に、いくつか青い設定画面（CUI）が出現します。実務を意識して以下のように選択しました。

一般ユーザーにパケットキャプチャ権限を付与するか？
- <Yes> を選択。毎回 sudo で起動するのはセキュリティ上および運用の観点から避けるため。
libc6 のアップデートに伴う確認画面（サービス自動再起動の許可）
- <No> を選択。本番環境のサーバー運用を想定し、勝手に裏でサービス（cronなど）を落とされないよう、手動で確認する安全牌を選択。

🚨 遭遇したエラーと解決策

インストール後、バックグラウンド（&）でWiresharkを起動したところ、以下のエラーに直面しました。

Couldn't run dumpcap in child process: Permission denied

原因：
usermod でユーザーを wireshark グループに追加したものの、Linuxのセッションが古いままだったため権限が反映されていませんでした。

解決コマンド：
一度Kaliのターミナルを閉じ、WindowsのPowerShell等からWSL2の裏のエンジンを完全にシャットダウン（リセット）することで解決しました。

wsl --shutdown

再起動後、groups コマンドで末尾に wireshark が追加されているのを確認し、無事に起動に成功しました。

2. 実際にパケットをキャプチャしてみる

Wiresharkを起動し、ネットワークカード（eth0）を選択してキャプチャを開始します。

今のインターネットはほとんどが暗号化（HTTPS）されていて中身が見えないため、今回はあえて暗号化されていないテスト用の有名な海外サイト（http://neverssl.com）をターゲットにしました。

Windowsのブラウザからの通信はWSL2のネットワークの壁に阻まれることがあるため、Linuxのターミナルから直接 curl コマンドを使ってパケットを発生させるというアプローチを取りました。

curl http://neverssl.com

3. 発掘！3ウェイハンドシェイクとまさかのドラマ

キャプチャを止め、ディスプレイフィルタを外してタイムスタンプ順にログを追いかけたところ、教科書通りの芸術的な流れが完全に記録されていました。

🤝 ① 運命の3ウェイハンドシェイク

No.25 [SYN]：マイPC 172.24.183.44 ➔ サーバー 34.223.124.45
「もしもし！今からHTTPの通信したいので、回線繋いでもいいですか？」
No.27 [SYN, ACK]：サーバー ➔ マイPC
「いいですよ！こっちも準備できたよ！そっちもOKですか？」
No.28 [ACK]：マイPC ➔ サーバー
「こちらもOKです！じゃあ回線繋ぎますね！」

これでデータを安全に流すための土管（TCPコネクション）が開通。

🌐 ② 本題のHTTP通信

No.29 GET / HTTP/1.1
土管が開通した直後、HTTPプロトコルが走り出し、「トップページのデータをください！」とリクエスト（GET）を送っています。

⚡ 【見どころ】裏で起きていた「TCP再転送（Retransmission）」

この検証中、非常に面白いハプニングが記録されていました。No.26 のログです。

[TCP Retransmission] 37936 → 80 [SYN]

No.25で最初の [SYN] を送った際、一瞬応答が遅れた（またはパケットが迷子になった）ため、TCPが自動的に「届かなかったかもしれないから、もう一回同じの送るわ！」と**再送処理（Retransmission）**を行っていました。
アプリケーション層（HTTP）が関知しないところで、トランスポート層（TCP）が必死に通信を保証しようとしているドラマを生々しく目撃できました。

4. 【実務の視点】GUIが使えない環境のために `tshark` で覗く

インフラの現場（特に本番環境のLinuxサーバー）では、GUIのWiresharkが使えないCUI環境のケースが多々あります。
そこで、Wiresharkで解析したログを一度 .pcapng 形式で保存し、コマンドライン版である tshark を使ってターミナル上でのパケット解析にも挑戦しました。

sudo apt install -y tshark
tshark -r handshake_test.pcapng

CUIでの出力結果

実行すると、見事にターミナル上にあの激闘のログが出力されました。

   25 3.837184450 172.24.183.44 → 34.223.124.45 TCP 74 37936 → 80 [SYN] Seq=0 Win=64240 Len=0...
   26 4.863800612 172.24.183.44 → 34.223.124.45 TCP 74 [TCP Retransmission] 37936 → 80 [SYN]...
   27 4.960372742 34.223.124.45 → 172.24.183.44 TCP 74 80 → 37936 [SYN, ACK] Seq=0 Ack=1...
   28 4.960547512 172.24.183.44 → 34.223.124.45 TCP 66 37936 → 80 [ACK] Seq=1 Ack=1...
   29 4.960733874 172.24.183.44 → 34.223.124.45 HTTP 142 GET / HTTP/1.1

さらにログをスクロールしていくと、裏で動いていた ARPパケット（IPアドレスからMACアドレスを割り出すために「172.24.183.44はどこ？」と叫んでいる通信）まで綺麗にテキストで追うことができました。

まとめ

教科書の中で「文字」としてしか見ていなかった3ウェイハンドシェイクやTCPリトランスミッション、ARPといったネットワークの基礎知識が、自分で環境を作ってパケットをのぞき見することで100倍リアルに理解できるようになりました。

「通信が遅い」「繋がらない」といった現場でのトラブルシューティングの際、このパケットレベルの視点を持っているかどうかで原因究明のスピードが全く変わってくる、という先輩方の言葉の重みが分かった気がします。

今後はDNSの挙動や、Ping（ICMP）のパケットなどもさらに深掘りしていきたいと思います！