Windows Serverで開いているポートを確認する方法

Windows Server で開いているポートを確認するには、まずローカルリスナーの一覧を表示し、別のコンピューターからクライアントがそれらのポートにアクセスできるかどうかをテストします。リスニングポートはネットワーク経由で自動的にアクセスできるわけではありません。サービスバインディング、Windows ファイアウォール、ネットワークファイアウォール、ルーティング、NAT など、さまざまな要因がアクセスに影響を与える可能性があります。スキャンは、所有しているシステム、または評価する権限のあるシステムのみにしてください。

PowerShellを使用してローカルTCPリスナーを一覧表示します

サーバー上でPowerShellを開き、状態Get-NetTCPConnectionを指定して実行しますListen。ポートでソートするとリストが見やすくなり、選択された列にはアドレス、ポート、プロセスIDが表示されます。

Get-NetTCPConnection -State Listen | Sort-Object LocalPort | Select-Object LocalAddress,LocalPort,OwningProcess

各行は、リスニング状態にあるTCPエンドポイントです。アドレスが0.0.0.0または の::場合、リスナーはそれぞれすべてのIPv4インターフェースまたはIPv6インターフェースにバインドされています。127.0.0.1やなどのアドレス::1はループバック専用であるため、リモートコンピュータはネットワークインターフェースを介してそのリスナーに接続できません。

1つのポートを検査するには、クエリにそのポート番号を追加します。

Get-NetTCPConnection -State Listen -LocalPort 443 | Select-Object LocalAddress,LocalPort,OwningProcess

返されたプロセス ID を使用して所有者を特定します。たとえば、Get-Process -Id 1234(出力の PID に置き換えてください) のように使用します。Microsoft は、Get-NetTCPConnection のリファレンス1234で、コマンドレットの接続状態、ローカル ポート、所有プロセス フィールドについて説明しています。

netstatを使用してリスナーとプロセスIDを確認します。

netstatコマンドプロンプトまたはPowerShellから動作する組み込みの代替手段です。このコマンドは、出力をリッスンしているTCPポートにフィルタリングします。

netstat -ano -p tcp | findstr LISTENING

スイッチの意味は次のとおりです。-aリスナーを含める、-nアドレスを数値のままにする、-oPIDを追加する、-p tcp表示をTCPに限定する。タスク マネージャーでPIDを照合するか、を使用しますGet-Process -Id 1234。UDPエンドポイントの場合は、を実行しますnetstat -ano -p udp。UDPにはTCPスタイルのLISTENING状態はありません。Microsoftのnetstatリファレンスを参照してください。

Microsoft PortQryでポートを確認する

PortQry バージョン 2は、TCP および UDP ポートをチェックするための Microsoft の独立したユーティリティです。これをダウンロードして、などのフォルダーに展開しC:\Tools\PortQryV2、そこで PowerShell を開きます。そのコンピューターでアクティブなマッピングを一覧表示するには、次のコマンドを実行します。

.\PortQry.exe -local

ローカルモードでは、アクティブなTCPおよびUDPマッピングが表示され、プロセスIDも含まれる場合があります。これはインベントリ管理に使用し、リモート接続性の確認には使用しないでください。別のサーバーに問い合わせるには、サーバー名またはIPアドレス、プロトコル、ポート番号を指定します。

.\PortQry.exe -n server01.example.com -p tcp -e 443

リモートクエリの場合、LISTENINGは PortQry が応答を受信したことを意味します。NOT LISTENINGはリスナーがないことを示す応答を受信したことを意味します。 はFILTERED応答がないことを意味するため、ファイアウォールがトラフィックを破棄している可能性があり、プロセスがリッスンしている場合とそうでない場合があります。UDP は、サービスがフォーマットされていないプローブを無視する可能性があるため、より不確実な場合があります。Microsoft のPortQry ガイドを参照してください。

別のコンピュータからの接続性をテストする

サーバー上で実行したチェックでは、別のネットワーク上のクライアントが接続できることを証明することはできません。検証したいパス上のWindowsクライアントから、以下を実行してください。

Test-NetConnection -ComputerName server01.example.com -Port 443 -InformationLevel Detailed

ホスト名とポート番号を実際の値に置き換えてください。 は、TcpTestSucceeded : Trueその時点でそのクライアントからの TCP 接続を確認します。Falseは失敗を報告しますが、原因がリスナー、ファイアウォール、ルーティング、DNS、またはアップストリームフィルタの不足であるかどうかは特定しません。 Microsoft のTest-NetConnection リファレンスを参照してください。

視覚的なスキャンを行うには、Nmapを公式ダウンロードページからインストールしてください。WindowsインストーラーにはZenmapが含まれています。選択したポートを確認するには、以下を実行してください。

nmap -p 80,443 server01.example.com

Zenmap では、認証済みのターゲットを入力し、プロファイルを選択してスキャンを実行し、結果を確認しますPorts / Hosts。Nmap の基本的なターゲット スキャンでは、最も一般的な 1,000 個の TCP ポートがチェックされます。-pこれを使用して範囲を絞り込むことができます。状態は、Nmap がそのクライアントから見ているものを表します。openは、アプリケーションが接続を受け入れていることを意味し、closedは、アプリケーションがリッスンしていないことを意味し、は、filtered障害物によって Nmap が状態を判断できないことを意味します。Zenmapガイドを参照してください。

結果をどう活用するか

PowerShellでリスナーが表示されるにもかかわらずクライアントテストが失敗する場合は、サービスのバインドアドレス、一致する受信ルールとそのネットワークプロファイル、および上流のファイアウォール、セキュリティグループ、ルーター、またはNATを確認してください。許可ルールはリスナーを作成しません。サービスがポートにバインドする必要があります。

見慣れないリスナーの場合は、PIDを使用してアプリケーションを特定し、変更する前に必要かどうかを確認してください。使用されていないサービスや受信ルールは、通常の変更プロセスに従って制限または削除し、重要なクライアントパスから再テストしてください。1回のスキャンでは、その視点からの到達可能性しか示されません。