Posted inホームラボ

IPアドレスの推測はやめよう：ホームラボ向けNetBox IPAM導入プロガイド

HomeLab tutorial - IT technology blog
HomeLab tutorial - IT technology blog

深夜2時のインフラ危機

時刻は午前2時14分。メインのDNSサーバーがダウンし、ホームラボ全体の内部ルーティングが道連れになりました。点滅するカーソルを眺めながら、セカンダリDNSを 192.168.10.5 に割り当てたか、それとも .15 だったかを必死に思い出そうとしています。「network_notes.txt」というファイルはありますが、それは嘘です。もう94日間も更新されていません。IPレンジにpingを打ってみても、半分のデバイスは沈黙したまま。この瞬間、ホームラボを単なる趣味としてカジュアルに運営し続けるのは、精神衛生上良くないと痛感しました。

ホームラボの拡張は諸刃の剣です。VLANが2つ以上、コンテナが20個を超えると、頭の中のマップだけでは限界が来ます。そこで必要になるのが「信頼できる情報源（Source of Truth）」です。エンタープライズ環境では、NetBoxというツールを頼りにします。これは専用のIPアドレス管理（IPAM）およびデータセンターインフラ管理（DCIM）ツールです。LANケーブルのコネクタを1つ作る前に、まずアーキテクチャを文書化することを強制してくれます。

経験から学んだことは、ドキュメント作成は「未来の自分へのプレゼント」だということです。クローゼットの中の6Uラックを管理していようと、複数リージョンにまたがるクラウド展開をしていようと、正確なポート間のマッピングを知っているかどうかが、5分で解決するか、3時間のダウンタイムになるかの分かれ目になります。

なぜホームラボにNetBoxなのか？

ネットワークスキャナーのことは一旦忘れましょう。NmapやAngry IP Scannerのようなツールは、ネットワーク上の「現在の状態」を教えてくれます。対してNetBoxは、「あるべき姿」を提示します。この違いは極めて重要です。NetBoxがあるIPは空いていると主張しているのに、スキャナーがアクティブだと示した場合、それは「野良」デバイスを見つけたか、ドキュメントの更新漏れがあることを意味します。NetBoxを使用して、具体的に以下の要素を標準化しましょう：

  • IPAM: サブネット（プレフィックス）、IPアドレス、VRFの追跡。
  • DCIM: 物理ラック、デバイスモデル、配線のマッピング。
  • 仮想化: クラスターやVMを物理ハードウェアとは別にグループ化。
  • データの整合性: AnsibleやTerraformなどの自動化ツールのためのセントラルAPIを提供。

Docker ComposeによるNetBoxのデプロイ

以前のNetBoxのインストールは、PostgreSQLのチューニングやRedisの依存関係の処理など、非常に骨の折れる作業でした。現在では、コミュニティが維持しているDocker版のおかげで、デプロイは非常に簡単です。データベースやワーカープロセスをホストOSから分離できるため、私はこの方法を好んで使っています。

1. 環境のセットアップ

まず、公式の netbox-docker リポジトリを取得します。私は整理整頓のため、インフラツールを ~/infra/netbox にまとめています。

mkdir -p ~/infra/netbox && cd ~/infra/netbox
git clone -b release https://github.com/netbox-community/netbox-docker.git .

次に、 docker-compose.override.yml ファイルを作成します。これにより、コアファイルとは別にカスタム設定を保持でき、将来のアップデートもコマンド一つで済むようになります。

version: '3'
services:
  netbox:
    ports:
      - 8080:8080

2. 初期設定と起動

NetBoxを動作させるには環境変数が必要です。デフォルト設定は大抵の 192.168.1.0/24 環境で動作しますが、提供されているサンプルファイルを編集して簡単に調整できます。まずはイメージをプルしてスタックを起動しましょう。

# イメージをプルする
docker compose pull

# スタックを起動する
docker compose up -d

初回起動時にはデータベースのマイグレーションが実行されるため、通常45〜90秒ほどかかります。コンテナが正常に起動したら、ログイン用の管理者アカウントを作成する必要があります。

docker compose exec netbox /opt/netbox/netbox/manage.py createsuperuser

