編集チームの記事その他の記事

IPアドレス管理ツールの選び方――確認すべき機能と実力

IPAMツールを実務に即して比較するために、実際の割り当て、記録の食い違い、復旧、再利用できるデータの書き出しを、導入前にどう検証するかを解説します。

Ann · · 読了まで約4分

目次

ミニチュアの技術者が、ネットワーク模型、記録カード、開いた工具箱を見比べている。

役に立つツールは、アドレス計画と実際のネットワークを照合し、確実に変更を実施できるよう支える。

新しいサービスに使うアドレスが必要になった。ある担当者は表計算ファイルを確認し、別の担当者はクラウドの管理画面を調べ、もう一人は先月予約したアドレスを思い出す。IPアドレス管理ツールに対して問うべきことは単純だ。こうした情報をまとめ、食い違いを明らかにし、次の変更を確実に行えるかどうかである。

IPAMは、アドレス空間とその利用状況を記録する仕組みだ。ツール選びは、担当者が行う必要のある仕事、すでに稼働しているシステム、そして供給元を変更しても組織が保持できなければならない情報を整理するところから始まる。

仕事を明確にしてから製品を比べる

主に必要なのが台帳というチームもある。プレフィックス、個々のアドレス、拠点、担当者、予定されている変更を把握できればよい。一方で、DNS、DHCP、IPAMを組み合わせた統合DDIプラットフォームを必要とするチームもある。DNSは名前を解決し、DHCPはクライアントにネットワーク設定を配布し、IPAMはアドレス計画を記録する。クラウドを扱うチームでは、まず複数のアカウントやリージョンにまたがるアドレスプールの調整が必要かもしれない。

これらは、それぞれ異なる導入判断になる。たとえば、NetBoxはネットワーク基盤と併せてIPアドレス空間を記録する。一方、Amazon VPC IPAMは、AWS上のワークロード向けに計画と割り当ての機能を提供する。どちらの例も、あらゆる場合に最良の製品であることを示しているわけではない。自分たちのチームが実際に運用する機能を比較しよう。

それぞれの記録が何を意味するかを確かめる

役立つ記録には、アドレスまたはプレフィックス、ルーティングの適用範囲、状態、担当するサービス、情報源、最終確認時刻が含まれる。「割り当て済み」は、計画上の割り当てを意味する場合がある。「観測済み」は、特定のシステムが特定の時刻にそのアドレスを確認したという意味だ。ダッシュボードでは、その違いが分かるようになっている必要がある。

評価の際には、判断に困る例を試してみよう。あるアドレスがIPAMでは予約済みで、クラウドの台帳には存在せず、DNSにはまだ残っているとする。ツールはこの食い違いを説明するだろうか。それとも、何の断りもなく空きアドレスと判定するだろうか。機器はスリープ中かもしれず、フィルタリングの対象になっているかもしれず、一時的に切断されているかもしれない。自動検出で得られるのは判断材料であって、依存関係の全体像ではない。

申請から復旧まで、一連の変更を試す

隔離したテスト用ネットワークで、小さなプレフィックスを申請し、アドレスを予約し、サービスを構築し、その名前を更新して、最後に廃止する。どこまでを製品自身が行い、どの手順には別のシステムが必要なのかを確認しよう。機能一覧にAPIと書かれていても、ワークフロー全体が動いて初めて役に立つ。

次に、同じアドレスに対して2件の要求を競合させる。更新を途中で中断する。タイムアウトした要求を再試行する。記録には、何が成功し、何が失敗し、何への対応が必要かが示されなければならない。同じアドレスを黙って二重に割り当ててはならない。最後に、履歴を失わずに担当者が変更を元に戻せることを、実際に示してもらおう。

実際のネットワーク構成を表現できるか

IPv4とIPv6、プライベートとパブリックのアドレス空間、クラウドアカウント、拠点、ルーティングドメインを確認する。ルーティングの適用範囲が分離されていれば、別々の顧客が同じプライベートアドレス範囲を使うことに問題はない。ツールはその分離を表現できなければならず、同じ番号が現れるたびにシステム全体での重複と扱ってはならない。NetBoxのVRFモデルは、この区別の一例だ。

担当者が毎日使う操作画面も試してみよう。プレフィックスの管理担当者を探す、保留中の予約を確認する、更新が滞ったデータソースを特定する、といった作業だ。デモでは分かりやすく見えるシステムも、似た名前の項目が何千件も並ぶと使いにくくなることがある。

試用の段階でデータの可搬性を確かめる

実際の利用を代表するプレフィックス、割り当て、識別子、関係性、変更履歴を一式書き出す。それを製品の外で読み、別のシステムが意味を再構成できるか確認する。ルーティングの適用範囲が失われたり、関係性を元のソフトウェアでしか読み取れなかったりするなら、エクスポートボタンがあるだけでは不十分だ。

対象範囲を限定したアクセス権限、復旧方法、管理サービスが使えなくなった場合の動作も試す。既存の通信と新規の構築では、依存する仕組みが異なる可能性がある。各現場のチームが明確な責任範囲の中で行動でき、同時に誰もが整合した記録を確認できるようにしたい。

仕事がどう改善したかで評価する

申請への対応時間、割り当ての競合、古くなった記録、復旧に要する手間を、試用の前後で比較する。費用には、連携作業、保守、研修も含める。小規模で変更の少ないネットワークなら、規律ある台帳管理で十分な場合がある。多数の拠点を持ち、変更の多いネットワークには、より強い調整機能が必要だ。

記録を管理する仕組みを理解し、必要なら別の仕組みに置き換えられるという実務上の能力は、Lu Hengのノート72につながる。調整は、参加者が自ら確認し、引き継いでいける記録によって、運用の継続を支えるべきだという考えである。基礎となる概念については、IPアドレス管理の役割へ進んでほしい。