Ping疎通可能でもTCP接続が失敗する境界領域のトラブルシューティング

Fri, 09 Oct 2026 10:46:32 +0900

インフラストラクチャの運用において、「Pingは通るが、サーバーへの接続（SSHやHTTPなど）が失敗する」という事象は頻繁に発生します。ICMPによるL3レベルの疎通確認のみに依存し、L4以上のトランスポート層やL7アプリケーション層の検証を怠ることは、障害復旧の遅延や誤った原因特定を招く要因となります。

ICMPエコーテストは低レイテンシかつパケットロス0%で成功している状態を示します。

$ ping 192.168.10.100
PING 192.168.10.100 (192.168.10.100) 56(84) bytes of data.
64 bytes from 192.168.10.100: icmp_seq=1 ttl=64 time=0.3 ms
64 bytes from 192.168.10.100: icmp_seq=2 ttl=64 time=0.2 ms

しかし、SSHセッションやHTTPリクエストを開始すると、接続に失敗します。

$ ssh 192.168.10.100
ssh: connect to host 192.168.10.100 port 22: Connection refused

あるいは、接続試行時にタイムアウトが発生します。

$ curl http://192.168.10.100:8080
curl: (7) Failed to connect to 192.168.10.100 port 8080: Connection timed out

「Pingが成功したためネットワークは正常であり、接続失敗はサーバー自体の破損を意味する」という仮定は、技術的に誤りです。ICMPはネットワーク層（L3）で動作するのに対し、SSH、HTTP、HTTPS、PostgreSQL、MySQL、Redisなどの主要なアプリケーションプロトコルは、特定のポート番号にバインドされたトランスポート層（L4）のTCPソケットに依存しているためです。

本稿では、この境界ギャップを体系的に分解し、Linuxの3つのコアユーティリティである ss、nc、tcpdump を中心とした診断手法を確立します。

1. ネットワーク層の抽象化とサービスマッピング

💡 通信のボトルネックを効果的に特定するために、対象サービスをOSI参照モデルの各レイヤーとトランスポートメカニズムにマッピングします。

ICMP: ping などの診断および制御メッセージングにのみ使用されます（トランスポートポートは存在しません）。
SSH: TCP ポート 22
HTTP: TCP ポート 80
HTTPS: TCP ポート 443
PostgreSQL: TCP ポート 5432
MySQL / MariaDB: TCP ポート 3306
Redis: TCP ポート 6379

ICMPはL4のTCPリスニングソケットとは独立して動作するため、ICMPエコーリクエストに対する応答があっても、TCPポートが開放されている、あるいは到達可能である保証はありません。

2. `ping` の低レイヤーメカニズム

ping 192.168.10.100 を実行すると、宛先ホストに対して ICMP Echo Request パケット（Type 8）が送信され、宛先ホストは ICMP Echo Reply パケット（Type 0）を返します。

+------------------------+ +------------------------+
| Client: 192.168.10.50 | | Server: 192.168.10.100 |
+------------------------+ +------------------------+
 | |
 |------------ ICMP Echo Request (Type 8) -------------&gt;|
 | |
 |&lt;----------- ICMP Echo Reply (Type 0) ----------------|
 | |

Ping of 成功は、クライアントからローカルルーティング、ゲートウェイ、物理ネットワーク、ターゲットのIPスタックを経て、ICMP応答が戻るパスが正常であることを確認するに留まります。ファイアウォールルールがTCPフレームを許可しているか、あるいはホスト上のアプリケーションデーモンがアクティブにソケットを処理しているかは検証できません。

3. TCP 3-Way ハンドシェイクの構造

TCPベースのサービス接続を開始する際、オペレーティングシステムのカーネルは、まず TCP 3-Way ハンドシェイク を介してステートフルな接続を確立する必要があります。

Client (192.168.10.50) Server (192.168.10.100:22)
 | |
 |----------------------- 1. SYN ------------------------------&gt;|
 | |
 |&lt;------------------- 2. SYN-ACK ------------------------------|
 | |
 |----------------------- 3. ACK ------------------------------&gt;|
 | |
