LANから外に出られない！？：コマンドを使ってトラブルシューティング（1）（1/2 ページ）

[山本洋介，＠IT]

はじめにこの連載について

この連載では、100人くらいのユーザーのいる小規模ネットワークに起こるさまざまなトラブルを、ネットワークツールを用いて解決していきます。主人公は、社内の管理者兼プログラマーの律子さん。得意技はPingで、何かが起きると、すぐテンパってしまうきらいがあります。

　律子さんはあるシステム開発会社に勤めています。そこそこネットワークやOSに興味はあり、自分では詳しいと思っています。ただ実際は、自由に使いこなせるネットワークコマンドはPingくらいで、実はそれほど詳しくはありません。

　ある日のこと、インターネットの話を自慢げにしていたのを聞かれていたのか、突然、上司に会社のLAN管理者に抜てきされてしまいます。どうやら本当にネットワークに詳しいと勘違いされたようです。

　そこに降りかかる嫉妬とトラブルの数々。果たして律子さんはうまく切り抜けて立派な管理者になれるでしょうか。

LANから外に出られない!?

　律子さんの管理するLANはそれほど規模が大きいわけでもなく、面倒なサーバも稼働していなかったおかげか、しばらくはトラブルにも遭遇せずうまくやり過ごしていました。そこに突然部長がやって来ます。

　管理者としてトラブルもなく過ごしているからお褒めの言葉でも、もしかすると昼ご飯でもごちそうしていただけるのかもと律子さんは期待したのですが、顔を見る限りそうではないことは明らかで、どうやらトラブルのようです。

　「私のマシンがネットにつながんないのですけど、何とかしていただけるかしら」と部長。律子さんは 「どういうことですか？」と状況を聞き出そうと対応しますが、「理由が分かるくらいなら私が解決します！　管理者なんですから早く何とかしてください！ 急いでいるのですよ」とすごい剣幕でこれ以上質問できそうにありません。

　理由はよく分からない、といわれて律子さんも困ったのですが、部長のいうことに逆らえません。とにかく早くトラブルを解決することが一番です。

　まずは何も考えず自分のマシンから自社のWebにアクセスしてみました。これは何事もなくできました。次に自社のメールを受信してみます。これはできません。

　あれっ。メールサーバが落ちてるのかな？

　次に、ほかのWebを見てみると、これも見られません。あれっ？

　部長のマシンを借りて、アクセスしてみても、似たような現象が起こっています。

　Webサーバにアクセスできるのにメールサーバにアクセスできないなんておかしいなあ。いっそのこと全部アクセスできなきゃよいのにと不謹慎なことを考えていると、「まだ終わんないの？」と怒鳴り声が飛んできます。「もうすぐ何とかします！」と、返事だけは威勢良くしてみたものの、何がどうなっているのかちっとも分かりません。

　得意のPingを打ってみたものの、状況は変わるはずもなく、クビになった自分のことを想像してしまい胸がドキドキしてきました。

　ドキドキしてても仕方がないので、取りあえず検索でもしようかと思いPCの画面に向かいました。すると、突然、PCの画面にメッセージがポップアップしてきました。

　　　　　「tracertで経路の障害を調べることができますよ」

　そうか！　律子さんはtracert（参照記事：＠IT：traceroute - ネットワークの経路を調査する）というコマンドがあったのを思い出しました。（＊1）

　　　　　（＊1）Windowsではtracertですが、Linuxだとtracerouteです。

　早速コマンドプロンプトを立ち上げて、Webサーバとメールサーバに対し、tracertコマンドを実行してみました。使い方はPing（参照記事：＠IT：ping- ネットワークの疎通を確認する）と同じくコマンドの後に対象ホスト名です。　

Webサーバに向けてtracertコマンドを実行

C:\>tracert www.example.co.jp
Tracing route to www.example.co.jp[219.166.170.245]
over a maximum of 30 hops:
1 <1 ms <1 ms <1ms 192.168.0.1
2 1 ms 1 ms 1 ms www.example.co.jp [219.166.170.245]
Trace complete.

メールサーバに向けてtracertコマンドを実行

C:\>tracert mail.example.co.jp
Tracing route to mail.example.co.jp[220.111.37.180]
over a maximum of 30 hops:
1 <1 ms <1 ms <1 ms 192.168.0.1
2 * * * Request timed out.
3 * * * Request timed out.
4 * * * Request timed out.
（以下略）
Trace complete.

　確かにメールサーバまでの経路には障害があるようだけど……、　どうすればいいのでしょう。途方に暮れて涙が出てきてしまいます。涙がこぼれないように天井を見ると、紙が貼ってあります。

　　　　　「社内のネットワークを把握してますか」

　あ！　そういえば私の管理してるLANってどうなってるんだろう。律子さんは慌てて渡されていた社内のネットワーク図を取り出して見てみました。Webサーバは社内にありました。DNSサーバも社内にあったので、名前解決はできていたのでした。

　ああ、WebサーバがグローバルIPアドレスを持っているからといって勘違いしてしまうなんて、なんて間抜けなんでしょう。tracertコマンドでもルータの次のホップなのに。律子さんは自分の注意力のなさに悲しくなってしまいましたが、だんだんと社内から自分に向けられる視線が厳しくなっているのに気付いたので解決を急ぐことにします。悲しんでいる場合ではありません。

図1：律子さんの勤務先のネットワーク構成図

　律子さんはトラブルの原因を考えました。どうやらLAN内は正常に通信できているようなので、単純にLANからインターネットへの接続に問題があるようです。

　ルータに接続してログを見てみるとエラーログが出続けています。読んでみると、PPPoE接続に失敗している、と書いてあります。設定を変えたこともないので、きっと回線の問題なのでしょう。慌てて契約している業者に連絡してみると、局内工事で回線が止まっているようです。相手はメールしたといっていますが、悲しいかな肝心のメールが見られないのだからしょうがありません。

　しばらくたつと工事は終わったようで、何とかインターネットにはアクセスできるようになりました。メールサーバにtracertしてみましたが、ちゃんとつながっているようです。

工事後、メールサーバに向けてtracertコマンドを実行

C:\>tracert mail.example.co.jp
Tracing route to mail.example.co.jp[220.111.37.180]
over a maximum of 30 hops:
1 <1 ms <1 ms <1ms 192.168.0.1
2 2 ms 2 ms 2 ms 219.160.1.8
3 2 ms 3 ms 3 ms 219.160.1.1
4 6 ms 4 ms 4 ms 221.184.12.161
5 3 ms 3 ms 5 ms 222.146.39.149
6 4 ms 3 ms 3 ms 219.160.10.33
7 4 ms 3 ms 3 ms 210.254.187.14
8 9 ms 3 ms 4 ms 220.111.40.2
9 3 ms 5 ms 3 ms 220.111.40.14
10 3 ms 3 ms 3 ms 220.111.40.70
11 3 ms 3 ms 2 ms mail.example.co.jp [220.111.37.180]
Trace complete.