ネットワークトラブルの救世主！PowerShellのTest-NetConnectionを使いこなそう

「サーバーに繋がらない…」「特定のサービスだけ応答がない…」

ITインフラに関わる仕事をしていると、こうしたネットワークのトラブルに遭遇しない日はありません。そんな時、皆さんはどんなツールを使っていますか？

古くから「とりあえずping」という言葉があるように、pingコマンドでICMPパケットを送って疎通確認をするのが第一歩、という方は多いでしょう。特定のポートが開いているか確認したい場合はtelnetコマンドを叩き、通信経路で問題が起きていないか調べたいときはtracert（traceroute）コマンドを使う…といったように、状況に応じて複数のコマンドを使い分けるのがこれまでの常識でした。

しかし、これらのコマンドにはいくつかの弱点があります。

こうした”ネットワークトラブルシューティングあるある”を、スマートに解決してくれるのが、今回ご紹介するPowerShellのコマンドレット**Test-NetConnection**です。

Windowsのネットワークの管理や調査をやったことがある人は、この便利さがわかると思います。

Test-NetConnectionとは？ – ネットワーク診断のオールインワンツール

Test-NetConnectionは、Windows PowerShell 4.0から標準で搭載されたコマンドレット（PowerShellで使えるコマンドのこと）です。その名の通り、ネットワーク接続をテストするためのものですが、その機能は単なる接続テストにとどまりません。

一言でいうなら、ping、tracert、TCPポートスキャンなどの機能を一つに統合した、高機能なネットワーク診断ツールです。PowerShellさえ使えれば追加のインストールは不要で、誰でもすぐに利用開始できます。

このコマンド一つで、以下のような様々な情報を一度に、あるいは選択的に取得することが可能です。

それでは早速、その使い方を基本的なものから見ていきましょう。

基本的な使い方 – pingより便利な基本テスト

最もシンプルな使い方は、引数にホスト名やIPアドレスを指定するだけです。PowerShellを開いて、次のように入力してみましょう。

Test-NetConnection www.google.com

これを実行すると、以下のような結果が返ってきます。

ComputerName     : www.google.com
RemoteAddress    : 172.217.26.3
InterfaceAlias   : Wi-Fi
SourceAddress    : 192.168.1.10
PingSucceeded    : True
PingReplyDetails : Reply from 172.217.26.3: bytes=32 time=5ms TTL=117

この結果を見るだけで、pingコマンドよりも多くの情報が得られていることがわかります。

たったこれだけのコマンドで、「①DNSの名前解決」と「②ICMPでの疎通確認」という、トラブルシューティングの最初の2ステップを一度に完了できてしまうのです。これは非常に効率的です。

応用的な使い方 – このコマンドの真骨頂

Test-NetConnectionの本当の価値は、ここから紹介するオプションにあります。

1. ポートを指定した接続確認 (これが一番便利！)

おそらく、このコマンドレットで最もよく使われる機能が、TCPポートを指定した接続テストでしょう。例えば、WebサーバーのHTTPS（ポート443）が応答するかどうかを確認したい場合、次のように実行します

Test-NetConnection www.google.com -Port 443

実行結果は以下のようになります。

ComputerName           : www.google.com
RemoteAddress          : 172.217.26.3
RemotePort             : 443
InterfaceAlias         : Wi-Fi
SourceAddress          : 192.168.1.10
TcpTestSucceeded       : True

注目すべきは最後の行、**TcpTestSucceededです。これがTrueであれば、指定したポート（443）に対してTCP接続が成功した、つまり「ポートが開いていて、サービスが応答可能な状態にある」**ことを意味します。

もし、サーバー側のファイアウォールでポートが閉じられていたり、サービスが起動していなかったりした場合は、TcpTestSucceededはFalseと表示されます。

これは、「ポート389（LDAP）が開いているか確認する」といったシナリオで絶大な威力を発揮します。telnetコマンドのように別途有効化する必要もなく、ただ-Portオプションを追加するだけで、あらゆるTCPポートの疎通確認ができてしまうのです。

【具体例】

2. ネットワーク経路の確認 (tracertの代替)

通信がどこかで遅くなっている、あるいは途絶している、といった問題を調査したい場合は-TraceRouteオプションが役立ちます。

Test-NetConnection www.google.com -TraceRoute

これを実行すると、tracertコマンドと同様に、宛先に到達するまでに経由するルーター（ホップ）の一覧とその応答時間が表示されます。ネットワーク経路のどこにボトルネックがあるのかを特定するのに非常に便利です。

3. 詳細な診断情報を表示

より包括的な情報が必要な場合は、-InformationLevel Detailedオプションを追加します。

Test-NetConnection www.google.com -InformationLevel Detailed

これを実行すると、基本的なテスト結果に加えて、DNS解決の詳細な結果、IPアドレスの構成情報、TCP接続のシーケンスなど、非常に詳細な情報が出力されます。問題の切り分けが難しい場合に、根本原因を探るための強力な手掛かりとなります。

実践！トラブルシューティングシナリオ

では、実際のトラブルシューティングでTest-NetConnectionがどのように役立つか、具体的なシナリオで見てみましょう。

シナリオ：新しく構築した社内Webサーバー webapp.local にブラウザからアクセスできない！

Step 1: 基本的な疎通確認

まずはpingと名前解決が正常かを確認します。

PS> Test-NetConnection webapp.local

ComputerName     : webapp.local
RemoteAddress    : 192.168.10.50
...
PingSucceeded    : True

PingSucceededがTrueなので、サーバーはネットワーク的に到達可能で、名前解決もできています。問題はサーバーのサービスレイヤーにありそうです。

Step 2: Webポートの確認

次に、Webサーバーが使用するHTTPポート（80番）が開いているかを確認します。

PS> Test-NetConnection webapp.local -Port 80

ComputerName           : webapp.local
...
TcpTestSucceeded       : False

TcpTestSucceededがFalseと出ました！これが原因のようです。サーバーには到達できるものの、80番ポートでの通信ができていません。

原因の推測と対策

この結果から、以下のいずれかが原因である可能性が高いと推測できます。

1. サーバーOSのファイアウォールが80番ポートの受信をブロックしている。
2. Webサーバーのソフトウェア（IIS, Apacheなど）が起動していない、または80番ポートで待ち受けていない。

この切り分けにより、ネットワーク担当者は「サーバーOSの設定を確認してください」と、サーバー管理者へ的確な依頼を出すことができます。闇雲に「ネットワークが悪い！」と騒ぐ前に、原因をロジカルに説明がきます

まとめ

Test-NetConnectionは、Windows環境におけるネットワークトラブルシューティングの進め方を大きく変える可能性を秘めた、非常に強力なコマンドレットです。

• シンプル: pingのように手軽に使える。
• 多機能: telnetやtracertの役割もこれ一つでこなせる。
• 情報豊富: 必要な情報が構造化されて表示され、状況を正確に把握できる。

これまで複数のコマンドを叩いて断片的な情報を集めていた作業が、Test-NetConnectionを使えば、より体系的かつ効率的に行えます。ぜひ使ってみてください。