0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@tanununsan

pingだけで終わらせないWindows疎通確認メモ

0
Posted at

pingだけで終わらせないWindows疎通確認メモ

はじめに

ネットワークやサーバの問い合わせ対応で、よく使う確認コマンドに ping があります。

たとえば、

  • サーバに通信できない
  • Web画面が開けない
  • ファイルサーバにアクセスできない
  • プリンターに印刷できない
  • 名前ではつながらない
  • IPアドレスではつながる
  • インターネットに出られない

といったとき、まず ping を実行することは多いと思います。

ただし、ping が通ることと、目的の通信ができることは同じではありません。

この記事では、Windows標準コマンドを使って、ping だけで終わらせずに、名前解決、Internet疎通、TCPポート疎通まで段階的に確認する方法を整理します。

よくある問い合わせ申告の主訴「Pingが通らない」に対して、「実際に何が通信できないの？」を確認するための手段としても、一考いただけると幸いです。

想定する用途

この記事では、以下のような場面を想定しています。

  • Windows端末からの疎通確認
  • サーバやネットワーク機器への一次切り分け
  • 問い合わせ対応時の初動確認
  • 名前解決とIP疎通を分けて確認したい場合
  • HTTP / HTTPSなどのポート疎通を確認したい場合
  • 複数宛先へ連続してpingしたい場合
  • Internet通信の切り分けをしたい場合

まず考えること

「通信できない」と言われたとき、確認したいことはいくつかに分かれます。

確認したいこと 例
自端末のIP設定は正しいか ipconfig /all
IPアドレスへ到達できるか ping 192.168.1.1
名前解決できるか nslookup server01
名前解決したIPが正しいか ping server01 の解決先を見る
TCPポートが開いているか Test-NetConnection
HTTP / HTTPSのポートへ接続できるか 80 / 443 の確認
経路の途中で止まっていないか tracert

ping は便利ですが、確認できるのは主にICMPの疎通です。

そのため、

pingが通る = アプリケーション通信もできる

とは限りません。

pingの基本

IPアドレスに対して疎通確認する基本形です。

ping 192.168.1.1

ホスト名に対して確認する場合は以下です。

ping server01

ホスト名で ping すると、名前解決されたIPアドレスも表示されます。

Pinging server01.example.local [192.168.1.10] with 32 bytes of data:

この表示を見ることで、

  • 名前解決できているか
  • どのIPアドレスに解決されているか
  • 応答があるか

を確認できます。

ping -t：継続して確認する

継続的にpingを実行したい場合は、-t を使います。

ping -t 192.168.1.1

これは、通信断や瞬断を見たいときに便利です。

停止する場合は、Ctrl + C を押します。

用途例です。

  • 機器再起動中の疎通復旧確認
  • LANケーブル差し替え時の疎通確認
  • VPN接続後の到達確認
  • 瞬断の有無確認

ping -n：回数を指定する

回数を指定する場合は、-n を使います。

ping -n 10 192.168.1.1

この例では、10回pingを実行します。

タスクやログ取得で、無限に実行したくない場合に使いやすいです。

ping -l：サイズを指定する

送信するデータサイズを指定する場合は、-l を使います。

ping -l 1472 192.168.1.1

MTUやフラグメント周りの確認で使うことがあります。

ただし、環境によってICMPの扱いが異なるため、結果の解釈には注意が必要です。

ping -w：タイムアウトを指定する

応答待ち時間を指定する場合は、-w を使います。

ping -w 1000 192.168.1.1

この例では、タイムアウトを1000ミリ秒にしています。

応答が遅い環境や、待ち時間を短くしたい確認で使います。

単発で高速にping確認する

疎通確認では、まず1回だけ素早く確認したい場面があります。

その場合は、以下のようにします。

ping -n 1 -w 1000 -4 8.8.8.8

各オプションの意味は以下です。

オプション 内容
-n 1 pingを1回だけ実行する
-w 1000 タイムアウトを1000ミリ秒にする
-4 IPv4で確認する
8.8.8.8 確認先IPアドレス

このコマンドは、インターネット向けにIPv4疎通があるかを素早く確認したいときに使えます。

ただし、8.8.8.8 へpingが通らないからといって、必ずしもインターネット接続全体ができないとは限りません。
環境によっては、ICMPが制限されている場合があります。

そのため、pingの結果はあくまで一次確認として扱います。

複数宛先へpingするbat

複数の宛先へまとめてpingしたい場合、batにしておくと便利です。

@echo off

rem ==========================================
rem 複数宛先 ping確認bat
rem ==========================================