[ ESTABLISHED ] [ ESTABLISHED ]

SYN: クライアントは接続開始を要求するために、SYN フラグを設定したTCPフレームを送信します。
SYN-ACK: サーバーは SYN を受信すると、ポート 22 でリスニングしているソケットを確認し、接続状態バッファを割り当てて SYN-ACK で応答します。
ACK: クライアントは ACK で応答し、両方のエンドポイントが ESTABLISHED 状態に移行します。

アプリケーションプロトコルが機能するためには、このL4シーケンスが正常に完了する必要があります。

4. 「Ping疎通可能＋ TCP接続失敗」の診断

初期の診断状態を定義します。

$ ping 192.168.10.100
# 成功 (パケットロス 0%)

$ nc -zv 192.168.10.100 22
# 失敗

この不一致により、障害ドメインを即座に絞り込むことができます。ICMPが機能していることはL3ルーティングと物理リンクが正常であることを示し、TCPの失敗はL4ソケット、ファイアウォール、またはサービスデーモンの障害を示します。

5. `nc` (Netcat) によるトランスポート層のプロービング

Netcat (nc) は、TCPおよびUDPの接続アナライザーとして機能します。実務環境における主なユースケースは、特定のソケットアドレスに対する生のTCP到達性を検証することです。

Netcatの実行には、ポートスキャン用のオプションを指定します。

$ nc -zv 192.168.10.100 22

