Menu
Digital Fortress Labo（デジタル・フォートレス・ラボ）

Npingコマンドの使い方を徹底解説！

セキュリティ実践ラボ
AlmaLinux Ubuntu プラットフォーム診断 疎通確認 経路確認

ICMP・TCP・UDPなどのパケットを生成・送信し、ネットワークの疎通や応答を確認できるツール
- Nping -

Npingは、任意のネットワークパケットを生成・送信し、対象ホストからの応答を分析できるパケット生成ツールです。通常のpingより柔軟な通信テストができるため、ICMP・TCP・UDPなどを用いた疎通確認やファイアウォールのルール検証に役立ちます。

本記事では、Npingの特徴やpingとの違い、インストール方法、npingコマンドの使い方を順番に解説します。

さらに、TCP・UDP・ICMP・ARP/RARP・Tracerouteモードごとの実行例も掲載しているので、実行結果の見方と使い分けが一度で理解できます。

目次

Npingとは

Npingは、ネットワークパケットの生成や応答分析、応答時間の測定を行うためのコマンドラインツールです。ポートスキャナのNmapと同じプロジェクトから提供されており、Nmapパッケージに標準で同梱されています。

ICMP Echo Requestしか送信できないpingとは異なり、NpingはTCP、UDP、ICMP、ARPなど複数のプロトコルに対応しており、送信するパケットのヘッダーや各種パラメータを細かく指定できます。単純な疎通確認だけでなく、ネットワーク機器の応答確認、ファイアウォールの設定検証、経路確認などの用途にも適しています。

本記事は、ネットワーク調査やトラブルシューティングといった正当な目的での利用を前提に、Npingの使い方を解説するものです。第三者が管理するサーバーやネットワークに対して無断で実行すると、攻撃行為や不正アクセスとみなされる可能性があります。必ず自身が管理する環境、または許可を得た環境でのみ使用してください。

主な特徴

Npingの最大の特徴は、一般的な疎通確認ツールよりもパケットを柔軟に制御できることです。

  • TCP、UDP、ICMP、ARPなどのパケットを送信できる
  • 宛先ホストや宛先ポートを複数指定できる
  • TCP/IPヘッダーの各種フィールドを細かく設定できる
  • 送信したパケットに対する応答を確認できる
  • パケットの往復時間を測定できる
  • TCP、UDP、ICMPを利用したTracerouteに対応している
  • 一部の機能は管理者権限を使用せずに実行できる
  • クロスプラットフォーム対応（Linux、Windows、macOS）

Nmapとの関係

Nmapは、ネットワーク上のホストやサービスなどを調査するためのポートスキャナです。ホストの検出、ポートの状態確認、サービスやバージョンの識別など、幅広い用途に対応しています。

一方、NpingはNmapプロジェクトが提供するネットワークツールで、指定した条件に基づいてパケットを生成し、その応答を詳細に確認する用途に適しています。

両者の役割の違い

主な用途概要
Nmapポートスキャンホスト、ポート、サービスなどネットワーク全体の状態を調査する
Nping疎通確認指定したパケットを送信し、対象ホストからの応答を確認する

pingとの違い

pingとNpingは、どちらもネットワークの疎通確認に利用できます。しかし、対応するプロトコルや設定できる項目には大きな違いがあります。

一般的なpingコマンドは、主にICMP Echo Requestを送信し、ICMP Echo Replyが返ってくるかを確認するツールです。対象ホストまで通信できるか確認したり、往復時間を測定したりする用途に適しています。

一方、NpingではICMPだけでなく、TCP、UDP、ARPなどを利用した通信確認が可能です。

pingとNpingの違い

pingNping
主な用途基本的な疎通確認高度な疎通確認
対応プロトコルICMP Echo RequestのみTCP / UDP / ICMP / ARP
宛先ポートの指定不可可能
経路確認非対応対応
応答時間の測定可能可能
実行権限一般ユーザーで実行可基本的に管理者権限が必要
（Rawパケットを生成しないモードの場合、一般ユーザーで実行可能）
導入方法OS標準搭載Nmapパッケージのインストール

この違いは、ネットワークの調査やトラブルシューティングにおいて重要です。

例えば、pingで応答が得られなかったとしても、「対象ホストに通信できない」とは限りません。ネットワークやホスト側の設定によって、ICMP通信が制限されている可能性があるためです。そのような場合、Npingを利用してTCPやUDPなど別のプロトコルによる応答を確認すれば、「ホストに到達できないのか」「特定の通信だけが制限されているのか」を切り分ける手掛かりになります。

つまり、pingが日常的な疎通確認に適したシンプルなツールであるのに対し、Npingはネットワーク通信をより詳細に検証するためのツールです。

Npingのダウンロード・インストール

Npingは、Nmapに同梱されているツールの一つです。基本的にはNmapをインストールすれば、Npingも利用できるようになります。

公式サイトでは、Nmapのバイナリパッケージとして、Windows向けに.exe形式、RHEL系Linuxディストリビューション向けに.rpm形式、macOS向けに.dmg形式が提供されています。※ただし、Debian系ディストリビューション向けのパッケージ（.deb形式）は提供されていません。

ダウンロードURL　https://nmap.org/download.html

インストール後は、次のコマンドを実行してNpingが利用できるか確認できます。

