突然のネットワーク不通，サーバのパフォーマンス問題……ITインフラエンジニアには日々さまざまな課題が降りかかってきます。これらの課題に効率的に対処していくには，効率的な切り分け，分析，対処，場合によっては改善策が必要です。今回は，筆者が経験した比較的シンプルなネットワーク，サーバの障害例を紹介しながら，問題解決に向けて押さえておきたいポイントを紹介します。

トラシュー事例（初級編）
「旅館の無線LANがつながらない！」

筆者はスノーボードを満喫するため，ある山の旅館に宿泊していました。この旅館には無料の無線LANサービスがあります（図1）⁠。夜，無線LANに接続したのですが，アクセスポイントには接続できるものの，インターネットとの通信ができません。「⁠あれ？ なんかおかしいな？」と思いましたが，使えないものはしかたがないと思い，深追いはしませんでした（注1）⁠。しかし，翌日の朝食時に旅館の支配人に声をかけられたのをきっかけに，通信を復旧させるお手伝いをすることになりました。

注1）

海外のホテルなどでは，まともに通信できることの方が少ない気がします。余談ですが，Software Design 2015年3月号の第1特集であり，gihyo.jpにも掲載されている「カンファレンスネットワークの作り方」はたいへんおもしろく，勉強になりました。

現状を把握する

この旅館のネットワークは，電話会社の光回線向けにレンタルされるPPPoE（Point-to-Point Protocol over Ethernet）が可能なインターネット接続用ルータ，および複数の家庭向け無線LANアクセスポイントで構成されていました。とりあえず，ルータの設定Webページにログインして再起動したところ，それだけでインターネット通信ができるようになったので，しばらく様子を見てもらうことにしました。その後，スノーボードを終え，遅めのランチをとっていたところ，あらためて支配人から相談を受けました。

• 「またインターネットがつながらなくて……クレジットカードの決済機も使えないんです」

事務所に入り，Windows端末のコマンドプロンプトからGoogleのDNSサーバ8.8.8.8（注2）へpingを打ってみても返事がありません。朝方にはちゃんとインターネット通信ができていたのにおかしいなと思い，端末からルータにpingを打ってみましたが返事がありません。

Windowsホストマシンでipconfigコマンドを実行してみたところ，ルータがあるはずのサブネット，192.168.xxx.0/24とは異なる空間のIPアドレス／サブネットマスクがホストのネットワークインターフェースに設定されていました（図2）⁠。

まさかと思いながら，Windowsのインターフェース情報から見つけたDHCPサーバのアドレスにpingを打ちながら宿泊者向けの無線LANアクセスポイントのLANケーブルを抜くと，そのDHCPサーバのIPアドレスからのICMP応答が絶えました。そのあと。WindowsホストでIPアドレスを取得しなおしてみると，今度は192.168.zzz.0/24のIPアドレスが……同じセグメントに，まさかの3つめのDHCPサーバがあるようです。

さらにDHCPサーバを探すため，ルータやハブに刺さっているLANケーブルを1本1本抜いていくと，やがて意図したとおり192.168.xxx.0/24のIPアドレスがリースされるようになり，サービスが復旧しました。どうやら，旅館内に設置された無線LANアクセスポイントのほとんどが，自動設定機能によって，DHCPサーバとして動作していたようです（注3）⁠。

注2）

個人的に，覚えやすく，少なくとも国内ならインターネットのどこからでもICMP ECHO REQUESTに応えてくれるIPアドレスとして重宝しています。: )

注3）

小さな旅館ということもあり，家電量販店でよく見かける家庭用無線LANルータが使われていました。動作モード切り替えスイッチによりNATルータ／ブリッジモード，もしくは自動判断が可能なものですが，上位ルータの停止時に下位ルータのほとんどがブリッジモードからNATルータモードに切り替わり，さらに使用していたEthernetポートの都合により，DHCPサービスが上位ネットワークに流れてしまったようです。

すべての機器を再設定し対処

状況が見えてきたところで，具体的なサービス復旧作業にとりかかります。念のため無線LANアクセスポイントの設定を初期化・再設定し（注4）⁠，すべて再設定および最新ファームウェアを適用しました。また，今後の混乱を防ぐために不要な自動設定機能は無効化します。再設定後のアクセスポイントに接続し，tracerouteコマンドで8.8.8.8までの経路を調べ，意図どおりのルートでパケットが送受信できていることも確認できました。今後のために，何につながっているかわかるよう各Ethernetケーブルにタグをつけ，本日時点のネットワーク図を書いて作業完了です（注5）⁠。

今回筆者が遭遇したシチュエーションは，インターネットの接続性に関するトラブルとしては最も単純な類のものですが，実際に小規模のオフィスで経験しやすいものだと思います。うっかり失敗しがちな今どきのパターンとしては，仮想マシン上で立ち上げたDHCPサービスのパケットを上位ネットワークに流してしまい，隣の席の上司のコンピュータがそのDHCPサーバからアドレスをリースされて通信ができなくなり大騒ぎになった，なんてこともよくあります。ITエンジニアであれば，TCP/IPネットワークの最低限のトラブルシューティング手法やコマンド（表1）は知っておきたいものです。

注4）

一部老朽化し不安定な機材などもあり，翌日，ルータの一部交換や追加，セキュリティ対策も行いました。

注5）

設定値の状況共有という意味合いもありますし，私自身が翌年に訪問したときに必要となるかもしれません……。