-z`: Zero-I/Oモード（ペイロードデータを送信せずにリスニングデーモンをスキャン）。

-v: 詳細出力モード。

接続テストの実行結果から、ネットワークの状態を判定します。

ハンドシェイク成功:

Connection to 192.168.10.100 22 port [tcp/ssh] succeeded!

失敗パターン A:

nc: connect to 192.168.10.100 port 22 failed: Connection refused

失敗パターン B:

nc: connect to 192.168.10.100 port 22 failed: Connection timed out

Connection Refused と Connection Timed Out の違いを理解することは、根本原因の特定において極めて重要です。

6. Connection Refused と Connection Timeout のメカニズム

Connection Refused の仕組み

⚠️ Connection refused エラーは、クライアントの SYN パケットが宛先ホストのカーネルに到達したものの、ホストが明示的に接続を拒否し、TCP Reset (RST) フレームを返したことを示します。

Client Server
 | |
 |--------------------------- SYN ----------------------------&gt;| (宛先ホストに到達)
 | | (リスニング中のプロセスなし)
 |&lt;------------------------ TCP RST ---------------------------|

主な原因:

サービスデーモンの停止: プロセス（sshd、nginx、mysqld など）が起動していません。
誤ったサービスポート: アプリケーションがデフォルト以外のポート（例：22 ではなく 2222）でリスニングしています。
バインドインターフェースの不整合: デーモンが 0.0.0.0 ではなく 127.0.0.1 のみにバインドされています。
アクティブなパケットフィルタリング: ローカルホストのファイアウォールが、パケットを破棄（DROP）するのではなく、明示的にTCP Resetパケットを返す（REJECT）ように設定されています。

Connection Timeout の仕組み

Connection timed out エラーは、クライアントが SYN パケットを送信したものの、ソケットのタイムアウトしきい値が経過するまでに応答が一切返ってこなかった場合に発生します。

Client Network / Firewall / Target
 | |
 |--------------------------- SYN ----------------------------&gt;|
 | | ===&gt; [ 破棄 / ブロック ]
 | (応答なし) |
 | ... タイムアウト ... |

主な原因:

ネットワークセキュリティによる破棄: クラウドのセキュリティグループ、ネットワークACL、またはハードウェアファイアウォールがインバウンドトラフィックをサイレントに破棄しています。
ホストレベルのファイアウォールによる破棄: iptables、firewalld、または nftables が DROP アクションで設定されています。
ルーティング障害: 中間ネットワークスイッチやルーターにおけるデフォルトルーティングの誤り、または静的ルートの欠落。
非対称ルーティング / 戻りパスの失敗: サーバーは SYN を受信して SYN-ACK を送信したものの、戻りパスのルーティングでパケットが破棄または誤送信されています。

7. `ss` によるローカルソケットの検査

ss (Socket Statistics) ユーティリティは、Linuxプラットフォーム上のアクティブな内部ソケットを検査し、従来の netstat ツールに代わるものとして使用されます。

ソケットの状態を確認するための診断コマンドを実行します。

$ sudo ss -lntp

フラグ仕様:

-l: リスニング（LISTEN）状態のソケットのみを表示。
-n: 数値アドレスとポートを表示（DNSやサービス名の解決によるオーバーヘッドを防止）。
-t: TCPソケットを表示。
-p: ソケットに関連付けられたプロセスIDと名前を表示（root または sudo 権限が必要）。

コマンドの実行により、以下のようなソケット情報が出力されます。

State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
LISTEN 0 128 0.0.0.0:22 0.0.0.0:* users:(("sshd",pid=1234,fd=3))
LISTEN 0 128 0.0.0.0:80 0.0.0.0:* users:(("nginx",pid=1500,fd=6))
LISTEN 0 128 127.0.0.1:8080 0.0.0.0:* users:(("java",pid=2000,fd=20))

8. バインドアドレスの分析: `127.0.0.1` vs `0.0.0.0`

Local Address:Port のバインド設定は、外部からの到達性を決定します。

ループバック隔離ケース (`127.0.0.1:8080`)

ソケットがループバックアドレスにのみバインドされている状態を示します。

LISTEN 0 128 127.0.0.1:8080 0.0.0.0:*

アプリケーションプロセス（java）は ループバックインターフェース（lo） にのみバインドされています。

[ 外部クライアント ] [ ターゲットサーバー ]
 192.168.10.50 192.168.10.100
 | |
 |--- 192.168.10.100:8080 へのHTTPリクエスト ------&gt;| [ 物理インターフェース ]
 | |
 | (ブロック / ソケットなし)
 | v
 | [ ループバックインターフェース ]
 | 127.0.0.1:8080 (Javaデーモン)

ローカル検証: サーバー上で curl http://127.0.0.1:8080 を実行すると成功します。

リモート検証: 外部クライアントから curl http://192.168.10.100:8080 を実行すると失敗します。

ワイルドカードIPv4バインド (`0.0.0.0:8080`)

ソケットがすべてのインターフェースにバインドされている状態を示します。

LISTEN 0 128 0.0.0.0:8080 0.0.0.0:*

ソケットは、ホストに割り当てられたすべてのアクティブなIPv4ネットワークインターフェース（例：IP 192.168.10.100 を持つ ens160）を介したインバウンドTCPトラフィックを受け入れます。ファイアウォールが許可していれば、外部クライアントからの接続が可能です。

+-------------------------------------------------------------+
| Server: 192.168.10.100 |
| |
| Interface ens160 [ 192.168.10.100 ] &lt;--- [ 外部リクエスト ] |
| | |
| v |
| 0.0.0.0:8080 にバインドされたサービス (全インターフェースで受診) |
+-------------------------------------------------------------+

9. 実務におけるトラブルシューティング事例

事例 1: Pingは通るが、SSHが失敗する (`Connection Refused`)

環境構成:

クライアント: 192.168.10.50
サーバー: 192.168.10.100
対象サービス: SSH (TCP ポート 22)

ステップ 1: クライアント側での診断

$ ping 192.168.10.100
# 結果: 64 bytes from 192.168.10.100: icmp_seq=1 ttl=64 time=0.3 ms (成功)

$ nc -zv 192.168.10.100 22
# 結果: nc: connect to 192.168.10.100 port 22 failed: Connection refused

ステップ 2: サーバー側でのソケット検査

サーバーのローカルコンソールまたは帯域外（OOB）管理インターフェースにログインします。

$ sudo ss -lntp
# 出力結果:
# LISTEN 0 128 0.0.0.0:80 0.0.0.0:* users:(("nginx",pid=1500,fd=6))

TCPポート22がリスナーテーブルに存在しません。*

ステップ 3: サービス状態の確認と解決

$ sudo systemctl status sshd
# 出力: Active: inactive (dead)

$ sudo systemctl start sshd
$ sudo systemctl enable sshd

$ sudo ss -lntp | grep ':22'
# 出力: LISTEN 0 128 0.0.0.0:22 0.0.0.0:* users:(("sshd",pid=3102,fd=3))

クライアント側で再度 nc -zv 192.168.10.100 22 を実行すると、接続が成功します。

事例 2: プロセスは起動しているが、外部アクセスが失敗する (`Bind Mismatch`)

診断状態:

アプリケーションサーバー上で ss -lntp を実行すると、以下の結果が得られます。

LISTEN 0 128 127.0.0.1:8080 0.0.0.0:* users:(("node",pid=4211,fd=18))

疎通テスト:

ターゲットサーバーから: curl http://127.0.0.1:8080 $\longrightarrow$ 200 OK
リモートクライアントから: curl http://192.168.10.100:8080 $\longrightarrow$ 接続拒否 (Refused)

診断と解決策:

アプリケーション（Node.js、Spring Boot、Nginxなど）の設定が localhost に制限されています。ホストの設定（例：server.host = 0.0.0.0 または LISTEN 0.0.0.0:8080）を変更し、サービスを再起動してソケットを外部インターフェースに公開します。

事例 3: サービスはバインドされているが、外部接続がタイムアウトする

診断状態:

サーバーのソケットテーブルは正常に公開されています。

$ sudo ss -lntp | grep ':8080'
LISTEN 0 128 0.0.0.0:8080 0.0.0.0:* users:(("java",pid=8820,fd=7))

しかし、クライアント側での実行は失敗します。

$ nc -zv 192.168.10.100 8080
nc: connect to 192.168.10.100 port 8080 failed: Connection timed out

ファイアウォールの検査:

出力が Refused ではなく Timeout であるため、インラインネットワークデバイスまたはホストのファイアウォールルールがパケットをサイレントに破棄しています。

ローカルホストのルールを確認します。

$ sudo firewall-cmd --list-all
# サービスおよびポートセクションに '8080/tcp' が存在するか確認

$ sudo nft list ruleset

firewalld でICMPがグローバルに許可されていても、ポート8080が除外されている場合、ping` は通過しますが、ポート8080へのL4 TCPトラフィックは破棄されます。

