Windowsでポートのリッスン状態を調査する：Tech TIPS

あるTCPのポートがリッスンされているかどうかを調べるにはtelnetで接続してみるとよい。netsh diagコマンドを使うと、Proxyやメール・サーバとの通信テストが簡単に行える。portqryコマンドを使うと、ポート・スキャンなど、より高機能な通信テストが行える。

» 2003年07月12日 00時00分公開

[打越浩幸，デジタルアドバンテージ]

連載目次

対象OS：Windows 2000 Professional／Windows XP Home Edition／Windows XP Professional／Windows 2000 Server／Windows 2000 Advanced Server／Windows Server 2003

解説をスキップして操作手順を今すぐ読む→

解説

　TCP/IPネットワークがつながらないといったトラブルが発生した場合、まず確認するのはpingコマンドによる応答があるかどうかであろう。これにより相手のサーバが生きているかどうかや、そのサーバまでの経路が有効であるかどうかなどが分かる。

　そしてpingテストがパスすれば、次は特定のTCPやUDPのポートに対する接続テストを行い、サーバとクライアント間で通信が正しくできているかどうかを調べる、というのが一般的なところだろうか。

　この接続性のテストのためにはいくつかの方法やツールがあるので、ここではそれらについてまとめておく。

操作方法

■記事内目次

●telnetコマンドを使って調査する

　telnetは、TCPプロトコルを使って相手のコンピュータと接続するためのコマンドである。通常はtelnetポート（TCPの23番ポート）に接続して利用するが、ポート番号を変えれば、TCPの接続確認用ツールとして利用することもできる。

関連記事： Telnetクライアントの使い方

　例えばWebサーバとの接続テストを行うためには、次のようなコマンドを実行すればよい。telnetに続けて、接続先のサーバ名とTCPのポート番号（標準的なHTTPプロトコルなら80）を指定する。

C:\>telnet server 80
接続中: server...
エスケープ文字は 'CTRL+]' です
……（以下省略）……

　以上はうまく接続できた場合の例である。Webサーバ（HTTPプロトコル）との通信では、クライアント側から何かのコマンドを送信しない限り、サーバは応答を返してこない。適当にリターン・キーを何回か押してみれば、サーバ側の応答が確認できるだろう（telnetを強制終了させるには、上記のTIPSを参照のこと）。

　これに対して、サーバ側から何も応答がない場合や、接続を拒否された場合は次のようになる（相手側サーバが無応答の場合は、エラーとなるまでに時間がかかる）。

C:\>telnet server 80
接続中: server...ホストへ接続できませんでした。ポート番号 80: 接続に失敗しました

　このような応答の違いを区別することにより、あるポートでサーバがリッスンしているかどうかを判断することができるだろう。さらに同時に（別のコマンド・プロンプト上で）netstatコマンドを実行してみれば、通信の状態がよりよく分かると思う

関連記事： netstatコマンドを使いこなす

　telnetはどのWindows OSでも用意されているコマンドなので、いつでもどこでも利用できるというのがメリットである。

●netsh diagコマンドで調査する

　Windows XPやWindows Server 2003では、以上のほかに、netsh diagコマンドを使うという方法もある（Windows 2000のnetshコマンドでは利用できない）。

　netsh.exeは、ネットワーク関連の設定を行ったり、動作を確認したりするためのコマンドである。コマンド・プロンプト上で利用する。

　netshには多くのサブコマンドがあり、そのうちの1つにdiagという診断用のサブコマンドがある。そしてその下にさらにいくつかの機能が用意されている。

　ネットワークの接続性のテストのためには、netsh diag connectというコマンドを利用する。使い方は以下のとおりである。

C:\>netsh diag connect

使用できるコマンドは次のとおりです:

このコンテキストのコマンド:
connect ieproxy -     Internet Explorer のプロキシへ接続します。
connect iphost -     ユーザー定義の IP ホストに接続します。
connect mail   -     メールサーバへ接続します。
connect news   -     ニュースサーバへ接続します。

　このnetshというコマンドはインタラクティブに使うことも可能だ。ただし今回は「netsh diag connect ……」というふうに、すべてのパラメータを指定して利用する方法を紹介する。