set LOGFILE=%USERPROFILE%\Desktop\pingcheck_%date:~0,4%%date:~5,2%%date:~8,2%.log

echo ===== ping check start ===== > "%LOGFILE%"
echo date %date% >> "%LOGFILE%"
echo time %time% >> "%LOGFILE%"
echo. >> "%LOGFILE%"

for %%A in (
    192.168.1.1
    192.168.1.10
    server01
    fileserver01
    printserver01
    8.8.8.8
    google.com
    ntp.nict.jp
) do (
    echo ===== %%A ===== >> "%LOGFILE%"
    ping -n 2 -w 1000 %%A >> "%LOGFILE%"
    echo. >> "%LOGFILE%"
)

echo ===== ping check end ===== >> "%LOGFILE%"
echo date %date% >> "%LOGFILE%"
echo time %time% >> "%LOGFILE%"

notepad "%LOGFILE%"

このようにしておくと、複数機器への疎通確認結果をまとめてテキストに残せます。

問い合わせ対応や現地作業の初動確認で使いやすいです。

もちろん、ExPingなどのフリーソフトを利用するのも手です。

宛先一覧をテキストファイルに分ける

確認対象が増える場合は、宛先一覧を別ファイルに分けると管理しやすくなります。

たとえば、targets.txt を用意します。

192.168.1.1
192.168.1.10
server01
fileserver01
printserver01
8.8.8.8
google.com
ntp.nict.jp

bat側では、以下のように読み込みます。

@echo off

set LOGFILE=%USERPROFILE%\Desktop\pingcheck.log
set TARGETFILE=%~dp0targets.txt

echo ===== ping check start ===== > "%LOGFILE%"
echo date %date% >> "%LOGFILE%"
echo time %time% >> "%LOGFILE%"
echo. >> "%LOGFILE%"

for /f %%A in (%TARGETFILE%) do (
    echo ===== %%A ===== >> "%LOGFILE%"
    ping -n 4 %%A >> "%LOGFILE%"
    echo. >> "%LOGFILE%"
)

echo ===== ping check end ===== >> "%LOGFILE%"

notepad "%LOGFILE%"

この形にすると、確認対象の追加・削除は targets.txt を編集するだけで済みます。

名前解決を確認する

ホスト名で通信できない場合、IP疎通の前に名前解決で詰まっていることがあります。

名前解決を確認する代表的なコマンドは nslookup です。

nslookup server01

確認したいことは以下です。

  • DNSサーバへ問い合わせできているか
  • 対象名が解決できるか
  • 解決されたIPアドレスが正しいか
  • 想定外のDNSサーバを見ていないか

ping server01 が失敗しても、原因がネットワーク疎通ではなく名前解決の場合があります。

Resolve-DnsNameを使う

PowerShellが使える場合は、Resolve-DnsName も便利です。

Resolve-DnsName server01

DNSレコードの種類を指定したい場合は、以下のようにします。

Resolve-DnsName server01 -Type A

名前解決の確認では、ping の結果だけでなく、DNSとしてどう解決されているかを見ることが大切です。

インターネット通信を段階的に確認する

インターネットに出られない、Webサイトが開けない、といった問い合わせでは、確認対象を分けると整理しやすくなります。

たとえば、以下のように確認します。

1. 外部IPアドレスへ到達できるか
2. 外部FQDNの名前解決ができるか
3. Web向けのTCPポートへ接続できるか
4. NTPなど、必要な外部サービスへ到達できるか

外部IPアドレスへの疎通確認

まず、外部IPアドレスへ疎通できるか確認します。

ping -n 1 -w 1000 -4 8.8.8.8

これは、DNS名前解決を使わずに外部IPアドレスへ確認するためのものです。

この確認で応答があれば、少なくとも端末から外部IPアドレスへICMP通信できている可能性があります。

ただし、ICMPが遮断されている環境もあるため、これだけで判断しないようにします。

外部FQDNの名前解決確認

次に、FQDNの名前解決を確認します。

nslookup google.com

PowerShellを使う場合は、以下でも確認できます。

Resolve-DnsName google.com

ここで確認したいのは、単に名前解決できるかだけではありません。

  • どのDNSサーバへ問い合わせているか
  • google.com がIPアドレスへ解決されるか
  • 想定外のDNSサーバを参照していないか

を確認します。

FQDN宛てのping確認

名前解決を含めて確認したい場合は、FQDNに対してpingします。

ping -n 1 -w 1000 -4 google.com

この確認では、

  • google.com を名前解決できるか
  • 解決されたIPアドレスへICMP応答があるか

をまとめて見られます。

ただし、これもICMPの確認であり、Webサイトが正常に開けることを保証するものではありません。

HTTP / HTTPSポートの確認

Web通信を確認したい場合は、HTTP / HTTPSのTCPポートを確認します。

Test-NetConnection google.com -Port 80
Test-NetConnection google.com -Port 443

結果の TcpTestSucceeded が True であれば、TCPレベルでは対象ポートへ接続できています。

TcpTestSucceeded : True

ただし、TCPポートに接続できることと、Webページが正常表示されることは別です。

プロキシ、証明書、HTTPレスポンス、アプリケーション側のエラーなどは別途確認が必要です。

NTPサーバへの確認

時刻同期の確認先として、NTPサーバ名を確認したい場合があります。

例として、NICTのNTPサーバ名を確認します。

nslookup ntp.nict.jp

名前解決を含めて確認する場合は、以下のようにpingします。

ping -n 1 -w 1000 -4 ntp.nict.jp

ただし、NTP自体は通常UDP/123を使用します。
pingが通ることは、NTP同期ができることを直接保証するものではありません。

NTPの確認では、Windowsであれば以下のようなコマンドも確認対象になります。

w32tm /query /status
w32tm /query /peers

外部の名前解決、外部IPへの疎通、Webポート確認、NTP設定確認を分けると、インターネット通信のどこで詰まっているか整理しやすくなります。

TCPポート疎通を確認する

ping が通っても、目的のポートが開いているとは限りません。

Windows PowerShellでは、Test-NetConnection を使ってTCPポートの疎通を確認できます。

Test-NetConnection server01 -Port 3389

RDPの3389番ポートを確認する例です。

HTTPの80番ポートを確認する場合は以下です。

Test-NetConnection webserver01 -Port 80

HTTPSの443番ポートを確認する場合は以下です。

Test-NetConnection webserver01 -Port 443

結果の TcpTestSucceeded が True であれば、TCP接続に成功しています。

TcpTestSucceeded : True

Well-knownポートとして確認する

Test-NetConnection で確認するポートは、目的の通信に合わせて指定します。

代表的なサービスで使われる番号は、Well-knownポートとして知られています。

用途 プロトコル 代表的なポート
HTTP TCP 80
HTTPS TCP 443
DNS TCP/UDP 53
SMTP TCP 25
NTP UDP 123
SMB TCP 445
RDP TCP 3389
WinRM HTTP TCP 5985
WinRM HTTPS TCP 5986

たとえば、WebサーバのHTTPS到達性を確認したい場合は、443番ポートを確認します。

Test-NetConnection webserver01 -Port 443

ファイルサーバのSMB通信を確認したい場合は、445番ポートを確認します。

Test-NetConnection fileserver01 -Port 445

RDP接続を確認したい場合は、3389番ポートを確認します。

Test-NetConnection server01 -Port 3389

ただし、Well-knownポートはあくまで代表的な番号です。

実際の環境では、サービス側で別ポートを使っている場合もあります。
たとえば、単一のサーバがFTPサイト、監視用Webサイト、ソフト管理用Webサイトの3サイトを、ポートでわけて使っていることがあります。
そのため、確認するときは「このサービスは何番ポートで待ち受けているのか」を確認してから実行します。

また、NTPは代表的にはUDP/123を使います。
Test-NetConnection は主にTCP接続確認で使うため、NTPのようなUDPサービス確認では、別の確認方法も検討します。

HTTP / HTTPS確認で見ること

Web画面が開けない場合、いきなりブラウザだけで判断するより、段階的に分けると確認しやすいです。

たとえば、以下のように分けます。

1. 名前解決できるか
2. IPアドレスへ到達できるか
3. TCP 80 / 443 が開いているか
4. ブラウザでHTTP応答が返るか
5. ログイン画面やアプリ画面が正常か

Test-NetConnection で80や443が通っても、Webアプリケーションが正常とは限りません。

TCPポート疎通とHTTPレスポンス、アプリケーションの正常性は分けて考えます。

tracertで経路を確認する

経路の途中で止まっていそうな場合は、tracert を使います。

tracert 192.168.1.1

ホスト名でも確認できます。

tracert server01

ただし、途中経路でICMP応答が制限されている場合、必ずしも全経路が見えるとは限りません。

tracert の結果も、環境に応じて解釈します。

pingが通らないときに考えること

ping が通らない場合でも、原因はいくつかあります。

  • 宛先が停止している
  • IPアドレスが違う
  • 経路がない
  • FWでICMPが止められている
  • VLANやセグメントが違う
  • デフォルトゲートウェイが違う
  • 名前解決が違うIPを返している
  • 端末側のネットワーク設定が誤っている
  • 宛先となる端末のデフォルトルートが、誤って設定されている

