＜Part＞

Part1

＜キャッチ→改行しない＞

基本コマンドとモニターツールでトラブル掌握

＜タイトル→改行しない＞

トラブルシュートツール紹介編

＜リード＞

＜本文→2段組＞

＜マーク＞

＜キャッチ＞

TCP/IPの設定情報を調べる

＜マーク的に大きく＞

ipconfig

　例えば、社内イントラネットのWebコンテンツを表示できないトラブルが発生したら、Webブラウザの設定で解決を図ることが多いだろう。しかし、それでも問題を解決できず、また、その原因もわからない場合、どのように対処すればよいだろうか。

　まずは、「ipconfig」コマンドで、TCP/IPの設定を確認することから始める。ipconfigは、WindowsのTCP/IP設定を確認するコマンドで、ネットワークトラブルが発生したら、最初に使用する。これは、自分のPCのTCP/IP設定がまちがっている可能性をあらかじめ排除しておくためだ（画面1）。ipconfigを実行して、通信できない原因がTCP/IP設定にあると判明したら、それを修正すればよい。「ipconfig /?」で使用可能なオプションを確認できる。これはOSにより異なる

　また、リモートネットワークとの通信に障害がある場合、デフォルトゲートウェイの設定も障害も可能性として考慮する必要がある。デフォルトゲートウェイの設定がされていなかったり、無効な設定値になっていると、そのPCが所属するネットワーク内部の通信しか出来ない。そのため、同じくipconfigでデフォルトゲートウェイのIPアドレスを確認しておく。さらに、ipconfigの「/all」オプションを使えば、DNS（Domain Name System）サーバのIPアドレスも表示できる。利用するDNSサーバのIPアドレスがまちがっていないかどうかも、ここで確認しておく。

　当然のことだが、自分のホストのIPアドレスが、ほかのホストのIPアドレスと重複していると通信できない。IPアドレスが重複していれば、たとえこちらからのパケットが目的のあて先に届いても、その返事（reply）が、同一のアドレスを持つどちらのホストに戻ればよいのか判断つかない。そのため、TCP/IPのネットワークでは、IPアドレスが重複すると、同一アドレスを持つホスト~~どうし~~同士だけではなく、ほかのホストとも通信できなくなる。ipconfigを実行して、既存のホストとIPアドレスが重複していないことを確認しよう。

　また、ほかのPCと通信できない原因として、DHCP（Dynamic Host Configuration Protocol）クライアントがIPアドレスを取得できないケースが考えられる。Windows2000以降では、この現象が発生すると、「APIPA（Automatic Private IP Addressing）」機能が働き、「169.254.x.x」というアドレスが表示されるはずだ（以前のWindowsは「0.0.0.0」）。ここで、DHCP~~サーバ~~クライアントにIPアドレスを付与させるには、「ipconfig /renew」を実行すればよい。なお、NIC（Network Interface Card）のドライバやPCの種類によっては、あらかじめ「ipconfig /release」を実行しないと、「ipconfig /renew」が実行できないこともある。このコマンドを実行しても、IPアドレスが取得できない場合は、NICやケーブルといったネットワーク機器媒体に不具合がないかを疑ってみよう。[HY1]

　TCP/IP設定のまちがいを修正し、ネットワーク機器媒体にも不具合が見当たらないのに、ターゲットPCとの通信が回復できなければ、ほかの原因を考えてみる必要がある。

＜マーク＞

＜キャッチ＞

＜中見出し＞

ping

　ローカルPCのTCP/IP設定に問題がないのにもかかわらず~~今度は、外部の~~まだWebサイトが閲覧できないケースで考えてみよう。このトラブルの原因としては、次のようなものが想定できる。[HY2]

①Webサーバが停止している

②プロキシを利用している場合、プロキシサーバが停止している

③ホスト名を使用して接続を試みている場合、DNSサーバが停止している

④ホスト名を使用して接続を試みている場合、DNSサーバにWebサーバの登録がない

⑤Webサーバ、プロキシサーバ、DNSサーバは稼働しているが、経路上のどこかで接続が途切れている

　では、想定できる5つの原因のうち、実際にはどこで障害が発生しているのだろうか。障害個所を探るのために使用するのが、リモートホストとの通信時状況を確認する「ping」コマンドである（画面2）。pingは、次のStepを踏んで実行すればよい。

「ping /?」で使用可能なオプションを確認できる。これもOSによりが異なる

＜マーク的に＞

Step1

＜ゴチ＞

ping 127.0.0.1

