Windows Server 2008で提供されているDHCPサーバーではMACアドレスによるフィルタリングはサポートされていません。これはNTの時代から変わっていませんね。

実際問題、私がSEをしていた頃に登録したMACアドレスにしかIPアドレスの配布をしたくないというお客様がいて、サードパーティ製のDHCPサーバーを購入して対応した記憶があります。

先日Windows Server 使い倒し塾のブログを見ていたら、なんとフリーのツールを使用することによってWindows Server 2003以降（2008も含む）のDHCPサーバーでMACアドレスフィルタリングを使用できるようなんです。

そのツールとはCallout DLLというものです。Microsoft Windows DHCP Team Blogにて紹介がされています。

そして、さらにリンクがあり、Connect The Worldをクリックします。

そして一番下にDownloadのリンクがありますのでそこからツールをダウンロードします。

そして32ビットと64ビット版がありますので使用する方をダウンロードしてDHCPサーバーに対してインストールします。見た目は全くかわりませんね～

変わる場所はレジストリになります。

HKEY_LOCAL_MACHINESystemCurrentControlSetServicesDHCPServerParameters

この中のパラメータがCallOut DLLに影響を及ぼすようです。

• CalloutDlls：ツールのパス
• CalloutEnabled：1の場合は起動で、0にすればロードされません
• CalloutErrorLogFile：ログファイルのパス
• CalloutInfoLogFile：情報ファイルのパス
• CalloutMACAddressListFile：これが肝のアクセス制御ファイルのパス

デフォルトではc:WindowsSystem32dhcp 配下に設定されていることがregeditから確認できます。

そして実際の操作に関しては次の2通りがあります。

• 許可リスト：DHCPを使用する全ての端末MACを登録する
• 拒否リスト：DHCPを使用させない端末のMACを登録する

このリストの記載方法は次の通り

#MACList.txt
MAC_ACTION = {ALLOW / DENY}
#List of MAC Addresses:
000a0c0d1254 #lab-server1
000d0c4a6723 #lab-server2
…
…

これはREADMEに記載してあるものなんですが、先頭に＃があるのはコメントですね。そしてMAC_ACTIONに許可もしくは拒否を設定する。そこでちょっとはまったのが、その書き方なんです。これって

MAC_ACTION = ALLOW

でうまくいくと思ったんですが、何度やってもうまくいきませんでした。試しに

MAC_ACTION = {ALLOW}

としたらうまくいきました。

あとは、クライアントのMACアドレスを登録すればうまく動きます。いや～、これはこれで便利ですね。

まとめ

今までこのような機能のニーズはあったにも関わらず、マイクロソフトのDHCPではサポートしていませんでした。が、Windows Server 2008 R2 のDHCPサーバーはMACアドレスフィルターをサポートするようです。

セキュリティで保護された動的更新

DNSの動的更新のセキュリティは３つあります

• なし
• 非セキュリティ保護およびセキュリティ保護
• セキュリティ保護のみ

ここで通常はセキュリティ保護のみに設定します。こうすれば、ADに登録されたオブジェクトからしか動的更新を受け付けることはありません。

最も端的な例としては、外部のユーザーがドメインネットワーク接続しても動的更新によってDNSにアドレスの登録は行うことができないということです。

では動的更新のセキュリティ設定が「セキュリティ保護のみ」に設定されていてDHCPの冗長構成を考えます。ふ～、やっと本題に入れます。

同一セグメントに複数台のDHCPがあると仮定します。ここではDHCP1とDHCP2があります。そしてDHCPの動的更新も行います。ここでDHCP1で登録されたクライアントのレコードがあります。これをClient1とします。このClient1はDHCP1によって登録されたので、このレコードの所有者はDHCP1ということになります。ここで、DHCP1がダウンしてDHCP2のみでの運用となります。ここでClient1が更新を行います。DHCP2はDNSに登録されているClient1の更新をかけますが、所有者がDHCP1のためエラーとなります。

これは問題ですね～

まあ、通常ではDHCPが登録するのはPTRレコードになるので気にすることはないかもしれませんが、DHCPがA,PTRレコード両方を登録する設定になっていたらこれは大問題になります。

