ICMPの苛立たしい沈黙
先日、セキュリティが強化されたVPC環境において、2つのマイクロサービス間の接続トラブルの解決に週末を費やしました。従来のツールは役に立ちませんでした。標準的な ping を実行してもパケットロスが100%になる一方で、アプリケーションのログには「タイムアウト」ではなく「接続拒否（Connection refused）」が記録されていたのです。
現代のインフラでは、セキュリティチームが最初に無効化するのがICMP（pingの背後にあるプロトコル）であることがよくあります。traceroute で「Request timed out」というメッセージを眺めているだけでは、全容を把握することはできません。サーバーがダウンしているのか、ファイアウォールがパケットをドロップしているのか、あるいは特定のポートが頑固に拒絶しているのかが分からないからです。
そこで、過去6ヶ月間の本番運用において絶対的な救世主となったのが hping3 です。nmap は探索に、tcpdump はスニッフィングに優れていますが、hping3 は独自の立ち位置を占めています。これはコマンドライン指向のTCP/IPパケットアセンブラおよびアナライザです。想像しうるほぼすべてのパケットを作成できるため、ファイアウォールルールのテストや、標準的なツールでは不可能な深いネットワーク診断を行う際に不可欠なツールとなります。
hping3の理念を理解する
標準的なネットワーキングツールは、多くの場合「ハイレベル（高レイヤー）」です。curl はアプリケーションレイヤーをテストし、ping はネットワークレイヤー（ICMP）をテストしますが、hping3 はトランスポートレイヤーを直接操作できます。特定のポートにTCP SYNパケットを送信したり、ACK、FIN、RSTなどの特定のフラグを切り替えたり、さらには送信元IPアドレスを偽装（スプーフィング）して、異なる視点からファイアウォールがどのように反応するかを確認したりすることも可能です。
実務経験上、これは習得すべき不可欠なスキルの一つです。TCPスタックの言語を話せるようになることで、「ドロップ」（ファイアウォールが静かにパケットを破棄する）と「リジェクト」（ファイアウォールまたはホストが積極的にRST/ACKを返送する）を区別できるようになります。最も重要なのは、アプリケーションが使用しているのと同じプロトコルとポートを使用して診断を実行できるため、テスト内容が実際のトラフィックと確実に一致することです。
hping3を始める
ほとんどのLinuxディストリビューションには hping3 がデフォルトで含まれていませんが、標準リポジトリから簡単に利用できます。UbuntuやDebianでは、通常次のコマンドですぐに実行環境を整えることができます：
sudo apt-get update
sudo apt-get install hping3hping3 はパケットを作成するために生ソケット（raw socket）へのアクセスを必要とするため、ほとんどのコマンドを sudo で実行する必要があります。hping3 --help を実行すると膨大なオプションのリストが表示されますが、圧倒される必要はありません。多くの場合、作業を完了させるために使うフラグは一握りです。
実践：一般的な診断シナリオ
1. ICMPがブロックされている時のTCP接続テスト
サーバーが ping に応答しない場合、私は即座にTCP SYNプローブに切り替えます。これは標準的なTCP接続の開始を模倣したものです。ウェブサーバーがポート443で到達可能かどうかをテストするには、次のように入力します：
sudo hping3 -S -p 443 -c 4 1.2.3.4-S: SYNフラグを設定します。-p 443: 特定のポートをターゲットにします。-c 4: 4つのパケットのみを送信します（指定しない場合、pingのように無期限に実行されます）。
ポートが開いている場合は、flags=SA (SYN/ACK) を含む応答が表示されます。閉じている場合は、通常 flags=RA (RST/ACK) が表示されます。応答が全くない場合は、ファイアウォールがパケットをドロップしている可能性が高いでしょう。
2. ファイアウォールを回避するTCP Traceroute
標準の traceroute はUDPまたはICMPを使用します。経路上のファイアウォールがこれらをブロックしている場合、アスタリスク（* * *）の列が表示されるだけです。私は代わりに hping3 を使用して、中間ルーターを通過する可能性がはるかに高いTCPポート80または443経由でtracerouteを実行することを好みます。
sudo hping3 --traceroute -V -S -p 80 itfromzero.com--traceroute フラグは各パケットのTTL（Time to Live）をインクリメントし、どのホップがトラフィックをドロップしているかを正確に可視化します。-V (詳細表示) を使用するとヘッダーに関するより詳細な情報が得られ、微妙な設定ミスを探す際に役立ちます。
3. ACKプローブによるファイアウォールルールのテスト
ファイアウォールの動作をマッピングするために使用する高度なテクニックの一つに、ACKスキャンがあります。（確立された接続がない状態で）ACKフラグのみを設定したパケットを送信することで、ステートフル・インスペクションの挙動を確認できます。単純なステートレス・ファイアウォールはこれを通してしまうかもしれませんが、現代的なステートフル・ファイアウォールは通常、これらをドロップするかRSTを送信します。
sudo hping3 -A -p 80 1.2.3.4RST (Reset) パケットが返ってきた場合、そのポートはフィルタリングされていないが、接続が認識されていないことを意味することが多いです。応答がない場合は、ステートフル・ファイアウォールがトラフィックをフィルタリングしている強力な指標となります。
4. 負荷環境下でのレイテンシ測定
ネットワークが「ダウン」しているのではなく、単に「遅い」だけの場合があります。私は hping3 を使って、システムが大量の接続リクエストをどのように処理するかをテストしています。--fast や --flood フラグを使用すると、大量のトラフィックを生成して、どの時点でレイテンシが急増し始めるかを確認できます。
# 1秒間に10個のパケットを送信
sudo hping3 -S -p 80 -i u10000 1.2.3.4注意：--flood の使用には細心の注意を払ってください。CPUが生成できる限界の速さでパケットを送信するため、セキュリティチームからはDoS攻撃のように見えてしまいます。私は、ローカルのロードバランサーの性能をテストするために、制御された内部環境でのみこれを使用します。
出力の分析
hping3 の素晴らしさは、レスポンスの詳細にあります。返信があった際は、flags と window サイズに細心の注意を払ってください。window=0 の応答は、リモートホストがパケットを受信しているものの、バッファがいっぱいであることを示している可能性があり、ネットワークの問題ではなくアプリケーションレベルのボトルネックを示唆しています。また、同じIPからの応答で一貫性のないTTL値が見られる場合は、標準のpingでは決して気づかないようなロードバランシングや非対称ルーティングの問題を突き止めるヒントになります。
ネットワークの可視化に関する最終的な考察
このツールを使い続けた半年間を振り返ると、接続問題へのアプローチが根本から変わりました。なぜ接続が失敗しているのかを推測する代わりに、故障箇所がどこにあるのかを正確に証明できるようになったのです。AWSのセキュリティグループの設定ミスであれ、バグのある内部ルーターであれ、hping3 は単に問題を報告するだけでなく、解決するために必要な実証的な証拠を提供してくれます。
シニアエンジニアやSRE（サイト信頼性エンジニア）の役割を目指すなら、ハイレベルなツールだけに頼らないでください. ラボ環境で 1 時間 hping3 をいじってみてください。特殊なパケットを作成し、ローカルファイアウォールがどう反応するかを観察し、生の出力に慣れておきましょう。次に本番環境で「原因不明」のネットワークバグが発生したとき、このツールがツールキットにあることに感謝することになるはずです。