　まずは、PCのTCP/IPコンポーネントが正しく構成されているかどうかを確認する。TCP/IPのコンポーネントが異常だと、ここで応答が得られない。対策法としては、TCP/IPプロトコルを再インストールする必要がある。OSによってはTCP/IPの再インストールはOSの再インストールを意味するものもある。[HY3] なお、IPアドレス「127.0.0.1」は、ネットワークカードなどのループバックインタフェースに割り当てられた自分自身を表すループバックアドレスで、「ping localhost」を実行しても、同じ応答を得ることができる。

＜マーク的に＞

Step2

＜ゴチ＞

ping 192.168.0.11（自分のIPアドレス）

　Step1で、ループバックアドレスへのpingが成功すれば、次に、ipconfigで調べた自分自身のIPアドレスにpingを実行する。ここで応答が得られない場合、NICの実装に失敗している可能性がある。対策としては、NICのドライバを再インストールするか、NICを交換する必要がある。

＜マーク的に＞

Step3

＜ゴチ＞

ping 192.168.0.250

（デフォルトゲートウェイのIPアドレス）

　リモートネットワークとの通信障害を確認するには、デフォルトゲートウェイのIPアドレスでpingを実行する。このpingに失敗する場合は、デフォルトゲートウェイに原因があると推測できる。しかし、pingでは、デフォルトゲートウェイが停止しているのか、インタフェースがダウンしているのか、切り分けられない。さらに、リモートネットワーク側のインタフェースがダウンしていても、デフォルトゲートウェイからのreplyはある。そのため、応答がある場合でも、「デフォルトゲートウェイは正常に稼働している」と判定してはいけない。これは次のStep4で確認する。なお、実際には、デフォルトゲートウェイがローカルホストと異なるスイッチやハブに接続されていることを考慮して、pingを実行する。

＜マーク的に＞

Step4

＜ゴチ＞

ping 192.168.2.2

（リモートホストのIPアドレス）

　通信したいあて先のIPアドレスを指定してpingを実行する。これで応答が得られない場合、リモートホストもしくはリモートホストまでの経路に障害が発生している可能性が高い。[HY4] もちろん、リモートホストに指定しているIPアドレスがまちがっていないことが前提である。

　また、リモートネットワークに所属する任意のホストにpingを実行すると、そのネットワークまでのルーティングが成功しているかどうかを判定できるので、リモートホストに障害が発生しているのか、経路上に障害発生かが切り分けできる。応答がない場合、リモートネットワークまでの経路上、どこまで通信が届いているかを確認する（5の「tracert」コマンド参照）。pingでもtracertでも、「Destination host unreachable」というメッセージが表示されるときは、その直前のルータが持つルーティング情報と、あて先に近い側のインタフェースを確認する（画面3、画面4　図1　図2）。

192.168.2.250と192.168.2.2の経路に障害がある場合のpingとtracertの表示

「192.168.2.250」の経路情報に障害がある場合のpingとtracertの表示

192.168.2.250と192.168.2.2の経路に障害がある場合

「192.168.2.250」の経路情報に障害がある場合~~なお、CISCO CATALYSTなどのように、~~IP~~アドレスを持つネットワーク機器の場合、その~~IP~~アドレスがローカルホストと同じネットワークに所属しているなら、スイッチに対してもpingを実行できる。~~[HY5]

＜マーク的に＞

Step5

＜ゴチ＞

ping <hostname>

（リモートホストのコンピュータ名またはホスト名）

　次に、IPアドレスではなくコンピュータ名やホスト名でpingを実行する。応答があれば、名前解決が成功していると判断できる。もしも名前解決に障害がある場合は、DNSサーバに対して、これまでのpingによる障害調査のステップを実行しみてる。名前解決も、プロキシサーバとの通信にも問題がなく状態で、Webがブラウズできない場合は、Webサーバのアプリケーションの動作を確認する。これはpingでは判定できない。これは、「管理ツール」から「コンピュータの管理」を開くと、リモートでサービスの起動を確認できる。[HY6]

＜マーク＞

＜キャッチ＞

＜中見出し＞

tracert

　あて先ホストまでの経路を調査するためのコマンドである（画面5）。通過するネットワークルータまでのpingを3回行っているのとほぼ同様の動作をする。使用している「ICMP（Internet Control Message Protocol）」というプロトコルも、pingと同じだ。経路上のルータが正確なルーティング情報を持ち、正常な動作をしていれば、replyが返るのでかかった時間が表示できる。replyが返らない表示はそのルータが障害原因とほぼ考えられる。しかしセキュリティ上の理由でICMPをreplyしない設定のホストも存在する。その場合、障害と同じ表示になる。Replyがないからといって障害とは限らない場合もある。

「tracert -?」で使用可能なオプションを確認できる~~つまり、どのルータまで通信できているのかを確認する。通信できない最初のルータのこちら側に対する経路情報に誤りがあってもreplyは返らない。返す経路がわからないからだ。~~

＜マーク＞

＜キャッチ＞

＜中見出し＞

route

　TCP/IPホストのroute情報を表示・設定するコマンドである。"route /?"とすることで使用方法が表示できる。<画面6>経路情報は"route print"で表示する。<画面7>経路情報のみならば"netstat -r"でも同じ内容を確認できる。

「route -?」で使用可能なオプションを確認できる

「route print」でWindowsPCの持つ経路情報が表示できる。0.0.0.0のネットワークへのゲートウェイとなっているホストをデフォルトゲートウェイという。

全てのTCP/IPホストはルーターとして構成しなくてもルーティングテーブルを持っている。このホストは

0.0.0.0/0のネットワークへは192.168.0.250のホストを経由する、

という経路情報を持っている。この0.0.0.0/0で表されるネットワークは「世の中すべてのネットワークアドレス」である。このエントリが意味する内容は、リモートネットワークへは、全て192.168.0.250をゲートウェイとする、ということとなる。PC1から見て、この192.168.0.250のホストを「デフォルトゲートウェイ」という。<図3>

「192.168.0.250」はPC1にとってデフォルトゲートウェイである。

"add"オプションを使用すると経路情報をルーティングテーブルに追加できる。図3のネットワークでPC1に対してPC3のいる192.168.200.0/24のネットワークへ192.168.0.3のホストを経由する経路を設定するには、次のようにコマンドを入力する。

route add 192.168.200.0 mask 255.255.255.0 192.168.0.3<画面08-2>

「route add 192.168.200.0 mask 255.255.255.0 192.168.0」で192.168.200.0/24への経路情報を追加する。

同様にPC3の方でも

① 192.168.0.0/24のネットワークへは192.168.200.3のホストを経由するという情報

か、あるいは、

　　②　192.168.200.3をデフォルトゲートウェイとして「全てのリモートネットワークへの出入り口に192.168.200.3を利用する。」

という設定になっていなければ、PC1とPC3は通信できない。こちらのパケットが相手に届いていたとしても相手が返答先をわかっていなければ通信は出来ないからだ。

PC1のルーティングテーブルのように明示的に任意のリモートネットワークへの経路情報を設定した場合、この経路はデフォルトゲートウェイより優先して機能する。デフォルトゲートウェイには、route コマンドなどで明示的に経路情報を追加したものを除くすべてのリモートネットワーク宛てのトラフィックが集中する。PC3のように自分が所属するネットワークから他のネットワークへの出入り口がデフォルトゲートウェイ一箇所に限られるときには、任意の経路情報をroute コマンドで追加する必要は無い。すべてはデフォルトゲートウェイに任せられる。

ルーティングテーブルに他のネットワークへの経路情報が記載されていないと、ネットワークアドレスが同じホストのみの通信に限られる。

Windows PCに複数インターフェースを実装するとそのインターフェースの属しているネットワーク分の経路情報を自動追加する。このPCでroutingをenableにすると「ルーター」になる。「ルーター」として構成するには管理ツールの「ルーティングとリモートアクセス」を利用する。<画面09>

Windows PCに複数インターフェースを実装するとそのインターフェースの属しているネットワーク分の経路情報を自動追加する。192.168.0.0と192.168.1.0と見て取れる。

ルーターが一方のネットワークから受け取ったパケットを、どこのネットワークに転送するのか、という判断はルーターの持つルーティングテーブルによって決まる。ルーティングの基本はネットワークアドレスが異なるネットワークへパケットを転送することである。同じネットワーク内でのパケットの転送はスイッチングという。

32bitOSのWindows PCはルーターとして構成可能である。先に述べたように複数のNICを実装するなり、あるいは１つのNICにネットワークアドレスが異なる複数のIPアドレスを設定し、それぞれのインターフェース間でルーティングを有効にすればよい。以上のことを理解していないと、次のようなネットワークを構成してしまうことがある。<図4>

SRV1の両側が同じネットワークアドレスなのでPC1とPC2は通信できない。

SRV1がNICを２枚実装していてそれぞれ

192.168.0.250/24

192.168.0.251/24

というというアドレスが設定してある。接続してあるネットワーク上に重複するIPアドレスが存在しなければ、また、それぞれのNICに重複しないIPアドレスを設定するのならば、このような構成も可能である。しかし、SRV1でルーティングを有効にしても、PC1とPC2は通信できない。物理的に別なネットワークセグメントとして構成してあるのにもかかわらず、PC1とPC2それぞれが所属するネットワークアドレスが同一なため、ルーティングの対象にならないからである。

（PC1）

route add 192.168.0.253 mask 255.255.255.255 192.168.0.250

（PC2）

route add 192.168.0.11 mask 255.255.255.255 192.168.0.251

というコマンドを実行しても駄目である。しかし、PC1はSRV1と通信は可能だ。PC2もSRV1と通信は可能だ。

<図5>のように構成すれば、PC1とPC2は通信可能だ。このときSRV1のホストアドレスは192.168.1.251でもかまわないが、複数のネットワークに所属しているルーターの場合、ホストアドレス部分に同じ値を使用すると記憶間違いが少なくなり管理が楽になる。[HY7]

SRV1の両端が別なネットワークアドレスなのでPC1とPC2は通信できる。

＜マーク＞

＜キャッチ＞

＜中見出し＞

nslookup

　「nslookup」コマンドは、DNSサーバに登録されているデータベースの内容を確認するときに利用する。使用方法を確認しようとして、このように"/?"というホスト名をクエリーしている。<画面10>~~のように~~nslookupを起動してから"?"を入力すると使用方法が表示できる。<画面11>

Helpどおりに"nslookup /?"としても"/?"をクエリしてしまう。これってバグじゃなかろうか?

"nslookup"を起動して"/?"を入力すると使用可能なオプションを確認できる。

あくまでもDNSサーバの持つゾーンファイルの情報を表示するだけなので、ここで任意のホストのエントリを確認できても、ローカルホストがその情報を利用できるわけではない。このDNSサーバに名前解決クエリーが届いていなければ回答はない。ローカルホストが名前解決で利用するDNSサーバーのIPアドレスはipconfig /allで確認する。設定は「ネットワーク」のプロパティから行う。DNSサーバーに対してpingが届けばnslookupでDNSサーバーと通信できる。Nslookupはデフォルトでipconfig /allで確認したDNSサーバーにクエリを投げる。

DNSサーバには自分が解決できないクエリーをほかのDNSサーバで解決する。その結果を一定時間キャッシュとして保持する。保持している間はあたかも自分が持っている情報のごとく名前解決に使用する。この情報はnslookupのクエリーでも表示・確認可能だ。<画面12>

"wwww.idg.co.jp"のipアドレスをクエリする。

＜マーク＞

＜キャッチ＞

＜中見出し＞

ネットワークモニタ

　サーバ製品に標準で添付するのネットワークアナライザー。<画面13>SMSに付属のバージョンは「ルータの検索」機能や「名前からアドレス解決する」機能などがあり、サーバ添付の通常バージョンより高機能になっている。このSMS版はクライアント製品にもインストールできる。このネットワークモニタを利用するとネットワーク上のトラフィックをキャプチャして解析ができる。<画面14>フィルタ機能を利用すると任意のプロトコルのトラフィックだけを表示するといったことも可能だ。

キャプチャ中の"ネットワークモニタ"の様子。「ルータの検索」機能や「名前からアドレス解決する」機能はSMS版のみ利用可能だ。

キャプチャしたトラフィックを解析する。ICMPのみを表示するようフィルタリングした。

　最近は無償のツールであるEtherealが有名だ。ほとんどNetwork monitor と同様の表示が可能となっている。見かけもNetwork monitorそっくりだ。<画面15>しかもNetwork monitorでキャプチャしたファイルをEtherealでも読込み表示が可能である。Windowsネットワークの管理者はこの2つのネットワーワークアナライザーを用意しておけば、どちらかのツールでしか計測・表示できないトラフィックもカバーできる。

最近はやりの無償ネットワークアナライザー"Ethereal"。見かけも"ネットワークモニタ"そっくりだ。

＜コラム＞

書式が統一されていない

Windowsのコマンド

　同じ名称のコマンドにもかかわらず、~~マイクロソフトの~~OSと~~UNIX互換の~~OSではそのコマンドを収録しているOSやリリース時期が異なると、実行結果やプログラムの動作、オプションに相違があるものだ。[HY8] しかし、UNIX互換OSに比べてマイクロソフトのOSではとてもばらつきが多い。例えば、オプション（引数）の記号と記述方法~~についても~~は、UNIX互換OSでは"-"は"--"のように2個続けるときもあるが"/"を用いるものはない。またコマンドと引数の間はスペースで区切る。ところがマイクロソフトのOSは、オプション（引数）記号は"-"のものもあれば"/"のものもある。両方可能なコマンドもあればどちらか一方しか使用できないコマンドも存在する。さらにコマンドと引数の間はスペースで区切るコマンドもあれば、スペースで区切らずにつなげて入力しても動作するコマンドがある。Windows2000以降の最近のOSでは、スペースで区切らなくても使用可能なものが多いようだ。マイクロソフトの昔のOSも操作する可能性のある管理者は、最近のOSのつもりでスペースで区切らずに入力して「実行できない」と悩む前に、スペースを入れる書き方を心がけたい。オプション記号についてはマイクロソフトのプログラマーに書式統一を心がけるように望むとここに書いておくことぐらいしか対策がない。