Client (192.168.10.50) Server (192.168.10.100)
 | |
 |----------------------- TCP SYN ----------------------------&gt;|
 | |
 | [ Host Firewall (nftables) ]
 | [ Action: DROP Port 8080 ]
 | |
 | &lt;=== Timeout (SYN-ACKが送信されない) ========================|

10. `tcpdump` によるディープパケット診断

nc は接続結果を報告し、ss はソケットのリスニング状態を示します。しかし、tcpdump は実際のパケットの動きをキャプチャし、フレームレベルでの状態遷移を明らかにします。

ターゲットサーバーでパケットキャプチャを実行します。

$ sudo tcpdump -nn -i ens160 tcp port 8080

-n`: ホスト名を解決しない。

-nn: ホスト名およびポート名を解決しない（数値IPとポートを表示）。
-i ens160: 対象ネットワークインターフェース ens160 のトラフィックを監視。
tcp port 8080: ポート8080を通過するTCPパケットのみをフィルタリング。

11. `tcpdump` によるパケットパターンの分析

シナリオ A: 正常な TCP 3-Way ハンドシェイク

10:00:01.001 IP 192.168.10.50.52344 &gt; 192.168.10.100.8080: Flags [S], seq 1001
10:00:01.002 IP 192.168.10.100.8080 &gt; 192.168.10.50.52344: Flags [S.], seq 2001, ack 1002
10:00:01.003 IP 192.168.10.50.52344 &gt; 192.168.10.100.8080: Flags [.], seq 1002, ack 2002

Flags [S]`: クライアントからの初期 SYN フレーム。

Flags [S.]: サーバーからの SYN-ACK 応答。
Flags [.]: クライアントからの ACK フレーム。
診断: L4ハンドシェイクが完了し、接続が確立（ESTABLISHED）されています。

シナリオ B: 応答のないインバウンド SYN の継続

10:00:01.001 IP 192.168.10.50.52344 &gt; 192.168.10.100.8080: Flags [S], seq 1001
10:00:04.005 IP 192.168.10.50.52344 &gt; 192.168.10.100.8080: Flags [S], seq 1001
10:00:10.009 IP 192.168.10.50.52344 &gt; 192.168.10.100.8080: Flags [S], seq 1001

観察: クライアントが TCP SYN を再送信しています。サーバーのインターフェースはパケットを受信していますが、アウトバウンドの SYN-ACK ([S.]) が送信されていません。

診断: ホストレベルのセキュリティメカニズム（iptables、nftables、SELinux、またはカーネルレベルのIPフィルタリング）が、ネットワークインターフェース層への流入直後にパケットを破棄しています。

シナリオ C: サーバーは SYN-ACK を送信するが、クライアントが SYN を再送する

10:00:01.001 IP 192.168.10.50.52344 &gt; 192.168.10.100.8080: Flags [S]
10:00:01.002 IP 192.168.10.100.8080 &gt; 192.168.10.50.52344: Flags [S.]
10:00:04.005 IP 192.168.10.50.52344 &gt; 192.168.10.100.8080: Flags [S]

観察: サーバーはインバウンド SYN を処理して SYN-ACK を送信していますが、クライアントは応答を受信していないかのように SYN フレームを送信し続けています。

診断: サーバーとクライアント間の戻りパスのルーティング障害、または送信元方向へのエグレスファイアウォールによるフィルタリングが発生しています。

Client (192.168.10.50) Server (192.168.10.100)
 | |
 |----------------------- 1. SYN -----------------------------&gt;|
 | |
 | X &lt;=== [ 戻りルーティング障害 / エグレスブロック ] ---------| (SYN-ACKを送信)

主な原因：

ターゲットサーバー上のローカルデフォルトゲートウェイの設定誤り。
非対称ルーティングポリシーによる戻りパスの破棄。
NATテーブルの状態喪失。

シナリオ D: 即時のリセット (`SYN` 直後の `RST`)

10:00:01.001 IP 192.168.10.50.52344 &gt; 192.168.10.100.8080: Flags [S]
10:00:01.001 IP 192.168.10.100.8080 &gt; 192.168.10.50.52344: Flags [R.]

観察: サーバーが即座にリセットフレーム（[R.]）を返しています。

診断: パケットはホストのファイアウォールを通過しましたが、カーネルは TCP ポート 8080 でリスニングしているプロセスを見つけられませんでした。ss -lntp でデーモンの状態を確認してください。

12. カーネルカウンタによるソケット状態の追跡

ss -ant を実行して、アクティブなソケット全体の接続状態の割り当てを確認します。

$ sudo ss -ant
State Recv-Q Send-Q Local Address:Port Peer Address:Port
LISTEN 0 128 0.0.0.0:8080 0.0.0.0:*
ESTAB 0 0 192.168.10.100:8080 192.168.10.50:52344
SYN-RECV 0 0 192.168.10.100:8080 192.168.10.50:52345

重要なソケット状態と異常値:

SYN-SENT の累積 (クライアント側):
```
$ ss -ant state syn-sent
```

意味*: クライアントアプリケーションが SYN フレームを送信しましたが、SYN-ACK を受信していません。アウトバウンドのブロックまたは経路上の破棄を示します。

SYN-RECV の累積 (サーバー側):
```
$ ss -ant state syn-recv
```

意味*: サーバーが SYN を受信して SYN-ACK を送信しましたが、クライアントからの最終的な ACK を待機したまま停止しています。クライアント側のインバウンドブロック、非対称ルーティング、またはSYNフラッド攻撃を示します。

13. 上位レイヤーの診断: PingとTCPは成功するが、アプリケーションが失敗する

さらに高度な障害状態を定義します。

$ ping 192.168.10.100
# 成功 (L3正常)

$ nc -zv 192.168.10.100 8080
# 成功 (L4 TCP接続正常)

