Kea DHCPサーバー構築：Rocky Linux 9・予約・検証・HAガイド

EdwardMoon

Kea DHCPサーバーは、クライアントへIPv4アドレス、デフォルトゲートウェイ、DNS、リース期間を自動提供する現代的なDHCPv4実装です。CentOS 7.9用の従来のdhcpd構成は、新規導入には適しません。CentOS 7はサポートが終了し、ISC DHCPも2022年で保守を終了したためです。

この記事はRocky Linux 9とKea 3.0 LTSの公式RPMを使い、まず単一サブネットを安全に構成します。実インターフェースとアドレス計画を確認し、JSON構文検査、最小限のファイアウォール、パケットキャプチャ、予約競合の防止、DHCP relay、冗長化設計まで説明します。

ISC DHCPではなくKeaを選ぶ理由

ISCはDHCP 4.4.3-P1を最後の保守リリースとし、新規環境にはKeaなど保守中のサーバーを選ぶよう推奨しています。KeaはJSON設定、Control Commands、統計、hook、memfile・MySQL・PostgreSQLのリースbackend、HA機能を提供し、3.0系は長期サポートブランチです。

2026年7月時点の最新安定ブランチは3.2ですが、このガイドでは長いサポート期間が必要な本番向けに3.0 LTSを選びます。導入前にISCのサポート方針とセキュリティ勧告で、使用する正確な保守バージョンを確認してください。

DORAの動作

クライアントとサーバーが別のbroadcast domainにある場合、L3機器のDHCP relayが要求をunicastで転送します。relayアドレスとsubnet選択、サーバーからrelayへの戻り経路、ACLのUDP 67・68の許可をすべて整える必要があります。

Rocky Linux 9での事前確認

例のサーバーは192.168.100.2/24、インターフェースはens192、ゲートウェイは192.168.100.1です。そのままコピーせず、実NIC、VLAN、重複アドレス、既存DHCPサーバーを先に調べてください。

cat /etc/os-release
ip -br link
ip -br address
ip route
nmcli -t -f NAME,DEVICE,TYPE,STATE connection show --active
ss -lunp | grep -E ':(67|68)\b' || true

アドレスプールの競合を確認する

• 動的プールをゲートウェイ、サーバー、プリンター、ネットワーク機器の固定アドレスと重ねない。
• 予約アドレスを例のように動的プールの外へ置くか、Keaの競合処理方針を明確に検証する。
• 同じVLANで既存DHCPが応答していないか、パケットキャプチャで確認する。
• MACランダム化によってhw-address予約が使えなくなる可能性を確認する。

3.0 LTS公式RPMをインストールする

ISCはRHEL系パッケージをCloudsmithで提供しています。リモートスクリプトを直接パイプで実行せず、ローカルへ取得して内容とTLSの提供元を確認してから実行します。組織の供給網方針がある場合は、承認済み内部リポジトリへ同期してください。

curl --fail --location --proto '=https' --tlsv1.2   https://dl.cloudsmith.io/public/isc/kea-3-0/setup.rpm.sh   --output /tmp/isc-kea-3-0-setup.rpm.sh

less /tmp/isc-kea-3-0-setup.rpm.sh
sudo bash /tmp/isc-kea-3-0-setup.rpm.sh

DHCPv4だけを導入し、バージョンを記録する

sudo dnf install -y isc-kea-dhcp4
rpm -q isc-kea-dhcp4 isc-kea-common
kea-dhcp4 -V
dnf repolist --enabled | grep -i kea

ISC RPMの依存関係でEPELなど追加リポジトリが必要になる場合があります。依存関係エラーを--skip-brokenで回避せず、ISCの資料に従ってRocky 9用の承認済みリポジトリと必要パッケージの提供状況を確認します。

JSON設定

公式RPMの既定ファイルは通常/etc/kea/kea-dhcp4.confです。先にバックアップし、sudoeditで次の例を環境に合わせて入力します。コメント、カンマ、引用符を誤りやすいため、サービス起動前に必ずKea自身の検査を通してください。

