Pingよりも高機能！ ネットワーク管理者のための「PsPing」活用法：山市良のうぃんどうず日記（166）

「Ping」コマンドは、TCP/IPネットワークの管理者には欠かせない、プラットフォームを問わずに利用できるユーティリティーです。今回は、Pingコマンドよりも高度なユーティリティーであるWindows Sysinternalsの「PsPing」について、応用的な活用法を紹介します。

[山市良，テクニカルライター]

山市良のうぃんどうず日記

PsPingとPingとはこんなに違う！

　TCP/IPネットワークの管理者なら自明のことだと思いますが、「Ping」コマンドはICMP（Internet Control Message Protocol）エコー要求／応答を利用して、ネットワーク上のホストとの接続性やネットワークレイテンシ（ラウンドトリップ、往復時間）をテストするツールです。

　Microsoftのフリーのユーティリティー集である「Windows Sysinternals」には、Pingコマンドに名前も機能もよく似た「PsPing.exe」（以下、PsPing）ツールがあります。Windows標準の「Ping.exe」コマンドは1ミリ秒の精度でしか計測できませんが、PsPingはその100倍の0.01ミリ秒の精度で応答時間やレイテンシを計測することができます。

• PsPing v2.1［英語］（Windows Sysinternals）

　しかし、PsPingはPingの単なる高精度版ではありません。第1に、PsPingは特定のTCPポートに対する接続要求の送信と応答時間の計測を行う「TCP Ping」機能も備えています（画面1）。第2に、PsPingは指定したTCPポートをバインドしてサーバとして機能することができ、その接続を介してTCP/UDPのレイテンシテスト、帯域幅テストを実行することもできます（画面2）。

画面1　Windows標準のPing.exeは1ミリ秒の精度しかないが（画面手前）、Windows SysinternalsのPsPingは0.01ミリ秒の精度を持ち、ICMPだけでなく、TCPの接続性の確認や応答時間を計測することもできる（画面奥）

画面2　TCP/UDPのレイテンシテストおよび帯域幅テスト用に、PsPingにはサーバモードが用意されている。各テストの使用法については、「psping -? l」および「psping -? b」のヘルプを参照

　PsPingのTCP/UDPのレイテンシテストおよび帯域幅テストについては、今回は説明しません。今回は、TCP/UDPのレイテンシテストおよび帯域幅テストに使える、サーバモードのPsPingを応用して、TCPサーバアプリケーションに対する接続を許可するファイアウォールのルールをテストするツールとして利用してみます。

　なお、先に指摘しておきますが、UDPのレイテンシテストおよび帯域幅テストは、サーバモードのPsPingのTCPポートに接続した上で、サーバからの指示でUDPポートに対する送信（または「-r」によるサーバからの受信）の通信を行うため、TCPとUDPの両方の送受信許可が必要になります。

PsPingサーバモードの簡単な使用法

　PsPingはIPv4とIPv6の両方をサポートしていますが、IPv4アドレスの特定のポートで動作させるには、次のようなコマンドラインを実行します。

PsPing -4 -f -s ＜コンピュータ名＞:＜TCPポート番号＞

PsPing -f -s ＜IPv4アドレス＞:＜TCPポート番号＞

　「-f」オプションは、Windowsファイアウォールの「受信の規則」に指定したTCPポートへの接続を許可する規則「Sysinternals PsPing（TCP-In）」を自動生成するための指定です。［Ctrl］＋［C］キーでサーバモードを終了すると、「Sysinternals PsPing（TCP-In）」は自動削除されます。「-f」を省略する場合は、Windowsファイアウォールの「受信の規則」に必要な規則を自分で作成します。

　サーバモードのPsPingに接続するには、PsPingのレイテンシテスト（PsPing -l）や帯域幅テスト（PsPing -b）でもよいのですが、今回は接続性テストが目的なので、より簡単なTCP Pingで：<ポート>を指定します。

　以下の画面3は、ローカルネットワーク上でサーバモードのPsPing（画面右）に対して、クライアントのPsPing（画面左）から接続したところです。この例ではTCPポート番号「2736」に対する接続をテストしています。