そこでADのグループには「DNSUpdateProxy」というグループが用意されています。

この「DNSUpdateProxy」に各DHCPサーバーのコンピューターオブジェクトを登録することにより所有者の問題は解決されます。が、DNSの設定で動的更新のセキュリティ設定が「セキュリティ保護のみ」だと登録がうまくいきません。

それはDHCP サーバーが DnsUpdateProxy グループのメンバである場合、DHCP サーバーによって登録される DNS ドメイン名はセキュリティで保護されないからです。

そのためにはどうするか？

DNSの動的更新専用アカウントを作成して、DHCPサーバーに設定すれば解決できます。

このページの資格情報をクリックして設定します。

まとめ

DHCPの冗長構成を行う場合は

• DNSUpdateProxyというグループにDHCPのコンピューターオブジェクトを登録する
• DNSの動的更新専用アカウントを作成して、DHCPサーバーに設定する

ということになりますね。

DHCPサーバーからDNSの動的更新を行う場合考慮しなくてはいけないポイントがあります。

まずは、DNSの動的更新とはどのような動作なのかを理解する必要があります。

以前はDNSのレコードは管理者が登録するものでした。しかし、昨今の環境ではクライアントの名前解決においてもDNSを使用することが一般的になることによって管理者がクライアントのレコードを登録するというのは難しくなってきました。またDHCPを使用している場合動的にIPアドレスが変更されるため尚更難しいということになります。

そこで考え出されたのがDNSの動的更新になります。

まず、クライアントの一般的な動作から考えます。

前提としてTCP/IPの詳細設定において「□この接続のアドレスをDNSに登録する」にチェックが入っていることになります。デフォルトではチェックが入っているので通常は気にしませんね。

ここで２つのパターンがあります。それは静的IPアドレスと動的IPアドレスの場合です。

静的IPアドレスの場合はクライアントが直接DNSサーバーにAレコードとPTRレコードの登録を行います。

動的IPアドレスの場合（DHCPからIPアドレスを取得した場合）

ここの動作はちょっと解説が必要になります。まず、前提としてDHCPのDNSタブの設定が絡んでくるんです。

デフォルトの状態では「以下の設定に基づいて、DNS動的更新を有効にする」にチェックが入っています。そして「DHCPクライアントから要求があったときのみDNSのAレコードおよびPTRレコードを動的に更新する」にチェックが入っています。

さて、ここでDHCPクライアントから要求～とありますがどういうことかというと、DHCP オプションであるクライアント FQDN オプション (オプション 81) を考慮する必要があるんです。

Windows Server 2003 で DNS 動的更新を構成する方法

以下参考リンクより抜粋～～

このオプションを使用すると、クライアントから FQDN を DHCPREQUEST パケットで DHCP サーバーに送信することができます。これで、クライアントは必要なサービス レベルを DHCP サーバーに通知できます。

FQDN オプションには、次の 6 つのフィールドがあります。

• Code
  このオプションのコード (81) を指定します。
• Len
  このオプションの長さ (4 以上) を指定します。
• Flags
  サービスの種類を指定します。
  • 0
    クライアントが “A” (ホスト) レコードを登録します。
  • 1
    クライアントが DHCP に “A” (ホスト) レコードを登録させます。
  • 3
    クライアントの要求にかかわらず、DHCP が “A” (ホスト) レコードを登録します。
• RCODE1
  サーバーがクライアントに送信する応答コードを指定します。
• RCODE2
  RCODE1 の追加記述を指定します。
• Domain Name
  クライアントの FQDN を指定します。

クライアントがリソース レコードを DNS に登録するよう要求した場合、クライアントは、RFC (Request for Comments) 2136 に従って、動的 UPDATE 要求を生成します。すると、DHCP サーバーが PTR (ポインタ) レコードを登録します。
このオプション 81 が、Windows Server 2003、Microsoft Windows 2000、または Microsoft Windows XP を実行する DHCP が利用できるコンピュータなどの有効な DHCP クライアントによって発行されたものであるとします。この場合、Windows Server 2003 ベースの DHCP サーバーによってオプションが処理および解釈されて、サーバーがクライアントのために更新をどのように開始するかが判断されます。

ここまで～～

ここで重要なのはクライアントからのオプション81のデフォルトはFlagsが0ということです。通常この設定を変えることはありません。

では話は戻って、DHCPサーバーの設定は「DHCPクライアントから要求があったときのみDNSのAレコードおよびPTRレコードを動的に更新する」になっています。そしてクライアントはFlagsが0なのでクライアントが “A” (ホスト) レコードを登録します。

ということで、デフォルトの動作ではクライアントがAレコード、DHCPサーバーがPTRレコードを登録するということになります。

そして、DHCPサーバーの設定を「DNSのAおよびPTRレコードを常に動的に更新する」にチェックを入れると、DHCPサーバーがクライアントのA、PTRレコードを登録するという動作になります。

ここで冗長構成の動作を考えると問題になることがあります。

それは次回に・・・

前回は同一セグメントにDHCPサーバーを複数台おいて冗長構成するお話をしましたが、こんな構成もありますね～

1台は同一セグメントにDHCPサーバーをたてて、それがダウンしたらリレーエージェントで別セグメントにあるDHCPサーバーに飛ばす方法。別セグメントには元のセグメントと同じアドレス範囲のスコープを設定しておく。クライアントがDHCPに問い合わせする際にアドレス情報を持っているので適切なスコープからアドレスをもらうことができます。

他にはこんな感じ

クライアントが存在するセグメントにはDHCPサーバーはなく、リレーエージェントを設置するか、ルーターにDHCPパケットを転送させるかしてDHCPサーバーが存在するセグメントにパケットを飛ばす方法。

なんか、こっちのほうがいいかも

そもそも、ネットワーク設計をする際にはセグメントは小さいほうが効率よくネットワークを使用することができます。ですのでL3スイッチを使用して社内ネットワークを分割している企業は多いはず。その際に各セグメントにDHCPサーバーを置くのは大変だし非効率的になります。この構成を使えば複数のセグメントのDHCPとして使用できるし、冗長化にもなる。

ということで、私の考える冗長構成のベストプラクティスは後者になります。

さて、かなり枯れた技術としてDHCPサービスがあります。このDHCPサービスですが、私の今までの経験ではDHCPデータベースが壊れるという事態に遭遇したことはありません。かなり安定しているサービスではないでしょうか？

そうはいってもDHCPサーバーを提供しているサーバーがダウンすることはあります。

そのような事態に対応するにはDHCPの冗長構成を考慮する必要があります。

ではDHCPの冗長構成を考える場合どのような構成があるのでしょうか？思い浮かぶ所で３つの方法があります。

• スコープの分割
• DHCPのクラスタ構成
• コールドサーバーの用意

でしょうか？

DHCPのクラスタ構成ですが、コストが高すぎてあまり現実的ではありませんね。そして、コールドサーバーの用意ですが運用中のDHCPサーバーがダウンしたら用意しておいたサーバーにDHCPサービスをインストールして運用する。これはこれでありですが、若干の問題を抱えます。それは今まで配布していたアドレス情報を持っていないのでIPアドレスのバッティングが発生する可能性があるということです。しかし、これはDHCPサーバーの設定画面で「検出の試行回数」の項目を２あたりにすることによって回避は可能になります。

この「検出の試行回数」を入力する数字によって、DHCPサーバーがクライアントにIPアドレスをリースする前に、そのアドレスでpingを使用して既存端末が存在するかを確認します。この数字は２を超えない値が推奨されています。

そして最も現実的な冗長構成としてはスコープの分割があります。

これは複数のサーバーをDHCPサーバーとして構成します。その際のスコープ構成として除外範囲を利用します。

アドレス範囲は同じですがそれぞれ除外範囲はことなるのでバッティングすることはありません。

ただし注意点としては予約をしている際にはすべてのDHCPサーバーで同じ設定をする必要があります。

次回はDHCPとDNSとの連携について考えてみます。