Windows ServerのDHCPフェールオーバーを更新するとき、IP helper（DHCPリレー）が旧スタンバイサーバーのIPを参照していて変更できないケースがあります。本記事では、旧IPを新サーバーへ安全に引き継ぎ、A↔Cでフェールオーバーを再構成する手順と注意点を解説します。
今回の前提とゴール
既存環境では、Windows Server DHCP のフェールオーバー（ホットスタンバイ）をサーバーA（稼働系）／サーバーB（待機系）で運用しているものの、各拠点のL3スイッチやルーターに設定されたIP helper（DHCPリレー）の転送先が「サーバーBのIPアドレス」になっており、アドレス変更が現実的ではない、という状況を想定します。
そこで、新しいDHCPサーバーCを用意して、フェールオーバーペアをA↔Cに組み替えつつ、サーバーCが旧サーバーBのIPアドレスを引き継ぐことで、IP helperの大量修正を避けるのが狙いです。
| 項目 | 既存（Before） | 目標（After） |
|---|---|---|
| フェールオーバー | A ↔ B（ホットスタンバイ） | A ↔ C（ホットスタンバイ or 負荷分散） |
| IP helper の宛先 | B のIP | 変更しない（BのIPのまま） |
| 旧BのIP | Bが保持 | Cが保持（引き継ぎ） |
| Active Directory のDHCP承認 | A/Bが承認済み | Cを承認し、Bは整理 |
IP helper と DHCPフェールオーバーを誤解しないための要点
IP helper（DHCPリレー）は、クライアントが送るブロードキャスト（DHCPDISCOVERなど）を、指定した宛先IPにユニキャスト転送する仕組みです。つまり、ネットワーク機器が「どのIPに転送するか」を決めており、サーバー側はそのIPで受信できれば要求を処理できます。
Windows Server DHCPフェールオーバーは、2台のDHCPサーバー間でスコープ情報やリース状態を同期し、片系障害時でも配布を継続できる機能です。ここで重要なのは、フェールオーバーはリレーの転送先を自動的に切り替える仕組みではないという点です。IP helper の宛先に届いた要求を、どちらのDHCPサーバーが処理するかは「そのサーバーが受信して応答できる状態か」「ホットスタンバイなら現在どちらがアクティブか」といった条件で決まります。
ホットスタンバイ構成で特に注意したいこと
ホットスタンバイでは、通常時はアクティブ側が主に配布し、スタンバイ側は障害時の切り替えを担います。もしIP helper の宛先がスタンバイ側だけになっている場合、通常時にスタンバイ側が応答しない（または限定的にしか配布しない）設計だと、クライアントがIPを取得できないリスクがあります。
そのため、IP helper を変更できない前提なら、「既存のIP helper宛先IP（旧BのIP）を持つサーバーを、通常時に配布できる側にする」のが安全です。この記事の手順では、旧BのIPをCに持たせたうえで、A↔Cの役割（どちらをアクティブにするか）も含めて破綻しない形に落とし込みます。
結論：旧サーバーBのIPをサーバーCが引き継ぐ構成は動作する
結論から言うと、サーバーCが旧サーバーBのIPアドレスを持つように設計すれば、IP helper（DHCPリレー）がそのIPに向けて転送するDHCP要求をサーバーCが受け取り、通常通り応答できます。
- Windows Serverは、1枚のNICに複数のIPアドレス（いわゆる第2IP）を設定できます。
- IP helper は「指定した宛先IPへ転送」するだけなので、そのIPをCが保持していればDHCP要求はCに届きます。
- A↔CでDHCPフェールオーバーを構成し、スコープやリース情報が同期されていれば、Cが受けた要求に対しても整合の取れた配布が可能です。
クライアントが「旧BのIP」にDHCP要求を投げたらどうなるか
DHCPリレーの転送先はIPアドレスなので、宛先IPが旧BのIPであり、そのIPをCが持っていれば、パケットはCに到達します。あとはC上のDHCP Serverサービスが、該当スコープを持ち、AD承認が済んでいて、バインド（Bindings）も適切なら、通常通りDHCPOFFER／DHCPACKを返します。
逆に言うと、「IPを持っている」だけでは不足するケースがあり、主に次の3点が落とし穴になります。
- AD上でDHCPサーバーとして承認されていない（承認されていないDHCPは配布できない）
- DHCPのバインド対象から外れている（複数NIC/複数IP環境で発生しやすい）
- ホットスタンバイの役割が「旧BのIPを持つ側＝通常時に配布する側」になっていない
DHCPサーバーの再承認は必要か
新規に構築したサーバーCは、Active Directory ドメイン環境では基本的にDHCPサーバーとして承認（Authorize）が必要です。承認されていないDHCPサーバーは、安全対策としてクライアントへリースを配布できません。
実装上は、次の考え方で整理すると安全です。
- サーバーA：既に承認済みならそのまま
- サーバーC：新規承認が必要
- サーバーB：退役させるなら、承認一覧からも整理（削除）しておくと運用が明確
現場で起きやすいポイント：第2IP追加と承認が噛み合わないケース
検証ベースの話として、サーバーCの既存NICに旧BのIPを第2IPとして追加したところ、DHCPサーバーの承認（再承認）がうまく行えないケースが報告されています。一方で、サーバーCに新しいNICを追加し、そのNICに旧BのIPを設定したところ、問題なく承認できた、という結果もあります。
環境依存要素（NICのバインド順、DNS登録、IPの優先度、承認時の到達性チェックなど）が絡むため「必ず失敗する」とは言い切れませんが、失敗したときの切り分けコストが高いのも事実です。そのため、実務では旧IPを引き継ぐ用途の専用NICを用意する設計が扱いやすく、戻しやすいです。
旧BのIPを引き継ぐ方法は2通り
旧BのIPをサーバーCに持たせる方法は大きく2パターンあります。運用・切り戻し・トラブル時の切り分けを考えると、最終的にどちらを採るかで安定性が変わります。
| 方式 | 概要 | メリット | 注意点 |
|---|---|---|---|
| 同一NICに第2IPとして追加 | 既存NICに旧BのIPを追加 | 構成がシンプル／NIC追加不要 | 承認やバインド、DNS登録、優先度の影響で想定外の挙動になることがある |
| 別NICに旧BのIPを割り当て | 旧BのIP用にNICを追加して割り当て | 役割が分離され切り分けしやすい／承認トラブル時の回避策になりやすい | マルチホーム構成になるため、ゲートウェイ設定やDNS登録を慎重に扱う必要がある |
別NIC方式を採る場合の鉄則
- 旧BのIP用NICにはデフォルトゲートウェイを設定しない（ルーティングが崩れる典型）
- 不要なDNSレコード登録を避けるため、必要に応じて「この接続のアドレスをDNSに登録する」を無効化
- DHCPが提供すべきネットワークだけにバインドされているか確認
推奨の実装手順
ここでは「IP helper を変更しない」ことを最優先に、A↔BをA↔Cに置き換え、最後に旧BのIPをCへ引き継ぐ流れを、手戻りが少ない順に整理します。実際の作業はメンテナンス時間を確保し、関係者周知とロールバック手順を用意した上で実施してください。
事前準備で必ずやること
| チェック項目 | 理由 | 確認方法の例 |
|---|---|---|
| スコープ／予約／ポリシー／オプションの棚卸し | 移行漏れを防ぐ | DHCP MMC、Get-DhcpServerv4Scope |
| フェールオーバー状態の確認 | 同期不良のまま移行すると事故る | Get-DhcpServerv4Failover で状態を確認 |
| DHCPデータベースのバックアップ | 最悪時の復旧手段 | DHCP MMCのバックアップ、またはサーバーバックアップ |
| IP helper 宛先の実態調査 | 本当に旧BのIPだけか、複数宛先かで設計が変わる | ネットワーク機器設定（ip helper-address等） |
サーバーCの構築
- サーバーCをドメイン参加させ、時刻同期（NTP）と名前解決（DNS）が正常であることを確認します。
- DHCPロールを追加します。GUIでもPowerShellでも構いません。
- Windowsファイアウォールやセキュリティ製品で、DHCP（UDP 67/68）や管理系通信が遮断されていないか確認します。
# DHCPロールのインストール例
Install-WindowsFeature -Name DHCP -IncludeManagementToolsA↔Bのフェールオーバーを解除
スコープは1つのフェールオーバー関係にしか属せないため、A↔Cを作る前にA↔Bを解除します。解除しても、DHCPサービス自体が即停止するわけではありませんが、運用上は「どちらが配布しているか」を明確にしてから進めるのが安全です。
# フェールオーバー関係の確認
Get-DhcpServerv4Failover
# 例：既存フェールオーバー関係の削除（名称は環境に合わせる）
Remove-DhcpServerv4Failover -Name "Failover-AB"A↔Cで新しいフェールオーバーを作成して同期
新しいフェールオーバーを作る際は、次の観点で決めると失敗しにくいです。
- 既存がホットスタンバイなら、まずは同じ方式で踏襲して変更点を最小化する
- IP helper が旧BのIP「のみ」を指しているなら、旧BのIPを持つCを通常時に配布する側に寄せる（役割を逆転させる/負荷分散にする等を検討）
- 切り替え当日は、スコープが同期されていることをコマンドとGUIの両方で確認する
# 例：A側でCをパートナーにしてフェールオーバーを構成（スコープ単位）
# 実際のScopeIdやパートナー名は環境に合わせてください
Add-DhcpServerv4Failover -Name "Failover-AC" `
-PartnerServer "dhcp-c.example.local" `
-ScopeId 10.10.0.0 `
-MaxClientLeadTime 01:00:00 `
-StateSwitchInterval 00:45:00 `
-SharedSecret "ChangeThisSecret"旧サーバーBをネットワークから外してIPを引き継ぐ
旧BのIPをCへ移す作業で最も重要なのは、IPアドレスの重複を絶対に起こさないことです。同一IPが2台で生きていると、DHCPに限らずARP解決が揺れて通信が不安定になり、原因追跡が非常に困難になります。
- サーバーBのDHCPロール停止、またはサーバーBをシャットダウンします（確実性優先ならシャットダウンが無難）。
- ネットワーク上からBが消えたことを確認します（Ping応答がない、ARPテーブルから消える等）。
- サーバーCに旧BのIPを設定します。推奨は別NICに割り当てです。
別NIC方式の例として、サーバーCに新NICを追加し、旧BのIPをそのNICへ設定します。NIC追加が難しい場合は第2IPでも実現可能ですが、後述のとおり承認やバインドのトラブルが出た場合に逃げ道が減る点は理解しておきましょう。
Active Directory 上でサーバーCを承認する
DHCP承認は、DHCP MMC（DHCP管理ツール）からでも、PowerShellからでも行えます。権限不足で失敗することがあるため、実施アカウントが適切か（Enterprise Admins相当、または委任）も含めて準備してください。
# 承認済みDHCPサーバーの一覧
Get-DhcpServerInDC
# サーバーCを承認（DNS名とIPは環境に合わせる）
Add-DhcpServerInDC -DnsName "dhcp-c.example.local" -IpAddress 192.0.2.10
# 旧サーバーBを整理（必要に応じて）
Remove-DhcpServerInDC -DnsName "dhcp-b.example.local" -IpAddress 192.0.2.20承認後は、サーバーCのDHCP Serverサービスを再起動し、イベントログ（DHCP-Server／System）にエラーが出ていないことを確認します。
DHCPが旧BのIPで確実に応答するための設定確認
「IPを持たせたのに配布されない」場合、原因の多くはDHCPのバインド設定（Bindings）です。複数NICや複数IPを持つサーバーでは、DHCPが応答すべきインターフェースが無効になっていることがあります。
- DHCP管理ツールで、IPv4のプロパティからバインドを確認し、旧BのIPが割り当たっているNICが有効になっているか確認します。
- セキュリティポリシーで「特定のインターフェースではDHCPを提供しない」運用をしている場合は、変更手順に組み込みます。
動作確認の手順
切り替え直後は、サーバー側／ネットワーク側／クライアント側の3方向から確認すると、見落としが減ります。
| 観点 | 確認ポイント | 具体例 |
|---|---|---|
| サーバーC | リースが増えているか、エラーがないか | Get-DhcpServerv4Statistics、イベントログ |
| ネットワーク機器 | リレーが旧BのIPへ転送しているか | DHCP Snoopingログ、リレー設定の確認 |
| クライアント | 更新で正しく取得できるか | ipconfig /renew、取得したDNS/ゲートウェイも確認 |
:: クライアント側（Windows）の更新例
ipconfig /release
ipconfig /renewよくあるトラブルと対処
| 症状 | ありがちな原因 | 対処の方向性 |
|---|---|---|
| クライアントがIPを取得できない | DHCP未承認／バインド無効／UDP 67/68遮断 | AD承認の確認、Bindings確認、FW/ACL確認 |
| 旧BのIPを設定したら通信が不安定 | IP重複、ARPキャッシュが残っている | Bの完全停止、ARPクリア、一定時間待って再試験 |
| フェールオーバーが通信断になる | 名前解決、時刻ずれ、FWで同期通信が遮断 | DNS/時刻/NTP、パートナー間通信の許可を見直す |
| 第2IP方式で承認がうまくいかない | NIC/バインド順、到達性チェック、DNS登録の影響など | 別NIC方式へ切り替え、承認手順の再実施 |
| 意図しないネットワークへDHCPを配布してしまう | マルチホームでバインド対象が広がっている | Bindingsを絞る、不要NICはDHCP提供を無効化 |
運用で効く小さな工夫
- 切り替え当日は「DHCPが配布する側」を一時的に単独化し、挙動が安定してから冗長化を戻すと原因切り分けが楽です。
- 監視（死活・リース枯渇・フェールオーバー状態）を用意し、障害時の初動を手順化します。
- IP helper の宛先が増やせる機器なら、将来的にAとCの両方を設定しておくと、特定IPに依存しない設計になります（変更コストが許すタイミングで検討）。
- 旧BのIPを引き継いだ後は、ドキュメント（ネットワーク図、サーバー一覧、運用手順、監視設定）を更新し、「IPはBのものだが実体はC」という状態が属人化しないようにします。
まとめ
サーバーAと新サーバーCでDHCPフェールオーバーを組み、サーバーCが旧サーバーBのIPを引き継ぐ方針は、IP helper の大量変更を避けつつ移行できる現実的な手段です。ポイントは、(1)旧BのIPを確実にCへ移す（重複させない）、(2)A↔Cでスコープ同期を完了させる、(3)サーバーCをAD上で承認し、DHCPのバインドを確認する、の3つです。
特に、旧BのIPを同一NICの第2IPとして追加すると承認や挙動で詰まるケースがあるため、実務上は別NICに旧BのIPを割り当てる構成を選ぶと、移行成功率と切り戻し容易性が上がります。
コメント