$ curl http://192.168.10.100:8080/
# 失敗 / エラー / HTTP 5xx / 応答なし

このシナリオは、ネットワーク層（L3）およびトランスポート層（L4）が完全に機能していることを証明しています。

`curl` によるアプリケーション層のデバッグ

詳細なHTTP操作を実行して、ハンドシェイクとプロトコルのセマンティクスをキャプチャします。

$ curl -v http://192.168.10.100:8080/

詳細な実行トレースの例を示します。

* Trying 192.168.10.100:8080...
* Connected to 192.168.10.100 (192.168.10.100) port 8080 (#0)
&gt; GET / HTTP/1.1
&gt; Host: 192.168.10.100:8080
&gt; User-Agent: curl/7.76.1
&gt; Accept: */*
&gt;
&lt; HTTP/1.1 504 Gateway Timeout
&lt; Server: nginx/1.20.1
&lt; Date: Mon, 10 Nov 2025 10:00:00 GMT
&lt; Content-Type: text/html

L7障害の主な原因カテゴリ:

リバースプロキシの上流タイムアウト: Nginxはポート8080で接続を受け入れますが、ローカルで動作するバックエンド（例：127.0.0.1:8000 のNode/Javaアプリ）への到達に失敗し、HTTP 504 Gateway Timeout または 502 Bad Gateway を返します。
HTTPホストヘッダーの拒否: アプリケーションの仮想ホストフィルタが、有効な Host: リクエストヘッダーを欠くリクエストを破棄しています。
アプリケーションのスレッドロック: データベース接続プールの枯渇や内部デッドロックにより、L4ソケットハンドシェイクが確立されているにもかかわらず、アプリケーション層がペイロードフレームを送信できません。
TLS/SSLハンドシェイクの失敗: 暗号スイートの不一致、証明書の期限切れ、またはSNIの誤設定により、ポート443でのTCP初期化直後に接続が切断されます。

14. UDPプロトコル診断における注意点

TCPとは異なり、UDPはコネクションレスです。セットアップフラグ（SYN、ACK）や状態マシンのチェックはありません。

nc を使用してUDPの到達性をテストするには、-u フラグが必要です。

$ nc -zvu 192.168.10.100 53

診断上の課題:

UDPスキャナーは0バイトのパケットを送信します。ICMP Port Unreachable フレームが戻ってこない場合、nc はポートが「開いている」または「開いているかフィルタされている」と判断します。
誤検知が非常に多いため、信頼性の高いUDPテストには、アクティブなパケットキャプチャと並行して、プロトコル固有のクエリツール（例：DNS UDP 53には dig、SNMP UDP 161には snmpwalk）を使用する必要があります。

$ sudo tcpdump -nn -i ens160 udp port 53

15. システムエンジニアのためのツールマトリクス

これらの診断ツールを統合された運用ワークフローに組み込みます。

ユーティリティ	対象レイヤー	コア機能	主な診断価値
`ping`	L3 (ネットワーク)	生のICMP到達性とリンクレイテンシの評価	基本的なIPルーティングと物理的接続性の検証
`nc`	L4 (トランスポート)	エンドツーエンドのTCP/UDPソケット可用性テスト	`Connection Refused` と `Timeout` の識別
`ss`	ホストカーネルソケット	ローカルインターフェースバインドとソケット状態の検査	デーモンプロセスが正常に起動しバインドされているかの確認
`tcpdump`	ワイヤプロトコル	生のネットワークインターフェースにおけるTCPフレームの監視	シーケンスフラグ（`SYN`、`SYN-ACK`、`RST`）の分析による障害箇所の特定
`curl`	L7 (アプリケーション)	HTTP/Sアプリケーションプロトコルトランザクションの検証	Webサーバーエラー、プロキシ設定ミス、バックエンドタイムアウトの特定

16. 体系的なトラブルシューティングフロー

🛠️ 「Pingは通るが、サービスアクセスが失敗する」事象に遭遇した場合は、以下の論理フローに従って診断を進めます。

 [ 事象発生: Pingは通るがサービスアクセスが失敗する ]
 |
 v
 実行: nc -zv <server_ip> <port>
 |
 +-----------------------------------+-----------------------------------+
 | | |
 v v v
 [ Connection Refused ] [ Connection Timed Out ] [ Succeeded ]
 | | |
 v v v
 ターゲットサーバーにログイン サーバーでパケットキャプチャを実行: L3/L4レイヤーは正常。
 実行: ss -lntp tcpdump -nn -i <nic> port <port> L7アプリケーション層を検証。
 | | 実行: curl -v http://<ip>:<port>
 +---------------+ +---------------+ |
 | | | | v
 v v v v アプリ/プロキシログを確認:
 [ ポートが未表示 ] [ 127.0.0.1 にバインド ] [ SYNが未到達 ] [ SYN到達、SYN-ACKなし ] - Systemdステータス
 | | | | - Nginx / アプリ例外
 v v v v - DB接続プール
 デーモンの起動: アプリ設定の修正 ネットワークパスの確認: ホストファイアウォールの確認:
 systemctl start 0.0.0.0:<port> - ネットワークFW - firewall-cmd
 <service> アプリ再起動 - セキュリティグループ - nftablesルール
 - ルーター設定 - カーネルIPフィルタリング

17. 運用CLIクイックリファレンス

L3 診断コマンド:

# リンク到達性をテストするために4つのICMPパケットを送信
$ ping -c 4 192.168.10.100

L4 ソケットプロービングコマンド (`nc`):

# 標準的な管理およびWebサービスのTCPポートを調査
$ nc -zv 192.168.10.100 22
$ nc -zv 192.168.10.100 80
$ nc -zv 192.168.10.100 443
$ nc -zv 192.168.10.100 8080

# UDPドメイン名解決サービスを調査
$ nc -zvu 192.168.10.100 53

ローカルソケット検査コマンド (`ss`):

# プロセス詳細を含むすべてのアクティブなリスニングTCPポートを一覧表示
$ sudo ss -lntp

# 特定のターゲットソケットリスナーをフィルタリング
$ sudo ss -lntp | grep ':8080'

# 状態に関係なく、すべての数値TCP接続を表示
$ sudo ss -ant

# SYN-SENTまたはSYN-RECV状態の接続を分離
$ sudo ss -ant state syn-sent
$ sudo ss -ant state syn-recv

パケット分析コマンド (`tcpdump`):

# 特定のインターフェースでTCPポート8080を監視
$ sudo tcpdump -nn -i ens160 tcp port 8080

# 生のSYN接続初期化リクエストをグローバルにキャプチャ
$ sudo tcpdump -nn -i ens160 'tcp[tcpflags] &amp; tcp-syn != 0'

# 特定のホストIPアドレスに関連するすべてのトラフィックをキャプチャ
$ sudo tcpdump -nn -i ens160 host 192.168.10.50

# ICMP制御パケットとターゲットTCPアプリケーショントラフィックを多重追跡
$ sudo tcpdump -nn -i ens160 'tcp port 8080 or icmp'

ホストファイアウォール操作 (`firewalld` / `nftables`):

# 現在のfirewalld設定を検査
$ sudo firewall-cmd --list-all

# TCP 8080の許可を永続的に追加
$ sudo firewall-cmd --add-port=8080/tcp --permanent
$ sudo firewall-cmd --reload

# 低レベルのnftablesルールセットバインディングを検査
$ sudo nft list ruleset

Lessons Learned

Pingの成功はサービスの健全性を保証しない: ICMP Echo応答は、レイヤー3のインターフェース到達性とルーティングの正常性のみを証明します。レイヤー4のポート状態やレイヤー7のアプリケーション機能は検証されません。
エラーメッセージの正確な解釈:

Connection refused は、パケットがホストに到達したものの、アクティブなリスナーがないか、明示的に RST 拒否されたことを示します。ホストのソケットバインド (ss -lntp) を確認してください。
Connection timed out は、送信または戻りの経路でフレームが消失したことを示します。ファイアウォール、セキュリティグループ、ルーティングループを確認してください。

ワイヤキャプチャによるパケットパスの追跡: tcpdump を使用して、「初期SYNフレームがインフラストラクチャスタックのどこまで到達したか」という根本的な問いに答えます。
レイヤー範囲の段階的な分離: L3（ping）からL4（nc）へ順次テストし、ローカルのリスニング状態（ss）を検査し、ワイヤ上の生のフレーム（tcpdump）を検証し、最後にL7（curl）で確認を行います。</server_ip>

Tcpdump on K-Life Hack | システムアーキテクチャ & DevOps

Ping疎通可能でもTCP接続が失敗する境界領域のトラブルシューティング

1. ネットワーク層の抽象化とサービスマッピング

2. ping の低レイヤーメカニズム

3. TCP 3-Way ハンドシェイクの構造

4. 「Ping疎通可能 ＋ TCP接続失敗」の診断

5. nc (Netcat) によるトランスポート層のプロービング

6. Connection Refused と Connection Timeout のメカニズム

Connection Refused の仕組み

主な原因:

Connection Timeout の仕組み

主な原因:

7. ss によるローカルソケットの検査

フラグ仕様:

8. バインドアドレスの分析: 127.0.0.1 vs 0.0.0.0

ループバック隔離ケース (127.0.0.1:8080)

ワイルドカードIPv4バインド (0.0.0.0:8080)

9. 実務におけるトラブルシューティング事例

事例 1: Pingは通るが、SSHが失敗する (Connection Refused)

環境構成:

ステップ 1: クライアント側での診断

ステップ 2: サーバー側でのソケット検査

ステップ 3: サービス状態の確認と解決

事例 2: プロセスは起動しているが、外部アクセスが失敗する (Bind Mismatch)

診断状態:

疎通テスト:

診断と解決策:

事例 3: サービスはバインドされているが、外部接続がタイムアウトする

診断状態:

ファイアウォールの検査:

10. tcpdump によるディープパケット診断

11. tcpdump によるパケットパターンの分析

シナリオ A: 正常な TCP 3-Way ハンドシェイク

シナリオ B: 応答のないインバウンド SYN の継続

シナリオ C: サーバーは SYN-ACK を送信するが、クライアントが SYN を再送する

シナリオ D: 即時のリセット (SYN 直後の RST)

12. カーネルカウンタによるソケット状態の追跡

重要なソケット状態と異常値:

13. 上位レイヤーの診断: PingとTCPは成功するが、アプリケーションが失敗する

curl によるアプリケーション層のデバッグ

L7障害の主な原因カテゴリ:

14. UDPプロトコル診断における注意点

診断上の課題:

15. システムエンジニアのためのツールマトリクス

16. 体系的なトラブルシューティングフロー

17. 運用CLIクイックリファレンス

L3 診断コマンド:

L4 ソケットプロービングコマンド (nc):

ローカルソケット検査コマンド (ss):

パケット分析コマンド (tcpdump):

ホストファイアウォール操作 (firewalld / nftables):

Lessons Learned

2. `ping` の低レイヤーメカニズム

4. 「Ping疎通可能＋ TCP接続失敗」の診断

5. `nc` (Netcat) によるトランスポート層のプロービング

7. `ss` によるローカルソケットの検査

8. バインドアドレスの分析: `127.0.0.1` vs `0.0.0.0`

ループバック隔離ケース (`127.0.0.1:8080`)

ワイルドカードIPv4バインド (`0.0.0.0:8080`)

事例 1: Pingは通るが、SSHが失敗する (`Connection Refused`)

事例 2: プロセスは起動しているが、外部アクセスが失敗する (`Bind Mismatch`)

10. `tcpdump` によるディープパケット診断

11. `tcpdump` によるパケットパターンの分析

シナリオ D: 即時のリセット (`SYN` 直後の `RST`)

`curl` によるアプリケーション層のデバッグ

L4 ソケットプロービングコマンド (`nc`):

ローカルソケット検査コマンド (`ss`):

パケット分析コマンド (`tcpdump`):

ホストファイアウォール操作 (`firewalld` / `nftables`):