■Proxyサーバのテスト

　「netsh diag connect ieproxy」というコマンドを実行すると、現在のInternet ExplorerのProxyサーバ設定に基づいて、Proxyサーバとの通信テストを行う。

　テスト内容としては、指定されたサーバのTCPポートに対して、TCPで接続を試み、接続が確立（establish）すればOKと見なされる（実際にHTTPプロトコルのコマンドをやりとりするわけではない。接続確立後はすぐにクローズする）。

C:\>netsh diag connect ieproxy

Internet Explorer Web プロキシ (192.168.0.13)
    IEProxyPort = 8080
    IEProxy = 192.168.0.13
    サーバは次のポートで実行中と思われます [8080]

　Proxyサーバ（192.168.0.13の8080番ポートでリッスンしている）との通信が正常に行えると、最後の行のように「サーバは次のポートで実行中と思われます [8080]」という結果が戻ってくる。Proxyサーバとの通信が失敗すると、最後の [ ] の内部は、ポート番号ではなく、[なし] となる。

■メール／ニュース・サーバとの通信

　Proxyサーバとの通信テストと同様に、「netsh diag connect mail」や「netsh diag connect news」というコマンドを実行すると、Outlook Expressに設定されているメール・サーバやニュース・サーバ（いずれも最初の1つのサーバしかテストしない）に対して、TCPで接続をすることができるかどうかを調査する。

　これらの各種サーバとの接続テストは、「ネットワークの診断ツール」が自動的に行うテスト内容と同じである。

関連記事：ネットワークの診断ツールを活用する

■任意のTCPポートとの接続テスト

　任意のTCPポートとの接続をテストするためには「netsh diag connect iphost サーバポート」と指定する。これにより、指定されたサーバの指定されたTCPポートに対して接続要求を行い、その結果を表示する。データをやりとりするわけではなく、単にTCPの接続が確立すれば、それだけで結果はOKとなる。

C:\>netsh diag connect iphost www.microsoft.com 80

IPHost (www.microsoft.com)
    IPHost = www.microsoft.com
    Port = 80
    サーバは次のポートで実行中と思われます [80]

　これは、www.microsoft.comというサーバの、TCPのポート80番へ接続できるかどうかをテストしたものである。最後が [80] となっているのは、ポート80番への接続が成功したことを示している。失敗するとこの部分が [なし] となる。

●portqryコマンドで調査する

　以上の接続テストは、OSが標準で持っているツールを使ったが、それ以外にも便利なツールはいくつかある。例えばマイクロソフトからはportqry.exe（port query）という、より高機能なツールが提供されている（Windows 2000上でも利用可能）。

Portqry.exe コマンドラインユーティリティの説明（マイクロソフトサポート技術情報）

　このWebページの最後にあるリンクからツールをダウンロードして実行すると、portqry.exeというコマンドとreadme.txtというドキュメントが展開される。

　このツールは、いわゆるポート・スキャン・ツールの一種であり、指定された（範囲の）ポートに対して、TCPやUDPで接続テストを行う。くれぐれも不用意にインターネット上のホストに対して使わないこと。そのような行為はクラッキングと見なされることがある。

C:\>PortQry.exe

Displays the state of TCP and UDP ports.

PortQry Usage:
PortQry.exe -n server [-p protocol] [-e || -r || -o endpoint(s)]
        [-l logfile] [-s] [-i] [-q]

Where:
        -n [server] IP address or name of server to query
        -p [protocol] TCP or UDP or BOTH (default is TCP)
        -e [endpoint] single port to query (valid range: 1-65535)
        -r [end point range] range of ports to query (start:end)
        -o [end point order] range of ports to query in an order (x,y,z)
        -l [logfile] name of log file to create
        -s 'slow link delay' waits longer for UDP replies from remote systems
        -i by-passes default IP address-to-name lookup
           ignored unless an IP address is specified after -n
        -q 'quiet' operation runs with no output
           returns 0 if port is listening
           returns 1 if port is not listening
           returns 2 if port is listening or filtered

Notes:
        PortQry runs on Windows 2000 and later
        Defaults: TCP, port 80, no log file, slow link delay off
        Hit Ctrl-c to terminate prematurely

