1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

挙動がおかしいDHCPクライアントが原因で、IPアドレス枯渇による通信障害が発生した

1
Posted at

 一般中小企業の情シスをやっています。先日ようやく原因にたどり着けたトラブルです。

起きたトラブル

 勤務する支社で、社内Wi-Fiには繋がるが「インターネットなし」で通信できない人が出る。確認すると、IPアドレスが来ていない。
 最初は会議などで他支社から人が集まったときにのみ発生しており、単純にDHCPで配布できる数をオーバーしているのかと考えた。が、その後状況が悪化していき、特に会議などがなくても発生するようになった。

DHCPサーバー確認と応急措置

 DHCPサーバーのアクセス権を預ったので確認すると、配布禁止IPが多数登録されていた。160 IPを配布できるうち50以上が配布禁止になっている。
 IPを固定して使う複合機等の機器は、DHCPのスコープ外に設定しており、スコープ内でそんなに多数のIPを止める理由は誰に聞いても不明。
 現に起きているIP枯渇への対応のため、配布禁止を様子を見ながら解除していったが、最終的にすべて禁止を解除してもトラブルは発生しなかった。

 しかし1年ほど経過して、同じネットワークトラブルが再発。やはりDHCPの配布禁止IPが数十件も登録されていた。

そもそもなぜ配布禁止になるのか?

 DHCPサーバーのログは、当日と前日分しか見られない仕様だった。(業務用広域VPN網サービスの機能として提供されているもので、ウェブ管理画面から操作できる以上のことはできなかった)
 一度配布禁止をすべて解除して、翌日にログを確認する、と数日繰り返したところ、DHCP DECLINEのログが見つかった。そして、DECLINEされたIPが配布禁止に登録されており、自動登録される仕様だとわかった。

 配布禁止されていたIPは、昨日端末AにASSIGNされた24時間後の今日、端末BにASSIGNされ、直後にDECLINEされていた。
 DECLINEからさほど時間が経っていなかったので、そのIPにPingを打ってみると、応答があった。

DHCPの仕様を確認して考察

 DHCPが配布する動的IPはリース期間があり、4時間に設定されていた。
 クライアントはリース期間の半分が経過すると、リース更新をリクエストする。DHCPサーバーはそれを受けて更新を行う。更新リクエストがないままリース期間を過ぎたら、そのIPは空いたものと判断する。

 ログを確認すると、どの端末も定期的にEXTENDしているログが残っているが、上記端末Aのみ、リースの延長を行っているログがない。にもかかわらず、実際にはIPアドレスを使用し続けているようで、pingが通る。

 そのことから、以下のようなことが起きていたらしい。

  • DHCPサーバーが端末AにIPを配布
  • 端末Aは、行うべきリース延長をせずにIPを握り続ける
  • リース延長がないから、DHCPサーバーはリース期限切れでそのIPが空いたと判断
  • 端末BがIPを要求
  • DHCPサーバーが端末Bに、空いているはずのIPを配布
  • 端末BはそのIPを使おうとしたが、実際には端末Aが握っているため衝突
  • 端末BがDHCPサーバーに別のIPを再度要求
  • DHCPサーバーは、最初に配布したIPアドレスがおかしいと判断して使用禁止に登録、別IPを端末Bに配布

 これによって、端末AがIPアドレスをリクエストして受け取り、握ったままリース期間を過ぎる度に、衝突を起こしかねないIPが発生、実際に衝突すると配布禁止にされる。
 DHCPサーバーの挙動は理解できるので、端末Aの挙動がおかしい。

端末Aは何者か?

 DHCPサーバーのログには、端末のOSを判断できる文字列が含まれていた。MSFT.5.0はWindows 11で、android-dhcp-xxは見たまま。iOSはN/Aになっていた。
 端末Aはudhcp-1.24.1とあり、おそらくLinuxか。事務用のPCなどはすべてWindowsで、Linuxがあるとすれば技術部門が持っている装置類に組み込まれているものかと思われた。

 また、同じくログにMACアドレスも記録されていたので、それを調べてみると、台湾の組み込みWi-Fiモジュールメーカーに充てられているとわかった。
 Wi-Fiならどれかのアクセスポイントに繋がっているので、各APの接続中端末を確認していくと、端末AのMACアドレスを発見。設置されている部屋まで絞り込めた。
 その部屋にあった装置類を確認してみると、とあるメーカーの3Dプリンターが端末AのIPを持っていた。

対処

 おそらく、問題の3Dプリンターに固定IPを割り当て、DHCPを使わせなければ解決すると見られた。

 しかしその3Dプリンターは、ネットワークまわりの挙動がおかしかった。
 DHCPを無効にして固定IPを指定する、という操作はできたが、やってみると、設定を無視してDHCPでIPを取った上で、手動設定したIPアドレス欄を目の前で書き換える、という挙動。
 幸いランダムMACアドレスではないので、DHCPサーバー側でそのMACアドレスには固定のIPアドレスを払い出すようにした。

お気持ち

 なんぼなんでもネットワークに繋ぐ機能を提供するなら、DHCPクライアントとして正しく振る舞うくらいのことはやってよー、と思いました。
 しかし私も成り行きで情シスやってるので、メーカーのひとも成り行きで、畑違いでネットワークのイロハも知らないままプログラム書くことになっちゃったのかな。DHCPでIP取れた! 通信もできた! ヨシ! で終わっちゃったのはわかる気がする。

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?