$ nping -V
Nping version 0.7.99 ( https://nmap.org/nping )

バージョン情報が表示されれば、インストールは完了です。

Linuxの場合、各ディストリビューションが提供するパッケージマネージャを利用すると、簡単にNmapをインストールできます。

# Debian系の場合（Ubuntuなど）
$ sudo apt update
$ sudo apt install nmap

# RHEL系の場合（AlmaLinuxなど）
$ sudo dnf install nmap

Kali Linuxをはじめとするセキュリティ用途のディストリビューションでは、Nmapパッケージが標準で導入済みです。

npingコマンドの使い方

本記事では、Linux環境におけるnpingコマンドの使い方を解説します。Npingの基本仕様はWindowsやmacOSでも共通ですが、一部の機能や動作はOSに依存する場合があります。

npingコマンドの基本構文

$ nping [プローブモード] [オプション] <ターゲット>
  • プローブモード：送信するパケットの種類を指定（TCP、UDP、ICMPなど）
  • オプション：送信回数、間隔、ポート、ヘッダ値などを制御
  • ターゲット：宛先ホストを指定

一部のプローブモードでは、ネットワークパケットを直接生成・送信するためにRawソケットなどの低レベルなネットワーク機能を使用します。これらの機能は通常、一般ユーザーには制限されているため、管理者権限での実行が必要です。

npingコマンドのヘルプを確認したい場合は、-h（または--help）オプション、またはマニュアル（manコマンド）を使用します。

$ nping -h    # ヘルプ
$ man nping   # マニュアル・リファレンス

プローブモード

NpingにはTCP、UDP、ICMP、ARPなど複数のプローブモードが用意されています。プローブモードによって生成されるパケットや指定可能なオプションが異なるため、npingコマンドを使用する際は、まず「何を確認したいのか」を明確にし、その目的に応じたプローブモードを選択します。

指定可能なプローブモード
  • TCP Connectモード（--tcp-connect）
  • TCPモード（--tcp）
  • UDPモード（--udp）
  • ICMPモード（--icmp）
  • ARP/RARPモード（--arp）
  • Tracerouteモード（-tr、--traceroute）

※一部のプローブモードではRawパケットを扱うため、管理者権限が必要です。

プローブモードを適切に使い分けることで、TCPポートへの接続可否やUDP通信の応答、ICMPの到達性、同一ネットワーク内のARP応答などを確認できます。ネットワークの調査やトラブルシューティングでは、単に「応答があるか」を確認するだけでなく、どのプロトコルのどの通信に対して応答があるのかを切り分けることが重要です。

各プローブモードの概要や実行例については、次章の『npingコマンドの実行例』で解説しています。

プローブモードの指定を省略した場合、実行ユーザーがRawソケット権限を持っているかどうかでデフォルトモードが変わります。

ユーザー例デフォルトモード
Rawソケット権限がない場合一般ユーザーTCP Connectモード
Rawソケット権限がある場合root管理者ICMPモード

本記事の検証環境でNpingを実行したところ、Kali Linuxでは実行権限にかかわらずICMPモードで動作しました。ただし、ICMPモードではRawパケットを送信するため、一般ユーザーでは権限不足エラーが発生します。

$ nping 192.168.30.107

Starting Nping 0.7.99 ( https://nmap.org/nping ) at 2026-09-03 03:50 JST
libnsock nsock_pcap_open(): pcap_activate(eth0) FAILED: Attempt to create packet socket failed - CAP_NET_RAW may be required.
Error opening capture device eth0

本記事の検証環境での確認結果

一般ユーザー権限管理者権限
Kali Linux 2026.2ICMPモード（権限エラー）ICMPモード
Ubuntu Server 26.04TCP ConnectモードICMPモード
AlmaLinux 10.2TCP ConnectモードICMPモード

オプション

代表的なオプションのみ抜粋

オプション概要
-p, --dest-port <port spec>宛先ポート（範囲やカンマ区切りで複数指定可）
※TCP Connectモード、TCPモード、UDPモードのみ指定可能
-g, --source-port <portnumber>送信元ポート
※TCP Connectモード、TCPモード、UDPモードのみ指定可能
--delay <time>プローブの送信間隔
単位：ms（ミリ秒）、s（秒）、m（分）、h（時間）
※単位省略時は秒
--rate <rate>1 秒あたりの送信プローブ数
-h, --helpヘルプを表示
-V, --versionバージョンを表示
-c, --count <n>プローブの送信回数
※0、または未設定の場合、無制限
-e, --interface <name>使用するネットワークインターフェース
-v / -v[level]詳細出力（レベル指定可）
-d / -d[level]デバッグ出力（レベル指定可）
-q / -q[N]出力を抑制（レベル指定可）
--quiet静音モード
--debugデバッグモード

npingのオプションは多岐にわたりますが、ヘルプ（nping -h）の出力はプローブモードごとに整理されており、リファレンスとして実用的です。手を動かしながら、随時参照する使い方をおすすめします。

（参考）nping -hのヘルプメッセージを見る
$ nping -h
Nping 0.7.99 ( https://nmap.org/nping )
Usage: nping [Probe mode] [Options] {target specification}

TARGET SPECIFICATION:
  Targets may be specified as hostnames, IP addresses, networks, etc.
  Ex: scanme.nmap.org, microsoft.com/24, 192.168.0.1; 10.0.*.1-24
PROBE MODES:
  --tcp-connect                    : Unprivileged TCP connect probe mode.
  --tcp                            : TCP probe mode.
  --udp                            : UDP probe mode.
  --icmp                           : ICMP probe mode.
  --arp                            : ARP/RARP probe mode.
  --tr, --traceroute               : Traceroute mode (can only be used with
                                     TCP/UDP/ICMP modes).
TCP CONNECT MODE:
   -p, --dest-port <port spec>     : Set destination port(s).
   -g, --source-port <portnumber>  : Try to use a custom source port.
TCP PROBE MODE:
   -g, --source-port <portnumber>  : Set source port.
   -p, --dest-port <port spec>     : Set destination port(s).
   --seq <seqnumber>               : Set sequence number.
   --flags <flag list>             : Set TCP flags (ACK,PSH,RST,SYN,FIN...)
   --ack <acknumber>               : Set ACK number.
   --win <size>                    : Set window size.
   --badsum                        : Use a random invalid checksum.
UDP PROBE MODE:
   -g, --source-port <portnumber>  : Set source port.
   -p, --dest-port <port spec>     : Set destination port(s).
   --badsum                        : Use a random invalid checksum.
ICMP PROBE MODE:
  --icmp-type <type>               : ICMP type.
  --icmp-code <code>               : ICMP code.
  --icmp-id <id>                   : Set identifier.
  --icmp-seq <n>                   : Set sequence number.
  --icmp-redirect-addr <addr>      : Set redirect address.
  --icmp-param-pointer <pnt>       : Set parameter problem pointer.
  --icmp-advert-lifetime <time>    : Set router advertisement lifetime.
  --icmp-advert-entry <IP,pref>    : Add router advertisement entry.
  --icmp-orig-time  <timestamp>    : Set originate timestamp.
  --icmp-recv-time  <timestamp>    : Set receive timestamp.
  --icmp-trans-time <timestamp>    : Set transmit timestamp.
ARP/RARP PROBE MODE:
  --arp-type <type>                : Type: ARP, ARP-reply, RARP, RARP-reply.
  --arp-sender-mac <mac>           : Set sender MAC address.
  --arp-sender-ip  <addr>          : Set sender IP address.
  --arp-target-mac <mac>           : Set target MAC address.
  --arp-target-ip  <addr>          : Set target IP address.
IPv4 OPTIONS:
  -S, --source-ip                  : Set source IP address.
  --dest-ip <addr>                 : Set destination IP address (used as an
                                     alternative to {target specification} ).
  --tos <tos>                      : Set type of service field (8bits).
  --id  <id>                       : Set identification field (16 bits).
  --df                             : Set Don't Fragment flag.
  --mf                             : Set More Fragments flag.
  --evil                           : Set Reserved / Evil flag.
  --ttl <hops>                     : Set time to live [0-255].
  --badsum-ip                      : Use a random invalid checksum.
  --ip-options <R|S [route]|L [route]|T|U ...> : Set IP options
  --ip-options <hex string>                    : Set IP options
  --mtu <size>                     : Set MTU. Packets get fragmented if MTU is
                                     small enough.
IPv6 OPTIONS:
  -6, --IPv6                       : Use IP version 6.
  --dest-ip                        : Set destination IP address (used as an
                                     alternative to {target specification}).
  --hop-limit                      : Set hop limit (same as IPv4 TTL).
  --traffic-class <class> :        : Set traffic class.
  --flow <label>                   : Set flow label.
ETHERNET OPTIONS:
  --dest-mac <mac>                 : Set destination mac address. (Disables
                                     ARP resolution)
  --source-mac <mac>               : Set source MAC address.
  --ether-type <type>              : Set EtherType value.
PAYLOAD OPTIONS:
  --data <hex string>              : Include a custom payload.
  --data-string <text>             : Include a custom ASCII text.
  --data-length <len>              : Include len random bytes as payload.
ECHO CLIENT/SERVER:
  --echo-client <passphrase>       : Run Nping in client mode.
  --echo-server <passphrase>       : Run Nping in server mode.
  --echo-port <port>               : Use custom <port> to listen or connect.
  --no-crypto                      : Disable encryption and authentication.
  --once                           : Stop the server after one connection.
  --safe-payloads                  : Erase application data in echoed packets.
TIMING AND PERFORMANCE:
  Options which take <time> are in seconds, or append 'ms' (milliseconds),
  's' (seconds), 'm' (minutes), or 'h' (hours) to the value (e.g. 30m, 0.25h).
  --delay <time>                   : Adjust delay between probes.
  --rate  <rate>                   : Send num packets per second.
MISC:
  -h, --help                       : Display help information.
  -V, --version                    : Display current version number.
  -c, --count <n>                  : Stop after <n> rounds.
  -e, --interface <name>           : Use supplied network interface.
  -H, --hide-sent                  : Do not display sent packets.
  -N, --no-capture                 : Do not try to capture replies.
  --privileged                     : Assume user is fully privileged.
  --unprivileged                   : Assume user lacks raw socket privileges.
  --send-eth                       : Send packets at the raw Ethernet layer.
  --send-ip                        : Send packets using raw IP sockets.
  --bpf-filter <filter spec>       : Specify custom BPF filter.
OUTPUT:
  -v                               : Increment verbosity level by one.
  -v[level]                        : Set verbosity level. E.g: -v4
  -d                               : Increment debugging level by one.
  -d[level]                        : Set debugging level. E.g: -d3
  -q                               : Decrease verbosity level by one.
  -q[N]                            : Decrease verbosity level N times
  --quiet                          : Set verbosity and debug level to minimum.
  --debug                          : Set verbosity and debug to the max level.
EXAMPLES:
  nping scanme.nmap.org
  nping --tcp -p 80 --flags rst --ttl 2 192.168.1.1
  nping --icmp --icmp-type time --delay 500ms 192.168.254.254
  nping --echo-server "public" -e wlan0 -vvv
  nping --echo-client "public" echo.nmap.org --tcp -p1-1024 --flags ack

SEE THE MAN PAGE FOR MANY MORE OPTIONS, DESCRIPTIONS, AND EXAMPLES

ターゲット

ターゲットにはIPアドレスだけでなく、ホスト名やネットワークアドレスを指定できます。

# 単一のIPアドレス
$ nping 192.0.2.1

# ホスト名（名前解決が可能な場合）
$ nping example.com

# CIDR表記によるネットワーク指定
$ nping 192.0.2.0/24

# 範囲指定
$ nping 192.0.2.1-20

# 複数指定
$ nping 192.0.2.1,2,10

複数のターゲットを指定した場合、Npingは各ホストへ順番にプローブを送信します。

npingコマンドの実行例

  • TCP Connectモード
    • サービスを待ち受けているポートの場合（宛先ポートがopenの場合）
    • サービスを待ち受けていない場合（宛先ポートがclosedの場合）
    • ファイアウォールで接続を遮断している場合（宛先ポートがfilteredの場合）
  • TCPモード
    • サービスを待ち受けているポートの場合（宛先ポートがopenの場合）
    • サービスを待ち受けていない場合（宛先ポートがclosedの場合）
    • ファイアウォールで接続を遮断している場合（宛先ポートがfilteredの場合）
  • UDPモード
    • サービスを待ち受けているポートの場合（宛先ポートがopenの場合）
    • サービスを待ち受けていない場合（宛先ポートがclosedの場合）
    • ファイアウォールで接続を遮断している場合（宛先ポートがfilteredの場合）
  • ICMPモード
    • ICMP通信が許可されている場合
    • ICMP通信が制限（DROP）されている場合
  • ARP/RARPモード
    • 同一セグメント内のホストにARPリクエストを送信する
    • 別セグメントのホストにARPリクエストを送信する
  • Tracerouteモード
    • ICMPモードでTracerouteを実行する
    • TCPモードでTracerouteを実行する

ここからは実際に手を動かしながら、Npingの挙動を確認していきます。本検証では、VirtualBoxで構築したWindows端末上の仮想ネットワークを使用します。ネットワーク構成にはホストオンリーネットワークを採用し、外部ネットワークから隔離された仮想環境内で検証を実施します。

検証環境の構成

OSIPアドレス備考
送信元（Nping実行）Kali Linux 2026.2192.168.10.11/24Nping 0.7.99
宛先ホストDebian 13.5192.168.30.107/24
宛先ホストUbuntu Server 26.04192.168.10.106/24ARPモードの検証で使用
※送信元ホストと同じセグメント

なお、以降の検証では、プローブの送信回数を-cオプションで指定しています。

TCP Connectモード

TCP Connectモードの基本構文

$ nping --tcp-connect [オプション] <ターゲット>

TCP Connectモードは、OSのconnect()システムコールを利用して、指定したTCPポートへの接続を正常に確立できるかどうかを確認します。Rawパケットを生成するTCPモードとは異なり、一般的なTCPクライアントと同様にOSのソケット機能を利用します。そのため、Rawパケットを送信する権限（管理者権限）がない環境でも実行可能です。

サービスを待ち受けているポートの場合（宛先ポートがopenの場合）

$ nping --tcp-connect -p 80 -c 3 192.168.30.107

Starting Nping 0.7.99 ( https://nmap.org/nping ) at 2026-09-07 02:05 JST
SENT (0.0017s) Starting TCP Handshake > 192.168.30.107:80
RCVD (0.0034s) Handshake with 192.168.30.107:80 completed
SENT (1.0044s) Starting TCP Handshake > 192.168.30.107:80
RCVD (1.0063s) Handshake with 192.168.30.107:80 completed
SENT (2.0073s) Starting TCP Handshake > 192.168.30.107:80
RCVD (2.0091s) Handshake with 192.168.30.107:80 completed

Max rtt: 1.907ms | Min rtt: 1.725ms | Avg rtt: 1.829ms
TCP connection attempts: 3 | Successful connections: 3 | Failed: 0 (0.00%)
Nping done: 1 IP address pinged in 2.01 seconds
  • SENT ... Starting TCP Handshake > 192.168.30.107:80
    • 192.168.30.107のTCP/80に対して、TCP接続処理（3ウェイ・ハンドシェイク）を開始。
  • RCVD ... Handshake with 192.168.30.107:80 completed
    • 3ウェイ・ハンドシェイクを正常に完了。

宛先ホスト（192.168.30.107）のTCP/80に対して3回接続を試行した結果、TCP接続処理をすべて正常に完了しています。したがって、宛先ホストまでTCP通信が到達しており、80番ポートでは「TCP接続を受け付けるサービスが稼働している」と判断できます。

サービスを待ち受けていない場合（宛先ポートがclosedの場合）

$ nping --tcp-connect -p 8080 -c 3 192.168.30.107

Starting Nping 0.7.99 ( https://nmap.org/nping ) at 2026-09-07 02:05 JST
SENT (0.0015s) Starting TCP Handshake > 192.168.30.107:8080
RCVD (0.0027s) Possible TCP RST received from 192.168.30.107:8080 --> Connection refused
SENT (1.0045s) Starting TCP Handshake > 192.168.30.107:8080
RCVD (1.0064s) Possible TCP RST received from 192.168.30.107:8080 --> Connection refused
SENT (2.0078s) Starting TCP Handshake > 192.168.30.107:8080
RCVD (2.0095s) Possible TCP RST received from 192.168.30.107:8080 --> Connection refused

Max rtt: N/A | Min rtt: N/A | Avg rtt: N/A
TCP connection attempts: 3 | Successful connections: 0 | Failed: 3 (100.00%)
Nping done: 1 IP address pinged in 2.01 seconds
  • SENT ... Starting TCP Handshake > 192.168.30.107:8080
    • 192.168.30.107のTCP/8080に対して、TCP接続処理（3ウェイ・ハンドシェイク）を開始。
  • RCVD ... Possible TCP RST received from 192.168.30.107:8080 --> Connection refused
    • 宛先ホストからRSTパケットが返されたため、「接続拒否（Connection refused）」と判断される。

宛先ホスト（192.168.30.107）から応答が返ってきているものの、TCP/8080への接続は3回とも拒否されています。そのため、宛先ホストにネットワークレベルで到達できている一方、「8080番ポートではサービスを待ち受けていない可能性が高い」と判断できます。

宛先ホスト自体には到達できても、指定したポートでサービスが待ち受けていなければ、TCP接続は成立しません。

ファイアウォールで接続を遮断している場合（宛先ポートがfilteredの場合）

$ nping --tcp-connect -p 8888 -c 3 192.168.30.107

Starting Nping 0.7.99 ( https://nmap.org/nping ) at 2026-09-07 02:05 JST
SENT (0.0023s) Starting TCP Handshake > 192.168.30.107:8888
SENT (1.0040s) Starting TCP Handshake > 192.168.30.107:8888
SENT (2.0053s) Starting TCP Handshake > 192.168.30.107:8888

Max rtt: N/A | Min rtt: N/A | Avg rtt: N/A
TCP connection attempts: 3 | Successful connections: 0 | Failed: 3 (100.00%)
Nping done: 1 IP address pinged in 3.01 seconds
  • SENT ... Starting TCP Handshake > 192.168.30.107:8888
    • 192.168.30.107のTCP/8888に対して、TCP接続処理（3ウェイ・ハンドシェイク）を開始。

宛先ホスト（192.168.30.107）に対して、TCP接続を3回試行しましたが、すべての試行で応答が得られず接続に失敗しました。注目すべきは、RCVD行が一切無く、rttもN/Aであること、つまりRSTによる「接続拒否」の応答すら返ってきていません。経路上のファイアウォールや宛先ホストのフィルタによって、パケットが遮断（DROP）されている可能性が高いと判断できます。

TCPモード

TCPモードの基本構文

$ nping --tcp [オプション] <ターゲット>

TCPモードは、TCPパケットを生成して送信するモードです。デフォルトでは、TCP/80にSYNパケットを送信します。TCP Connectモードよりも低レイヤーで通信を扱えるため、TCPヘッダーの各種フィールドを指定できます。

  • 送信元ポート
  • 宛先ポート
  • TCPシーケンス番号
  • TCPフラグ
  • ACK番号
  • ウィンドウサイズ

SYNパケットを送信し応答内容を確認することで、TCPポートの状態や通信経路上のフィルタリングを調査できます。

TCP ConnectモードとTCPモードでは、疎通確認の方式が異なります。

TCP Connectモード通常のTCP接続を実際に確立して通信状態を確認する。
TCPモードSYNなど任意のTCPパケットを送信し、その応答として受信したSYN/ACKやRSTなどをもとに疎通可否を判断する。

サービスを待ち受けているポートの場合（宛先ポートがopenの場合）

$ sudo nping --tcp -p 80 -c 3 192.168.30.107

Starting Nping 0.7.99 ( https://nmap.org/nping ) at 2026-09-07 03:51 JST
SENT (0.0110s) TCP 192.168.10.11:26660 > 192.168.30.107:80 S ttl=64 id=48456 iplen=40  seq=422752150 win=1480
RCVD (0.0126s) TCP 192.168.30.107:80 > 192.168.10.11:26660 SA ttl=62 id=0 iplen=44  seq=499673092 win=64240 <mss 1460>
SENT (1.0113s) TCP 192.168.10.11:26660 > 192.168.30.107:80 S ttl=64 id=48456 iplen=40  seq=422752150 win=1480
RCVD (1.0134s) TCP 192.168.30.107:80 > 192.168.10.11:26660 SA ttl=62 id=0 iplen=44  seq=515307146 win=64240 <mss 1460>
SENT (2.0148s) TCP 192.168.10.11:26660 > 192.168.30.107:80 S ttl=64 id=48456 iplen=40  seq=422752150 win=1480
RCVD (2.0167s) TCP 192.168.30.107:80 > 192.168.10.11:26660 SA ttl=62 id=0 iplen=44  seq=530984189 win=64240 <mss 1460>

Max rtt: 1.973ms | Min rtt: 1.536ms | Avg rtt: 1.801ms
Raw packets sent: 3 (162B) | Rcvd: 3 (138B) | Lost: 0 (0.00%)
Nping done: 1 IP address pinged in 2.04 seconds
  • SENT ... TCP 192.168.10.11:26660 > 192.168.30.107:80 S ...
    • 送信元（192.168.10.11）から宛先（192.168.30.107）のTCP/80へSYNパケット（接続要求）を送信。
  • RCVD ... TCP 192.168.30.107:80 > 192.168.10.11:26660 SA ...
    • 宛先ホストからSYN/ACKパケット（接続要求応答）を受信。

宛先ホスト（192.168.30.107）のTCP/80にSYNパケットを送信したところ、すべてのプローブに対してSYN/ACKパケットが返ってきました。つまり、宛先ホストのTCP/80は開いており、サービスを待ち受けていると判断できます。

サービスを待ち受けていない場合（宛先ポートがclosedの場合）

$ sudo nping --tcp -p 8080 -c 3 192.168.30.107

Starting Nping 0.7.99 ( https://nmap.org/nping ) at 2026-09-07 03:51 JST
SENT (0.0099s) TCP 192.168.10.11:8437 > 192.168.30.107:8080 S ttl=64 id=60657 iplen=40  seq=868344475 win=1480
RCVD (0.0110s) TCP 192.168.30.107:8080 > 192.168.10.11:8437 RA ttl=62 id=0 iplen=40  seq=0 win=0
SENT (1.0120s) TCP 192.168.10.11:8437 > 192.168.30.107:8080 S ttl=64 id=60657 iplen=40  seq=868344475 win=1480
RCVD (1.0137s) TCP 192.168.30.107:8080 > 192.168.10.11:8437 RA ttl=62 id=0 iplen=40  seq=0 win=0
SENT (2.0138s) TCP 192.168.10.11:8437 > 192.168.30.107:8080 S ttl=64 id=60657 iplen=40  seq=868344475 win=1480
RCVD (2.0154s) TCP 192.168.30.107:8080 > 192.168.10.11:8437 RA ttl=62 id=0 iplen=40  seq=0 win=0

Max rtt: 1.577ms | Min rtt: 1.107ms | Avg rtt: 1.407ms
Raw packets sent: 3 (162B) | Rcvd: 3 (138B) | Lost: 0 (0.00%)
Nping done: 1 IP address pinged in 2.04 seconds
  • SENT ... TCP 192.168.10.11:8437 > 192.168.30.107:8080 S ...
    • 送信元（192.168.10.11）から宛先（192.168.30.107）のTCP/8080へSYNパケット（接続要求）を送信。
  • RCVD ... TCP 192.168.30.107:8080 > 192.168.10.11:8437 RA ...
    • 宛先ホストからRST/ACKパケット（リセット応答）を受信。（つまり、TCP/8080では接続を受け付けていない。）

宛先ホスト（192.168.30.107）へのネットワーク疎通自体は正常であり、パケットロスなく通信できています。ただし、TCP/8080からはRST/ACKパケットが返されているため、宛先ホストのTCP/8080は閉じている（サービスが起動していない）可能性があると判断できます。

サマリ行のLost: 0 (0.00%)という表示については、解釈に注意が必要です。今回受信しているのはRST/ACKパケット（リセット応答）です。Npingでは、応答の種類にかかわらず「何らかの応答を受信した」場合に受信済みとしてカウントするため、対象ポートが閉じている場合でもLost: 0 (0.00%)と表示されます。

ファイアウォールで接続を遮断している場合（宛先ポートがfilteredの場合）

$ sudo nping --tcp -p 8888 -c 3 192.168.30.107

Starting Nping 0.7.99 ( https://nmap.org/nping ) at 2026-09-07 03:51 JST
SENT (0.0140s) TCP 192.168.10.11:41855 > 192.168.30.107:8888 S ttl=64 id=16108 iplen=40  seq=1710301989 win=1480
SENT (1.0150s) TCP 192.168.10.11:41855 > 192.168.30.107:8888 S ttl=64 id=16108 iplen=40  seq=1710301989 win=1480
SENT (2.0174s) TCP 192.168.10.11:41855 > 192.168.30.107:8888 S ttl=64 id=16108 iplen=40  seq=1710301989 win=1480

Max rtt: N/A | Min rtt: N/A | Avg rtt: N/A
Raw packets sent: 3 (162B) | Rcvd: 0 (0B) | Lost: 3 (100.00%)
Nping done: 1 IP address pinged in 3.05 seconds
  • SENT ... TCP 192.168.10.11:41855 > 192.168.30.107:8888 S ...
    • 送信元（192.168.10.11）から宛先（192.168.30.107）のTCP/8888へSYNパケット（接続要求）を送信。

送信元から宛先ホスト（192.168.30.107）のTCP/8888へSYNパケットを3回送信しましたが、応答パケットは1つも返ってきませんでした（パケットロス 100%）。そのため、経路途中または宛先ホストのファイアウォール機能で通信がブロックされている可能性があると判断できます。

UDPモード

UDPモードの基本構文

$ nping --udp [オプション] <ターゲット>

UDPモードでは、指定した宛先ポートにUDPデータグラムを送信し、通信状況を確認します。UDPはTCPのようなコネクション確立処理を行わないため、応答が返ってこない場合でも、UDPサービスが停止しているとは断定できません。

  • アプリケーション応答あり → UDPサービスが稼働している（open）
  • ICMP Port Unreachable → 該当ポートは閉じている（closed）
  • 無応答 → サービス稼働中（open）か、通信が遮断されている（filtered）かを判別できない

この点は、UDPモードの実行結果を分析するうえで特に重要です。

サービスを待ち受けているポートの場合（宛先ポートがopenの場合）

$ sudo nping --udp -p 53 -c 3 192.168.30.107

Starting Nping 0.7.99 ( https://nmap.org/nping ) at 2026-09-07 04:48 JST
SENT (0.0136s) UDP 192.168.10.11:53 > 192.168.30.107:53 ttl=64 id=53175 iplen=28
SENT (1.0144s) UDP 192.168.10.11:53 > 192.168.30.107:53 ttl=64 id=53175 iplen=28
SENT (2.0162s) UDP 192.168.10.11:53 > 192.168.30.107:53 ttl=64 id=53175 iplen=28

Max rtt: N/A | Min rtt: N/A | Avg rtt: N/A
Raw packets sent: 3 (126B) | Rcvd: 0 (0B) | Lost: 3 (100.00%)
Nping done: 1 IP address pinged in 3.04 seconds
  • SENT ... UDP 192.168.10.11:53 > 192.168.30.107:53 ...
    • 送信元（192.168.10.11）のUDP/53から、宛先（192.168.30.107）のUDP/53へUDPパケットを送信。

宛先ホスト（192.168.30.107）上ではBIND9が正常稼働しているものの、送信したUDPパケットに対する応答がなく、パケット損失率は100%（Lost: 3）となっています。

--udpオプションはDNSクエリとして有効なペイロードを送っているわけではなく、単なるUDPパケットをUDP/53へ送信しているため、BIND9が応答していない可能性があります。したがって、この結果だけから「UDP/53が閉じている」「BIND9へ到達できない」とは判断できません。

BIND9の応答を確認する場合は、digコマンドで正しいDNSクエリを送信するか、Nmapのようにサービスの応答内容を判別できるツールを利用します。

例）NmapでUDP/53の状態を確認（実行結果の抜粋）

$ nmap -sU -p 53 -sV 192.168.30.107
PORT   STATE SERVICE VERSION
53/udp open  domain  ISC BIND 9.20.26-1~deb13u1 (Debian Linux)

※参考： Nmapコマンドの使い方を徹底解説！

サービスを待ち受けていない場合（宛先ポートがclosedの場合）

$ sudo nping --udp -p 123 -c 3 192.168.30.107

Starting Nping 0.7.99 ( https://nmap.org/nping ) at 2026-09-07 04:48 JST
SENT (0.0195s) UDP 192.168.10.11:53 > 192.168.30.107:123 ttl=64 id=12490 iplen=28
RCVD (0.0215s) ICMP [192.168.30.107 > 192.168.10.11 Port unreachable (type=3/code=3) ] IP [ttl=62 id=42999 iplen=56 ]
SENT (1.0197s) UDP 192.168.10.11:53 > 192.168.30.107:123 ttl=64 id=12490 iplen=28
RCVD (1.0215s) ICMP [192.168.30.107 > 192.168.10.11 Port unreachable (type=3/code=3) ] IP [ttl=62 id=43052 iplen=56 ]
SENT (2.0213s) UDP 192.168.10.11:53 > 192.168.30.107:123 ttl=64 id=12490 iplen=28
RCVD (2.0233s) ICMP [192.168.30.107 > 192.168.10.11 Port unreachable (type=3/code=3) ] IP [ttl=62 id=43183 iplen=56 ]

Max rtt: 1.951ms | Min rtt: 1.714ms | Avg rtt: 1.824ms
Raw packets sent: 3 (126B) | Rcvd: 3 (168B) | Lost: 0 (0.00%)
Nping done: 1 IP address pinged in 2.05 seconds
  • SENT ... UDP 192.168.10.11:53 > 192.168.30.107:123 ...
    • 送信元（192.168.10.11）のUDP/53から、宛先（192.168.30.107）のUDP/123へUDPパケットを送信。
  • RCVD ... ICMP [192.168.30.107 > 192.168.10.11 Port unreachable (type=3/code=3) ] ...
    • 宛先ホストからICMP Port Unreachable（ポート到達不能）を受信。（つまり、UDP/123で待ち受けているサービスが存在しない。）

送信した3つのUDPパケットすべてに応答があり、宛先ホスト（192.168.30.107）とはネットワークレベルで正常に通信できています。ただし、毎回ICMP Port Unreachableが返されているため、UDP/123は閉じている（サービスが待ち受けていない）と判断できます。

サマリ行のLost: 0 (0.00%)は、「UDP通信が正常に成立した」ことを示すものではありません。今回受信したパケットはUDP応答ではなく、宛先ポートが閉じていることを示すICMP Port Unreachableです。Npingでは、ICMPエラーを含め、何らかの応答があれば受信済みとしてカウントするため、宛先ポートが閉じている場合でもLost: 0 (0.00%)と表示されます。

ファイアウォールで接続を遮断している場合（宛先ポートがfilteredの場合）

$ sudo nping --udp -p 161 -c 3 192.168.30.107

Starting Nping 0.7.99 ( https://nmap.org/nping ) at 2026-09-07 04:48 JST
SENT (0.0123s) UDP 192.168.10.11:53 > 192.168.30.107:161 ttl=64 id=59486 iplen=28
SENT (1.0133s) UDP 192.168.10.11:53 > 192.168.30.107:161 ttl=64 id=59486 iplen=28
SENT (2.0148s) UDP 192.168.10.11:53 > 192.168.30.107:161 ttl=64 id=59486 iplen=28

Max rtt: N/A | Min rtt: N/A | Avg rtt: N/A
Raw packets sent: 3 (126B) | Rcvd: 0 (0B) | Lost: 3 (100.00%)
Nping done: 1 IP address pinged in 3.04 seconds
  • SENT ... UDP 192.168.10.11:53 > 192.168.30.107:161 ...
    • 送信元（192.168.10.11）のUDP/53から、宛先（192.168.30.107）のUDP/161へUDPパケットを送信。

実行結果では、送信したすべてのUDPパケットに対して応答がなく、パケットロス率100%となっています。ただし、UDPはTCPのような接続確立処理がなく、対象サービスが要求内容に応答しない場合もあるため、この結果だけでUDP/161が閉じている、またはホストに到達できないとは断定できません。

推定される原因
  • ホストが停止している
  • 経路上のファイアウォールでパケットを破棄している
  • 宛先ホストがICMPエラーメッセージを抑制している
  • 宛先ホストがUDP/161を遮断している

SNMPの稼働状況を確認する際は、実際に有効なSNMPリクエストを送信するか、nmap -sUコマンドなどを併用して総合的に判断する必要があります。

ICMPモード

ICMPモードの基本構文

$ nping --icmp [オプション] <ターゲット>

ICMPモードは、ICMPメッセージを生成して宛先ホストへ送信します。一般的なpingコマンドと同様、ホスト間のIPレベルの疎通確認に利用できます。通常のpingコマンドでもICMP Echo Requestによる疎通確認はできますが、Npingでは--icmp-typeオプションを用いてICMPタイプを指定することができます。

--icmp-typeオプションでICMPタイプを指定しない場合、pingと同じICMP Echo Requestが使用されます。

ICMP通信が許可されている場合

$ sudo nping --icmp -c 3 192.168.30.107

Starting Nping 0.7.99 ( https://nmap.org/nping ) at 2026-09-10 06:33 JST
SENT (0.0453s) ICMP [192.168.10.11 > 192.168.30.107 Echo request (type=8/code=0) id=12673 seq=1] IP [ttl=64 id=50686 iplen=28 ]
RCVD (0.0474s) ICMP [192.168.30.107 > 192.168.10.11 Echo reply (type=0/code=0) id=12673 seq=1] IP [ttl=62 id=23683 iplen=28 ]
SENT (1.0461s) ICMP [192.168.10.11 > 192.168.30.107 Echo request (type=8/code=0) id=12673 seq=2] IP [ttl=64 id=50686 iplen=28 ]
RCVD (1.0479s) ICMP [192.168.30.107 > 192.168.10.11 Echo reply (type=0/code=0) id=12673 seq=2] IP [ttl=62 id=23704 iplen=28 ]
SENT (2.0486s) ICMP [192.168.10.11 > 192.168.30.107 Echo request (type=8/code=0) id=12673 seq=3] IP [ttl=64 id=50686 iplen=28 ]
RCVD (2.0502s) ICMP [192.168.30.107 > 192.168.10.11 Echo reply (type=0/code=0) id=12673 seq=3] IP [ttl=62 id=23824 iplen=28 ]

Max rtt: 2.041ms | Min rtt: 1.514ms | Avg rtt: 1.757ms
Raw packets sent: 3 (126B) | Rcvd: 3 (138B) | Lost: 0 (0.00%)
Nping done: 1 IP address pinged in 2.08 seconds
  • SENT ... ICMP [192.168.10.11 > 192.168.30.107 Echo request (type=8/code=0) ...
    • 送信元（192.168.10.11）から宛先（192.168.30.107）へICMP Echo Requestを送信。
  • RCVD ... ICMP [192.168.30.107 > 192.168.10.11 Echo reply (type=0/code=0) ...
    • 宛先ホストからICMP Echo Replyを受信。

送信元（192.168.10.11）から宛先ホスト（192.168.30.107）へ送信した3回のICMP Echo Requestすべてに対してICMP Echo Reply を受信しており、パケットロスは発生していません。そのため、両ホスト間ではICMP通信が正常に成立しており、ネットワークレベルでの疎通に問題はないと判断できます。

ICMP通信が制限（DROP）されている場合

事前準備

宛先ホストのファイアウォール機能（nft）でICMPを遮断（DROP）する。

$ sudo nping --icmp -c 3 192.168.30.107

Starting Nping 0.7.99 ( https://nmap.org/nping ) at 2026-09-10 07:08 JST
SENT (0.0118s) ICMP [192.168.10.11 > 192.168.30.107 Echo request (type=8/code=0) id=23263 seq=1] IP [ttl=64 id=28708 iplen=28 ]
SENT (1.0124s) ICMP [192.168.10.11 > 192.168.30.107 Echo request (type=8/code=0) id=23263 seq=2] IP [ttl=64 id=28708 iplen=28 ]
SENT (2.0144s) ICMP [192.168.10.11 > 192.168.30.107 Echo request (type=8/code=0) id=23263 seq=3] IP [ttl=64 id=28708 iplen=28 ]

Max rtt: N/A | Min rtt: N/A | Avg rtt: N/A
Raw packets sent: 3 (126B) | Rcvd: 0 (0B) | Lost: 3 (100.00%)
Nping done: 1 IP address pinged in 3.04 seconds
  • SENT ... ICMP [192.168.10.11 > 192.168.30.107 Echo request (type=8/code=0) ...
    • 送信元（192.168.10.11）から宛先（192.168.30.107）へICMP Echo Requestを送信。

送信元（192.168.10.11）から宛先（192.168.30.107）へICMP Echo Requestは正常に送信しているものの、応答（ICMP Echo Reply）は1つも返ってきていません（損失率100%）。そのため、この結果だけを見る限り、ICMPによる疎通は確認できません。

考えられる原因には、次のようなものがあります。

  • 宛先ホストが停止している
  • 宛先ホストまでの経路に問題がある
  • 宛先ホスト側の設定で、ICMP Echo Requestに応答しないようになっている
  • ネットワーク経路上の機器でICMPが制限されている

「ICMPに応答しない = 宛先ホストが停止している」と判断しない。

実際のネットワーク環境では、セキュリティ上の理由などからICMP Echo Requestへの応答を無効化している機器があります。そのため、ICMP Echo Requestによる確認だけで判断せず、TCPやUDPなどのプローブ方式も併用して確認することが重要です。

ARP/RARPモード

ARP/RARPモードの基本構文

$ nping --arp [オプション] <ターゲット>

ARP/RARPモードでは、ARPやRARPに関連するパケットを生成できます。

ARP（Address Resolution Protocol）同一L2セグメント内で、IPv4アドレスに対応するMACアドレスを確認するためのプロトコル。
RARP（Reverse ARP）MACアドレスをもとに自身のIPアドレスを取得するためのプロトコル。現在はBOOTPやDHCPなどに置き換えられ、一般的なネットワーク構成ではほとんど利用されていません。

同一セグメント内のホストにARPリクエストを送信する

$ sudo nping --arp -c 3 192.168.10.106

Starting Nping 0.7.99 ( https://nmap.org/nping ) at 2026-09-10 07:29 JST
SENT (0.0465s) ARP who has 192.168.10.106? Tell 192.168.10.11
RCVD (0.0469s) ARP reply 192.168.10.106 is at 08:00:27:22:FB:7E
SENT (1.0471s) ARP who has 192.168.10.106? Tell 192.168.10.11
RCVD (1.0477s) ARP reply 192.168.10.106 is at 08:00:27:22:FB:7E
SENT (2.0496s) ARP who has 192.168.10.106? Tell 192.168.10.11
RCVD (2.0502s) ARP reply 192.168.10.106 is at 08:00:27:22:FB:7E

Max rtt: N/A | Min rtt: N/A | Avg rtt: N/A
Raw packets sent: 3 (126B) | Rcvd: 3 (138B) | Lost: 0 (0.00%)
Nping done: 1 IP address pinged in 2.09 seconds
  • SENT ... ARP who has 192.168.10.106? Tell 192.168.10.11
    • 送信元（192.168.10.11）から宛先（192.168.10.106）のMACアドレスを問い合わせるARP Requestを送信。
  • RCVD ... ARP reply 192.168.10.106 is at 08:00:27:22:FB:7E
    • 宛先ホストから「自分のMACアドレスは、08:00:27:22:FB:7E」というARP Replyを受信。

宛先ホスト（192.168.10.106）に対してARP Requestを3回送信したところ、すべて正常にARP Replyが返ってきました。このことから、宛先ホストは同一LAN上で稼働しており、L2（データリンク層）レベルで到達可能と判断できます。また、宛先ホストのMACアドレスは08:00:27:22:FB:7Eであることも確認できます。

別セグメントのホストにARPリクエストを送信する

$ sudo nping --arp -c 3 192.168.30.107

Starting Nping 0.7.99 ( https://nmap.org/nping ) at 2026-09-10 07:29 JST
SENT (0.0182s) ARP who has 192.168.30.107? Tell 192.168.10.11
SENT (1.0187s) ARP who has 192.168.30.107? Tell 192.168.10.11
SENT (2.0190s) ARP who has 192.168.30.107? Tell 192.168.10.11

Max rtt: N/A | Min rtt: N/A | Avg rtt: N/A
Raw packets sent: 3 (126B) | Rcvd: 0 (0B) | Lost: 3 (100.00%)
Nping done: 1 IP address pinged in 3.05 seconds
  • SENT ... ARP who has 192.168.30.107? Tell 192.168.10.11
    • 送信元（192.168.10.11）から宛先（192.168.30.107）のMACアドレスを問い合わせるARP Requestを送信。

宛先ホスト（192.168.30.107）に対してARP Requestを3回送信したところ、応答（ARP Reply）は返ってこず、結果は100%ロスとなりました。ARPは同一L2セグメント内でMACアドレスを解決するためのプロトコルです。ARP Requestはルーターを越えて転送されないため、別セグメント上の宛先ホストからARP Replyが返らないことは正常な動作です。

本検証で使用した送信元（192.168.10.11）と宛先（192.168.30.107）は、それぞれ「192.168.10.0/24」と「192.168.30.0/24」の異なるネットワークに属しています。

したがって、100%ロスという結果は「宛先ホストの停止」を示すものではなく、異なるセグメントのIPアドレスに対してARPを実施したことによる結果と判断できます。

Tracerouteモード

Tracerouteモードの基本構文

$ nping [プローブモード] --tr [オプション] <ターゲット>

Tracerouteモードでは、宛先ホストまでのネットワーク経路を確認できます。--trまたは--tracerouteを指定すると、TTL（Time To Live）を増加させながらプローブを送信し、途中のネットワーク機器から返されるICMPメッセージなどをもとに経路を確認します。

  • NpingのTracerouteは独立したプローブモードではなく、TCP、UDP、ICMPモードと組み合わせて使用します。
  • TCP Connect、およびARPモードは指定できません。
  • プロトコルを指定しない場合、デフォルトはICMPモードです。

Tracerouteモードが特に有効なのは、「どこまで通信できているのか」を切り分けたい場面です。例えば、宛先ホストから応答が得られない場合でも、途中まで経路を確認できれば、問題が発生している可能性のある区間を絞り込めます。

コマンド例

$ sudo nping --tr 192.0.2.1                # デフォルトはICMPモード
$ sudo nping --icmp --tr 192.0.2.1         # ICMPモード
$ sudo nping --tcp  --tr 192.0.2.1         # TCPモード
$ sudo nping --udp  --tr 192.0.2.1         # UCPモード

$ sudo nping --tcp  --tr -p 443 192.0.2.1  # TCPモードでポート指定
$ sudo nping --udp  --tr -p 54  192.0.2.1  # UDPモードでポート指定

ネットワーク機器の設定によっては、ICMPパケットが遮断されていてもTCPパケットは通過するなど、プロトコルごとに異なる結果が得られる場合があります。そのため、単一のプローブ結果のみで判断するのではなく、複数のプローブモードによる結果を検証し、総合的に判断することが重要です。

ICMPモードでTracerouteを実行する

$ sudo nping --tr -c 5 192.168.30.107

Starting Nping 0.7.99 ( https://nmap.org/nping ) at 2026-09-10 07:48 JST
SENT (0.0116s) ICMP [192.168.10.11 > 192.168.30.107 Echo request (type=8/code=0) id=46299 seq=1] IP [ttl=1 id=35738 iplen=28 ]
RCVD (0.0123s) ICMP [192.168.10.254 > 192.168.10.11 TTL=0 during transit (type=11/code=0) ] IP [ttl=64 id=59416 iplen=56 ]
SENT (1.0119s) ICMP [192.168.10.11 > 192.168.30.107 Echo request (type=8/code=0) id=46299 seq=2] IP [ttl=2 id=35738 iplen=28 ]
RCVD (1.0136s) ICMP [192.168.20.253 > 192.168.10.11 TTL=0 during transit (type=11/code=0) ] IP [ttl=63 id=41510 iplen=56 ]
SENT (2.0134s) ICMP [192.168.10.11 > 192.168.30.107 Echo request (type=8/code=0) id=46299 seq=3] IP [ttl=3 id=35738 iplen=28 ]
RCVD (2.0155s) ICMP [192.168.30.107 > 192.168.10.11 Echo reply (type=0/code=0) id=46299 seq=3] IP [ttl=62 id=16754 iplen=28 ]
SENT (3.0167s) ICMP [192.168.10.11 > 192.168.30.107 Echo request (type=8/code=0) id=46299 seq=4] IP [ttl=4 id=35738 iplen=28 ]
RCVD (3.0185s) ICMP [192.168.30.107 > 192.168.10.11 Echo reply (type=0/code=0) id=46299 seq=4] IP [ttl=62 id=16806 iplen=28 ]
SENT (4.0182s) ICMP [192.168.10.11 > 192.168.30.107 Echo request (type=8/code=0) id=46299 seq=5] IP [ttl=5 id=35738 iplen=28 ]
RCVD (4.0204s) ICMP [192.168.30.107 > 192.168.10.11 Echo reply (type=0/code=0) id=46299 seq=5] IP [ttl=62 id=16916 iplen=28 ]

Max rtt: 2.207ms | Min rtt: 0.626ms | Avg rtt: 1.642ms
Raw packets sent: 5 (210B) | Rcvd: 5 (250B) | Lost: 0 (0.00%)
Nping done: 1 IP address pinged in 4.05 seconds
  • SENT ... ICMP [192.168.10.11 > 192.168.30.107 Echo request (type=8/code=0) ... seq=1 ... ttl=1 ...
    • TTL=1のICMP Echo Requestを宛先（192.168.30.107）へ送信。
  • RCVD ... ICMP [192.168.10.254 > 192.168.10.11 TTL=0 during transit (type=11/code=0) ] ...
    • 1ホップ目の192.168.10.254でTTLが0になり、ICMP Time Exceededを受信。（1ホップ目の機器を確認）
  • SENT ... ICMP [192.168.10.11 > 192.168.30.107 Echo request (type=8/code=0) ... seq=2 ... ttl=2 ...
    • TTLを2に増やして、ICMP Echo Requestを送信。
  • RCVD ... ICMP [192.168.20.253 > 192.168.10.11 TTL=0 during transit (type=11/code=0) ] ...
    • 2ホップ目の192.168.20.253でTTLが0になり、ICMP Time Exceededを受信。（2ホップ目の機器を確認）
  • SENT ... ICMP [192.168.10.11 > 192.168.30.107 Echo request (type=8/code=0) ... seq=3 ... ttl=3 ...
    • TTLを3に増やして、ICMP Echo Requestを送信。
  • RCVD ... ICMP [192.168.30.107 > 192.168.10.11 Echo reply (type=0/code=0) ...
    • 宛先（192.168.30.107）に到達し、ICMP Echo Replyを受信。（宛先には3ホップで到達）

送信元（192.168.10.11）から宛先（192.168.30.107）までの経路は、192.168.10.254 → 192.168.20.253 → 192.168.30.107の順で、3ホップで到達しています。宛先ホストから正常にICMP Echo Replyが返されており、パケットロスも0%で通信状態は正常と判断できます。

なお、--trは宛先到達後も指定回数までTTLを増やして送り続けるため、seq=4/5はseq=3と同じICMP Echo replyが重複しているだけで、追加の情報はありません。

TCPモードでTracerouteを実行する

$ sudo nping --tcp --tr -c 5 192.168.30.107

Starting Nping 0.7.99 ( https://nmap.org/nping ) at 2026-09-10 07:49 JST
SENT (0.0126s) TCP 192.168.10.11:33168 > 192.168.30.107:80 S ttl=1 id=62352 iplen=40  seq=1621394702 win=1480
RCVD (0.0131s) ICMP [192.168.10.254 > 192.168.10.11 TTL=0 during transit (type=11/code=0) ] IP [ttl=64 id=46290 iplen=68 ]
SENT (1.0133s) TCP 192.168.10.11:33168 > 192.168.30.107:80 S ttl=2 id=62352 iplen=40  seq=1621394702 win=1480
RCVD (1.0143s) ICMP [192.168.20.253 > 192.168.10.11 TTL=0 during transit (type=11/code=0) ] IP [ttl=63 id=19474 iplen=68 ]
SENT (2.0152s) TCP 192.168.10.11:33168 > 192.168.30.107:80 S ttl=3 id=62352 iplen=40  seq=1621394702 win=1480
RCVD (2.0167s) TCP 192.168.30.107:80 > 192.168.10.11:33168 SA ttl=62 id=0 iplen=44  seq=782185674 win=64240 <mss 1460>
SENT (3.0170s) TCP 192.168.10.11:33168 > 192.168.30.107:80 S ttl=4 id=62352 iplen=40  seq=1621394702 win=1480
RCVD (3.0185s) TCP 192.168.30.107:80 > 192.168.10.11:33168 SA ttl=62 id=0 iplen=44  seq=797838780 win=64240 <mss 1460>
SENT (4.0194s) TCP 192.168.10.11:33168 > 192.168.30.107:80 S ttl=5 id=62352 iplen=40  seq=1621394702 win=1480
RCVD (4.0214s) TCP 192.168.30.107:80 > 192.168.10.11:33168 SA ttl=62 id=0 iplen=44  seq=813506437 win=64240 <mss 1460>

Max rtt: 1.980ms | Min rtt: 0.359ms | Avg rtt: 1.247ms
Raw packets sent: 5 (270B) | Rcvd: 5 (274B) | Lost: 0 (0.00%)
Nping done: 1 IP address pinged in 4.05 seconds
  • SENT ... TCP 192.168.10.11:33168 > 192.168.30.107:80 S ttl=1 ...
    • TTL=1のSYNパケットを宛先（192.168.30.107）のTCP/80へ送信。
  • RCVD ... ICMP [192.168.10.254 > 192.168.10.11 TTL=0 during transit (type=11/code=0) ] ...
    • 1ホップ目の192.168.10.254でTTLが0になり、ICMP Time Exceededを受信。（1ホップ目の機器を確認）
  • SENT ... TCP 192.168.10.11:33168 > 192.168.30.107:80 S ttl=2 ...
    • TTLを2に増やしたSYNパケットを送信。
  • RCVD ... ICMP [192.168.20.253 > 192.168.10.11 TTL=0 during transit (type=11/code=0) ] ...
    • 2ホップ目の192.168.20.253でTTLが0になり、ICMP Time Exceededを受信。（2ホップ目の機器を確認）
  • SENT ... TCP 192.168.10.11:33168 > 192.168.30.107:80 S ttl=3 ...
    • TTLを3に増やしたSYNパケットを送信。
  • RCVD ... TCP 192.168.30.107:80 > 192.168.10.11:33168 SA ...
    • 宛先（192.168.30.107）のTCP/80からSYN/ACKを受信。（宛先には3ホップで到達）
  • 〜 以降の解説は省略〜
    • 既に宛先ホストに到達済みなので、TTLを増やしても結果は同じ。（SYN/ACKが返るだけ）

送信元（192.168.10.11）から宛先（192.168.30.107）までは、192.168.10.254 → 192.168.20.253 → 192.168.30.107の順に到達しており、2台の中継機器を経由しています。また、宛先ホストのTCP/80からSYN/ACKが返ってきているため、192.168.30.107の80番ポートは到達可能で、TCP接続を受け付けている状態と判断できます。

Googleで当サイトの記事を見つけやすくする

「優先するソース」に追加すると、Google検索やAIモードで当サイトの記事が見つけやすくなります。

Googleで優先するソースとして追加

■ セキュリティ情報サイト

セキュリティ実践ラボ
AlmaLinux Ubuntu プラットフォーム診断 疎通確認 経路確認
デフォラボ

この記事が気に入ったら
フォローしてね！

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