プロンプトに従ってユーザー名とパスワードを設定してください。これで、 http://your-server-ip:8080 からダッシュボードにアクセスできるようになります。

「信頼できる情報源」を構築する

むやみにボタンをクリックしたくなる衝動を抑えましょう。空のNetBoxインスタンスは白紙のキャンバスと同じであり、ドキュメント作成には論理的なフローが必要です。私がラボの標準化に使用している正確なワークフローをご紹介します。

物理的および論理的なスペースの定義

NetBoxは厳格です。IPアドレスを単独で存在させることはできません。まずは「組織（Organization）」から始めましょう：

  1. Sites（サイト）: 「自宅」や「アパート」など、物理的な場所を定義します。
  2. Regions（リージョン）: ローカルハードウェアに加えてリモートのVPSなども管理する場合に便利です。
  3. Racks（ラック）: たとえ「ラック」がIKEAのテーブルだったとしても定義してください。後で機材の奥行きやRU（ラックユニット）の使用状況を可視化するのに役立ちます。

ネットワークのマッピング (IPAM)

ここからが本番です。**IPAM > Prefixes** に移動します。プレフィックスとは `10.0.10.0/24` のようなサブネットのことです。機能別のVLANごとにプレフィックスをグループ化することを強くお勧めします：

  • VLAN 10 (管理用): 管理スイッチ、PDU、Proxmoxホストなど。
  • VLAN 20 (信頼済み): メインのワークステーションやモバイルデバイス。
  • VLAN 30 (IoT): インターネットから隔離されたスマート電球やカメラ。
  • VLAN 40 (ゲスト用): 信頼できないデバイス用のサンドボックス。

プレフィックスが確定したら、**IP Addresses** を追加していきます。稼働中のデバイスは「Active（アクティブ）」に、来週末にデプロイ予定のものは「Reserved（予約済み）」に設定します。

デバイスの階層構造

NetBoxでは正確さが求められます。単に「サーバー」を追加することはできません。まず**Manufacturer**（メーカー、例：Dell）、次に**Device Type**（デバイスタイプ、例：PowerEdge R730）、そして最後に具体的な**Device**（デバイス）ユニットを定義する必要があります。一見過剰に思えますが、サーバーのどのNICがどのスイッチポートに接続されているかを思い出そうとするとき、この詳細さが真価を発揮します。

検証とメンテナンス

最大の罠は「ドキュメントの腐敗（Documentation Decay）」です。IPを変更したのにNetBoxの更新を忘れると、ツール自体が負債に変わります。正確性を維持するために、私は2つの方法を使っています。

1. ‘Ping’ による検証

NetBoxは自動スキャンを行いませんが、そのギャップを埋めることができます。以下は、 pynetbox を使用して、ステータスが「Active」なのにICMPに応答しないIPを特定し、アラートを表示するPythonスクリプトの断片です。

import pynetbox
import os

nb = pynetbox.api('http://localhost:8080', token='YOUR_API_TOKEN')

for ip in nb.ipam.ip_addresses.filter(status='active'):
    address = str(ip).split('/')[0]
    response = os.system(f"ping -c 1 -w 1 {address} > /dev/null 2>&1")
    if response != 0:
        print(f"アラート: {address} ({ip.dns_name}) に到達できません！")

2. 自動化との統合

自動化と連携させることで、NetBoxは単なるデジタルノートから強力なエンジンへと進化します。Ansibleを使用している場合は、NetBoxインベントリプラグインを活用しましょう。 hosts.ini ファイルにIPをハードコードする代わりに、AnsibleがNetBoxに直接問い合わせるようにします。これにより、ドキュメントそのものが構成（コンフィギュレーション）になります。

最後に

NetBoxのセットアップは、最初はデータ入力などの手間がかかります。しかし、次に深夜2時にネットワークループのトラブルシューティングをするとき、推測に頼る必要はなくなります。 `10.0.20.55` がVLAN 20に接続されたノード2上のDebian VMであることを正確に把握できるからです。推測はやめて、文書化を始めましょう。あなたの精神衛生が守られるはずです。

Share:
Tags: