5.3基本診断コマンドと結果解釈

つながらないという訴えに対し、最初に手を動かして事実を集めるのが基本診断コマンドです。どのOSにも用意された ping・ipconfig/ifconfig/ip・tracert/traceroute・nslookup は、それぞれ違う層・違う観点を確かめます。大切なのは、コマンドを打てることそのものより、結果をどう読むかです。特にファイアウォールが特定の通信を遮断していると、コマンドは「失敗」と表示するのに実際には到達できているという食い違いが起こり得ます。この節では、各コマンドの使い分けと、こうした結果の落とし穴を含む正しい解釈を学びます。

5.3.1定番コマンドの使い分け

• ping＝相手へのL3の到達性をICMPで確かめる。応答が返れば往復時間（RTT）も分かる。まず「そもそも届くのか」を見る最初の一手。ping 8.8.8.8 のようにIPで打てば名前解決の影響を切り離せる。
• ipconfig（Windows）/ifconfig・ip（Linux/mac）＝自機のIP設定（IPアドレス・サブネットマスク・デフォルトゲートウェイ等）を確認する。「そもそも正しいIPを持っているか」「ゲートウェイは設定されているか」を最初に確かめる。
• tracert（Windows）/traceroute（Linux/mac）＝宛先までの経路（ホップ）を1つずつたどる。どのルータまで届いてどこで止まるかが見えるので、「途中のどこで切れているか」を絞れる。nslookup＝ホスト名からIPへの名前解決（DNS）が正しく引けるかを確かめる。

5.3.2結果の解釈とファイアウォールの影響

• ファイアウォールがICMPを遮断していると、相手が正常に動いていてもpingはタイムアウト（失敗）する。つまり「ping不通＝必ず停止」ではない。Webサーバが443では応答するのにpingだけ返らない、というのは典型例。
• IPでは行けるが名前では行けない症状（ping 8.8.8.8 は通るが ping example.com は失敗）は、到達性ではなく名前解決（DNS）の問題を示す。ここで nslookup を使えば、DNSが引けているか切り分けられる。
• tracert/traceroute も途中のルータがICMPを返さない設定だと、そのホップだけ *（無応答）になることがあるが、それは必ずしも障害ではない。コマンドの「失敗表示」を額面どおり受け取らず、他の手段と合わせて判断するのが結果解釈の要。

ユーザーから「社内の新しいWebサーバにアクセスできない」と連絡が来ました。あなたはまずそのサーバへ ping を打ちますが、応答がなくタイムアウトします。ここで「pingが通らないのだからサーバはダウンしている」と結論づけるのは、結果解釈の典型的な誤りです。多くのサーバやファイアウォールは、セキュリティ上の理由でICMP（pingが使うプロトコル）への応答をあえて遮断しているからです。そこで次に、実際のサービスであるHTTPS（TCP443）でアクセスできるかをブラウザや別の手段で確かめると、Webページはちゃんと開ける——つまりサーバは動いており、ping が失敗していたのはファイアウォールがICMPを止めていたためだった、と分かります。別のケースも見てみましょう。ユーザーが「ping 8.8.8.8 は通るのに ping 社内サーバ名 は失敗する」と言うなら、到達性そのものは生きていて、ホスト名からIPへの変換＝名前解決（DNS）が怪しいと当たりが付きます。ここで nslookup 社内サーバ名 を実行し、正しいIPが返るかを確かめれば、DNS設定の問題かどうかを切り分けられます。さらに「途中までは行くが特定の拠点から先で切れる」なら tracert/traceroute でどのホップで止まるかを見ます。ここで一貫して大切なのは、コマンドの「失敗」を鵜呑みにせず、なぜその結果になったのかを別の手段で裏取りすることです。ping 一つの結果に飛びつかず、ipconfig で自機の設定、nslookup で名前解決、tracert で経路と、観点の違うコマンドを組み合わせて事実を積み上げるのが、入門段階でも身につけたい診断の作法です。

5.3.3この節のまとめ

• ping＝ICMPで到達性、ipconfig/ifconfig/ip＝自機のIP設定、tracert/traceroute＝経路、nslookup＝DNS名前解決と観点が違う
• ファイアウォールがICMPを遮断するとping失敗でも到達可能なことがある。失敗表示を額面どおり受け取らない
• IPで行けるが名前で行けないのは名前解決（DNS）の問題。観点の違うコマンドを組み合わせて事実を積み上げる