sudo cp -a /etc/kea/kea-dhcp4.conf   /etc/kea/kea-dhcp4.conf.before-$(date +%F-%H%M%S)
sudoedit /etc/kea/kea-dhcp4.conf

{
  "Dhcp4": {
    "interfaces-config": {
      "interfaces": [ "ens192" ]
    },
    "lease-database": {
      "type": "memfile",
      "persist": true,
      "name": "/var/lib/kea/kea-leases4.csv",
      "lfc-interval": 3600
    },
    "valid-lifetime": 3600,
    "renew-timer": 900,
    "rebind-timer": 1800,
    "subnet4": [
      {
        "id": 100,
        "subnet": "192.168.100.0/24",
        "pools": [
          { "pool": "192.168.100.100 - 192.168.100.200" }
        ],
        "option-data": [
          { "name": "routers", "data": "192.168.100.1" },
          { "name": "domain-name-servers", "data": "192.168.100.53" },
          { "name": "domain-name", "data": "example.internal" }
        ],
        "reservations": [
          {
            "hw-address": "00:11:22:33:44:55",
            "ip-address": "192.168.100.50",
            "hostname": "printer1"
          }
        ]
      }
    ],
    "loggers": [
      {
        "name": "kea-dhcp4",
        "output-options": [ { "output": "syslog" } ],
        "severity": "INFO"
      }
    ]
  }
}

例から変更する値

構文検査と起動

sudo kea-dhcp4 -t /etc/kea/kea-dhcp4.conf
sudo systemctl enable --now kea-dhcp4
sudo systemctl status kea-dhcp4 --no-pager
sudo journalctl -u kea-dhcp4 -b --no-pager | tail -n 100

構文検査の成功はネットワーク設計の正しさを意味しません。誤ったinterface、gateway、DNS、重複プールも構文上は有効です。隔離VLANで実際のリース取得、ルーティング、名前解決を検証してください。

ファイアウォールと公開範囲の制限

DHCPv4サーバーはUDP 67、クライアントはUDP 68を使います。直結VLANだけを扱う場合は、サービスNICのfirewalld zoneでDHCPを許可します。relay環境ではrelay、ACL、ルーティングを併せて限定してください。

sudo firewall-cmd --get-active-zones
sudo firewall-cmd --zone=internal --add-service=dhcp --permanent
sudo firewall-cmd --reload
sudo firewall-cmd --zone=internal --list-services
sudo ss -lunp | grep ':67'

例のinternalが実際のサービスNICに割り当てられているか先に確認し、全zoneへポートを開かないでください。ネットワーク機器のDHCP snoopingでは、relayと正規サーバーの経路だけをtrustedポートに指定します。

パケットとリースの診断

DORAパケットをリアルタイムで確認する

sudo tcpdump -ni ens192 -vvv   '(udp port 67 or udp port 68)'

サービスログとリースファイルを確認する

sudo journalctl -u kea-dhcp4 -f
sudo ls -lh /var/lib/kea/
sudo tail -n 20 /var/lib/kea/kea-leases4.csv

DHCP relayと複数サブネット

DHCPサーバーを全VLANへ直結する必要はありません。ルーターやL3スイッチのrelayが転送すると、Keaは指定されたリンク情報でsubnetを選びます。各subnetに一意のidを使い、応答経路とrelayのアクセスACLを検証してください。機器固有のrelayコマンドはベンダーの公式資料に従います。

ip route get <RELAY_IP>
sudo tcpdump -ni any -vvv   'host <RELAY_IP> and (udp port 67 or udp port 68)'
sudo journalctl -u kea-dhcp4 --since '-10 min'

予約の設計

予約は手動の固定IP設定とは異なり、サーバーが同じ識別子を見たときに特定のリースを提供する方針です。管理対象のプリンターやサーバーNICではMACが安定していても、モバイル端末はSSIDごとのprivate MACを使う場合があります。hw-address、client-id、flex-idを併せて検討してください。