画面3　ローカルネットワーク上でサーバモードのPsPing（画面右）に対して、クライアントのPsPing（画面左）から接続したところ

応用――PsPingでファイアウォールやNATの規則を事前にテスト

　PsPingのサーバモードとPsPingのTCP Pingについて簡単ですが説明しました。では、これらを応用して、ファイアウォールやNAT（Network Address Translation）の規則をテストしてみましょう。

　実は、前出の画面3は、Microsoft AzureのIaaSにデプロイした「Windows Server 2019」ベースのDockerコンテナホストです。このAzure上のDockerエンジンに対して、インターネットを介して手元のDockerクライアント（Docker for WindowsのDocker.exeやLinuxのDockerクライアント）と、TCPポート「2736」によるTLS接続を実現しようとしています。

　なお、一般的なDockerのTLSポートは「2376」です。現在、TCPポート「2376」で動いているDocker Engineはそのままにしておいて、受信NAT規則が期待通りに機能することをPsPingで確認した上で、Docker Engine側のTLSポートを「2376」から「2736」に切り替え、テスト済みの受信NAT規則を利用しようというのが筆者の考えです。

　DockerエンジンでTLS接続を有効化する事前段階として、Azure仮想ネットワークのプライベートアドレスのサブネットに接続された仮想マシンのTCPポート「2736」への接続性を確認しておくのです。

　ネットワーク構成は、フロントエンドにパブリックIPアドレスを持つロードバランサーを展開し、その「インバウンドNAT規則」としてTCPポート「62736」を、仮想マシンのTCPポート「2736」に転送するように構成しました。Windows Server 2019のWindowsファイアウォールの「受信の規則」では、TCPポート「2736」を許可しています（図1）。

図1　DockerエンジンでTLSを有効化する前に、PsPingでWindowsファイアウォールとNATの規則をテストしておく

　図1のネットワーク構成で、仮想マシン側でPsPingをサーバモード、TCPポート「2736」で実行し（「-f」オプションは指定せずに）、クライアントのPsPingのTCP PingでパブリックIPアドレスのTCPポート「62736」に接続してみます。期待通り、インターネットを介した接続は成功しました（画面4）。

画面4　NATのポート転送とホストのWindowsファイアウォールの規則が有効であることをPsPingで事前に確認できた

　続いて、DockerエンジンとDockerクライアントのTLS接続用証明書を準備して、DockerエンジンのTLSを有効化し、今度はDockerクライアントからAzure上のDockerエンジンに対して接続してみます（画面5）。

画面54　PsPingのサーバモードを本来のDockerエンジンに、PsPingのTCP Pingを本来のDockerクライアントの置き換え、TLS接続が可能であることをテストする

トラブル発生時の切り分けのヒントにも

　今回は、Dockerエンジンに対するリモートからのTLS接続を許可する前段階として、PsPingの機能を応用して先にNATやファイアウォールの規則をテストしました。

　最初からDockerエンジンでTLSを有効化して接続性に問題があった場合、その原因が途中の経路にあるのか、サーバやクライアントアプリケーションの設定にあるのか切り分ける必要があります。先に接続性をテストしておくことで、問題が発生した際に、アプリケーション設定の問題であると絞り込むことができ、解決時間を短縮できるでしょう。

　既に稼働中のサーバアプリケーションに対する接続性の問題を調査する場合でも、そのアプリケーションを停止して、PsPingのサーバモードに置き換えてテストすることで、純粋に接続性の問題だけを調査することができます。

筆者紹介

山市 良（やまいち りょう）

岩手県花巻市在住。Microsoft MVP：Cloud and Datacenter Management（2019-2020）。SIer、IT出版社、中堅企業のシステム管理者を経て、フリーのテクニカルライターに。Microsoft製品、テクノロジーを中心に、IT雑誌、Webサイトへの記事の寄稿、ドキュメント作成、事例取材などを手掛ける。個人ブログは『山市良のえぬなんとかわーるど』。近著は『ITプロフェッショナル向けWindowsトラブル解決 コマンド＆テクニック集』（日経BP社）。