つまり、ping が通らないという結果だけでは、原因を確定することができません。

pingが通るのに通信できないときに考えること

逆に、ping が通るのに目的の通信ができないこともあります。

たとえば、

  • Webポートが閉じている
  • サービスが停止している
  • FWでTCPポートが止められている
  • 認証で失敗している
  • アプリケーション側でエラーになっている
  • プロキシ設定が必要
  • SMBやRDPなど目的のポートだけ遮断されている

この場合、ping だけでは不足します。

Test-NetConnection やアプリケーションログ、サーバ側サービス状態なども確認します。

切り分けの流れ

問い合わせ対応では、以下のように段階を分けると整理しやすいです。

1. 自端末のIP設定を確認する
   ipconfig /all

2. 名前解決を確認する
   nslookup server01
   Resolve-DnsName server01

3. IP疎通を確認する
   ping 192.168.1.10

4. ホスト名で疎通確認する
   ping server01

5. Internet向け疎通を確認する
   ping -n 1 -w 1000 -4 8.8.8.8
   nslookup google.com
   ping -n 1 -w 1000 -4 google.com

6. 目的ポートを確認する
   Test-NetConnection server01 -Port 445
   Test-NetConnection server01 -Port 3389
   Test-NetConnection webserver01 -Port 443
   Test-NetConnection google.com -Port 443

7. 必要に応じてNTP状態を確認する
   nslookup ntp.nict.jp
   ping -n 1 -w 1000 -4 ntp.nict.jp
   w32tm /query /status
   w32tm /query /peers

8. 必要に応じて経路を確認する
   tracert server01

このように分けると、

  • 名前解決の問題
  • IP疎通の問題
  • Internet出口の問題
  • ポート疎通の問題
  • アプリケーション側の問題
  • 時刻同期の問題

を切り分けやすくなります。

このメモでできること

この記事の内容を使うと、以下のような確認ができます。

  • pingでIP疎通を確認する
  • pingオプションを使い分ける
  • 単発高速pingで外部IP疎通を確認する
  • 複数宛先へのping結果をログ化する
  • 名前解決を確認する
  • Internet通信を段階的に確認する
  • TCPポート疎通を確認する
  • Well-knownポートを意識して確認する
  • HTTP / HTTPSの確認観点を分ける
  • NTP確認の入口を整理する
  • 「pingが通る/通らない」だけで判断しない

注意点

pingはICMPの確認

ping は主にICMPの疎通確認です。

ICMPが許可されていない環境では、宛先が正常でもping応答が返らないことがあります。

pingが通ることとサービス利用可否は別

pingが通っても、RDP、SMB、HTTP、HTTPSなどの目的の通信ができるとは限りません。

目的のサービスに応じたポート確認が必要です。

名前解決と疎通は分けて考える

ホスト名で接続できない場合、名前解決が原因なのか、通信経路が原因なのかを分けて確認します。

nslookup や Resolve-DnsName を併用すると整理しやすくなります。

Well-knownポートは代表値として扱う

Well-knownポートは代表的な番号です。

実際の環境では、サービス側で別ポートを使っている場合があります。

確認時は、対象サービスが実際にどのポートで待ち受けているかを確認します。

Test-NetConnectionの結果も万能ではない

Test-NetConnection でTCP接続に成功しても、アプリケーションログインやHTTPレスポンスの中身までは保証しません。

あくまでTCPレベルの確認として扱います。

NTPはUDPであることに注意する

NTPは代表的にはUDP/123を使用します。

ping や Test-NetConnection だけではNTP同期の正常性は判断できません。

Windows端末では、w32tm コマンドもあわせて確認します。

結果をログに残す

問い合わせ対応や現地作業では、確認結果をログに残しておくと後から説明しやすくなります。

bat化してテキストに残すと、作業証跡として扱いやすくなります。

まとめ

ping は疎通確認の基本ですが、ping だけで通信可否を判断するのは危険です。

通信できないと言われたときは、

  • 自端末のIP設定は正しいか
  • 名前解決できるか
  • IP疎通できるか
  • Internetへ出られるか
  • 目的ポートに接続できるか
  • アプリケーションとして応答しているか
  • 必要な外部サービスに到達できるか

を分けて確認することが大切です。

大事なのは、

pingが通るかどうか

だけではなく、

何の通信を、どの層で確認しているのか

を意識することだと思います。

pingは疎通確認の入口です。これだけでも出来ることはたくさんあります。
そこで終わらせず、名前解決やTCPポート疎通まで見ることで、問い合わせ対応や障害切り分けが少し整理しやすくなると思います。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?