• 予約アドレスが動的プールと重なる場合の競合防止を試験する。
• 資産管理のMAC、所有者、用途と予約の変更履歴を関連付ける。
• 機器交換時に旧識別子とリースを整理する承認手順を設ける。
• 予約数が増えたら、JSONの手作業より対応するhost backendと変更APIを検討する。

ISC DHCPからの移行

ISCのKea Migration Assistantはdhcpd.confを部分変換しますが、結果をそのまま本番へ適用できるわけではありません。条件式、DDNS、failover、class、リース処理、未対応オプションを人が確認する必要があります。旧・新サーバーが同じプールを同時に提供しないように切り替え時間を設計します。

1. 既存設定、リース、DNS連携、relay、オプション、予約をバックアップして一覧化する。
2. KeaMAの警告と未変換構文を確認し、最小限のJSONを作る。
3. 隔離VLANでDORA、予約、更新、DNS、PXE、長期間のリース動作を試験する。
4. 既存リースの時間経過を考慮して期間を段階的に短縮するか、移行中のアドレス競合防止方法を決める。
5. 変更時間帯に旧サーバーの応答を止めてKeaを起動し、パケット、ログ、重複アドレスを観測する。
6. 切り戻し条件と旧サーバー再有効化の手順を事前に文書化する。

高可用性の設計

前のJSONは単一DHCPサーバーの設定で、HAは有効になりません。実際のHA導入には、選択バージョンのHA hookパッケージ、hooks-libraries内のpartner設定、HTTP/HTTPS制御経路、両サーバーへ転送するrelay設定が必要です。以下は設計・試験の基準であり、完成したHA設定の代わりではありません。ISC HA Quickstartの同じバージョンの例を出発点に、2ノードの設定を一緒に検証してください。

HA hookはhot-standbyやload-balancingのpartner状態とリース更新を管理できます。同じJSONを2台へ置くだけではHAになりません。heartbeat、状態遷移、リース同期、split-brain時の応答方針、relay宛先、hookの対応バージョン、障害シナリオを併せて設計します。

• 両サーバーの時刻、バージョン、hook、subnet設定をそろえる。
• HA通信ポートを管理網だけに許可し、TLSと認証の対応範囲を確認する。
• primary停止、HAリンク断、relay経路断、リースbackend障害を個別に試験する。
• partner-downへの移行時間中の影響を、実端末とperfdhcpで測定する。
• HAは誤設定、削除、操作ミスも複製するため、設定のバージョン管理とバックアップを別途用意する。

運用チェックリスト

• CentOS 7とISC DHCPのEOLを認識し、サポートされるOSとKeaブランチを選択した。
• 実interface、subnet、pool、gateway、DNS、relay、既存DHCPの応答を確認した。
• JSON検査後に起動し、DISCOVER、OFFER、REQUEST、ACKをキャプチャした。
• サービスVLANまたはrelay経路だけを最小限許可した。
• 予約アドレス、識別子、random MAC方針、プール枯渇の警報を管理する。
• 設定、リースbackend、hook、パッケージバージョンを保存し、復旧を試験する。
• HAではサーバー停止に加え、リンク分断とリース同期失敗も検証した。

公式資料と関連ガイド

• ISC DHCPの保守終了案内
• Kea 3.0 LTS公式管理者資料
• ISC Keaの公式パッケージとサービス名
• Kea 3.0 Cloudsmithの設定
• ISC DHCPからKeaへの移行
• Kea HA公式Quickstart
• Linuxのディスク・inode障害診断

まとめ

新しい環境ではEOLのdhcpd例を繰り返さず、サポート中のKeaとOSを選び、アドレス設計と実パケットで検証してください。インストール以上に重要なのは、DHCPの重複防止、プールと予約の管理、relay経路、最小限のファイアウォール、リースと設定の復旧、ネットワーク分断を含むHA試験です。