検証ルータのためにLAN半壊
前回の記事で、HUBが壊れただけでLAN全滅した、という記事を書きましたが、もうひとつ残念な話思い出しましたので、もう一本書いておきます。
案件内容
- タイトル: 某一部上場企業 情報システム部門におけるPC接続障害
- 案件規模： 予算？ メンバー12人 エンドユーザー2000人
- 田中(゜p゜)のポジション： 情報システム部門 ITインフラ マネージャ
経緯
田中(゜p゜)が、情シスのマネージャやっていた時の話です。
ある日の午後、本社にいるユーザから立て続けにPCが接続できないというコールが入り、情シス部門は緊張状態に入りました。
コール数は時間を追うに連れて増え、結局、対象者は本社全体の1/3に広がり、大混乱に。
監視等のアラートはなく、サーバ、NW機器共に一切異常無し。もちろん田中(゜p゜)含めた情シス部員も大混乱。
事件は現場で起きてるんだ！ ということで、何人か繋がらない申告してきたユーザのPCのIPアドレスを実際に見てみると、アレ？本社のセグメントと違うIPアドレス※が振られてるよ？
※リンクローカルでもないです。
失敗の内容
結論、田中(゜p゜)はなにも失敗してない。
強いて言えば、L2SWに、ポート認証とかDHCPサーバを抑制する抑制する設定を入れてなかった前任者が悪いのですが、予算の関係もありますし。
あと、検証ルータをLANに接続しやがった技術者が失敗してる。
原因
↓コレ。
いや、YAMAHAはなんにも悪くない。悪いのはコレ繋いじゃったエンジニア。
つまるところ、技術開発職のエンジニアが、ローカル環境作るの面倒だからといって、本社LANに検証ルータ繋いでゴニョゴニョやっとったのです。
そしてさらに残念なことに、この検証ルータにはローカル環境の名残のDHCPサーバが起動しており、本社のPCは検証ルータのDHCPサーバーからデータセンターと通信できないIPアドレスを取ってしまっていたのでした。
原因さえわかればあとはこっちのもの。
そこからは、そのトンチキDHCPサーバーのMACアドレスからポートを辿って所在を洗い出し、有無を言わさず検証ルータ引っこ抜き。
ホントはなんかルータに火を付けたり、ビルから投げ捨てたりとか、怒りのパフォーマンスしたかったですが、大人なのでやめました。
当の本人不在だったんで、すぐ折り返せっていうメモ置いときましたけど。
ちなみに本番DHCPサーバーはデータセンターで稼働していて、ノントラブルでしたが、DHCPプロトコルは、ブロードキャストにクエリ投げて、早く帰ってきた方のIPアドレスをアサインしてまうので、この動きはどうしようもないです。
結果
その検証ルータを外したあと、接続できないユーザのPCのケーブルを抜き差しして復旧。
正味2時間ほどでしたが、いい悪夢見させていただきました。
田中(゜p゜)はそのエンジニアと仲が良かったので、握りつぶしたかったのですが、被害が想像以上に大きく、結局そのエンジニアは始末書を書くことに。
反省点
設計上、ポート認証か、DHCPの制御しとけばよかったかな、と思いますが、構築時に固めた仕様を運用で全面的に変更するのは、かなり厳しいのです。
ポート認証は田中(゜p゜)得意なので、別記事で書きます。田中(゜p゜)の好きな802.1xの話。
あと、しつこいようですがヤベエ機器はLANに参加させちゃいけねぇ。色々な意味で。
2020/09/13