examples:
portqry -n myserver.com -e 25
portqry -n 10.0.0.1 -e 53 -p UDP -i
portqry -n host1.dev.reskit.com -r 21:445
portqry -n 10.0.0.1 -o 25,445,1024 -p both

　このツールは、先ほどのtelnetやnetsh diagコマンドと異なり、より高機能な通信テストが行える。まず、TCPだけでなくUDPのテストも行うことができる。またポート番号の範囲を指定して、連続してテストを行うことができる。

　さらにいくつかの特定のポートについては、そのプロトコル特有のコマンドを発行するなど、単なる接続と切断だけではない高度なテストを行うことができる。

　具体的には、DNS（53番）、LDAP（389番）、MS-RPC（135番。RPCのポート・マッパ）、NetBIOS名前サービス（137番）などである。これらのポートをテストしようとすると、それぞれのプロトコルに応じて、より詳細なテストを行い、その結果を表示する。

　まずは、あるサーバのポート80番（TCPとUDPの両方）に対して接続性テストをしてみよう。

C:\>portqry -n server -p both -e 80

Querying target system called:

server01

Attempting to resolve name to IP address...

Name resolved to 192.168.0.13

TCP port 80 (http service): LISTENING

UDP port 80 (unknown service): NOT LISTENING

　この場合は、TCPの80番ポートとは通信ができたが（「LISTENING（リッスンしている）」と表示されている）、UDPの80番ポートとは何も通信ができなかったため、「NOT LISTENING（リッスンしていない）」という結果が表示されている。

　これ以外にも「FILTERED（フィルタされている）」という結果が返されることもある。「NOT LISTENING」は、サーバから何らかの拒否応答が戻ってくるのに対して、「FILTERED」の場合は、肯定応答も拒否応答も何も戻ってこないことを示している。一般的には、ファイアウォールなどで通信を完全にブロックしている場合には、このような応答が返ってくることが多い。

　ただしUDPを使ったサービスでは単にUDPパケットを送信するだけでは何も応答を返さないものが多い。UDPのリッスン状態の判断方法やその結果の見方については、portqryに付属のドキュメントを参照していただきたい。

　では次にMS-RPCポート（ポート135番）のテストをしてみよう。

C:\>portqry -n server01 -p both -e 135

Querying target system called:

server

Attempting to resolve name to IP address...

Name resolved to 192.168.0.13

TCP port 135 (epmap service): LISTENING
Querying Endpoint Mapper Database...
Server's response:

UUID: 8cfb5d80-31a4-11cf-a7d8-00805f48a135
ncacn_np:\\\\SERVER[\\PIPE\\SMTPSVC]

UUID: ecec0e70-a603-11d0-96b1-00a0c92ece31 NTDS Backup Interface
ncacn_np:\\\\SERVER[\\PIPE\\lsass]

UUID: ecec0e70-a603-11d0-96b1-00a0c92ece31 NTDS Backup Interface
ncalrpc:[LRPC00000118.00000001]
……（以下省略）……

　このように、RPCのポート・マッパを介して提供されているサービスの一覧が表示されている。同様にLDAP（389番）の場合は、LDAPプロトコルを通じてアクセスできるディレクトリ情報が表示される。

C:\>portqry -n SERVER -p both -e 389

Querying target system called:

SERVER

Attempting to resolve name to IP address...

Name resolved to 192.168.0.13

TCP port 389 (ldap service): LISTENING

Sending LDAP query to TCP port 389...

LDAP query response:

currentdate: 07/10/2003 04:14:31 (unadjusted GMT)
subschemaSubentry: CN=Aggregate,CN=Schema,CN=Configuration,DC=d-advantage,DC=com
dsServiceName: CN=NTDS Settings,CN=SERVER,CN=Servers,CN=Digital-Advantage-Headquarters,CN=Sites,CN=Configuration,DC=d-dvantage,DC=com
namingContexts: CN=Schema,CN=Configuration,DC=d-advantage,DC=com
defaultNamingContext: DC=d-advantage,DC=com
schemaNamingContext: CN=Schema,CN=Configuration,DC=d-advantage,DC=com
……（以下省略）……