VPNクライアントにおけるADサイトマッピングとドメインコントローラ固定の比較

VPNプール上のリモートアクセスクライアントが、地球の反対側にあるドメインコントローラと通信してしまうことがあります。これを直す方法は二つあります。プールを、正しいコントローラを持つサイトに結び付けたActive Directoryのサブネットとして記述するか、クライアントやアプリケーションを特定のコントローラに固定するかです。前者はDC Locatorが判断に使えるトポロジの表明です。後者はトポロジを完全に無視するアプリ単位の上書きです。両者のコストは異なり、目先の速いほうに手を伸ばすことが、結局ディレクトリ担当チームが両方を維持することになる原因です。

それぞれの方法が実際に変えるもの

サブネットオブジェクトは、あるアドレス範囲がどのサイトに属するかを示すディレクトリのレコードです。Active Directoryモジュールと既存のサイトがあれば、この操作は事前確認できるほど小さいものです。

New-ADReplicationSubnet -Name "10.90.0.0/24" -Site "Remote-Access-Hub" -WhatIf
Get-ADReplicationSubnet -Filter * | Select-Object Name,Site

-WhatIf はディレクトリへの書き込みを事前に表示します。オブジェクトは作成せず、その範囲のクライアントが何かに到達できるかも検証しません。しかし人々が期待するのはまさにその部分です。DC Locatorはサービスレコードを解決するときにサイトモデルを読むため、正確なサブネットオブジェクトはクライアントに提示される内容を変えます。

固定は別の層で働きます。アプリの設定に書かれた固定のコントローラ名、ホストを含むLDAP文字列、優先サーバを指定するレジストリ値は、いずれも検出を経路から外します。アプリケーションは誰かが設定を変えるまでそのコントローラと通信し、障害時の切り替えはそのアプリが実装しているもの次第です。

サブネットマッピングが勝つ場面

プールをマッピングすると、DC Locatorを使うすべてのクライアントに対してネットワーク上の位置を一度だけ記述できます。プールが一つの/24から三つに増えても、モデルの変更はアプリの一覧ではなく二つか三つのオブジェクトで済みます。これが利点のすべてであり、クライアントの母集団が自分の管理下にない場合には大きな利点になります。

落とし穴は、オブジェクトがコントローラの実際に見るアドレスと一致しなければならないことです。VPNゲートウェイがすべてのクライアントをハブのアドレスに変換しているなら、変換前のプールを追加しても、どのコントローラも観測しないネットワーク位置を記述したことになります。設計がクライアントの送信元アドレスを保持するかどうかを早めに決め、保持しない場合はVPNサーバに設定したプールではなく変換後の範囲をマッピングしてください。

二つ目の限界として、サイトモデルはあくまで優先順位とトポロジの表明です。コントローラを到達可能にはせず、ユーザーに何かを与えるものでもありません。到達性はルートとファイアウォールポリシーが担い、認可はアカウントポリシーが担います。

固定が勝つ場面

検出が機能しない場合、固定が正解です。変更できない名前でコントローラを解決する古いアプリ、コントローラのアドレスを一つだけ許可するフィルタ、コントローラがアプリ設計の一部になっている固定のサーバ群などです。そうした場合の固定は近道ではなく、実際の制約を文書化したものです。

そのコストはマッピングの逆です。固定した名前はプールに追従せず、アプリが方法を知らなければ障害時に切り替わらず、台帳の点検なしにコントローラの改名や廃止を乗り越えられません。さらにトポロジの問題を隠します。固定したクライアントはどれも健全に見える一方で、サイトモデルは静かに腐っていくからです。

ドメインの通常のアドレスレコードを一つの優先サーバに置き換えるのは第三の選択肢ではありません。通常の検出セットを期待するすべての利用者を壊し、しかもディレクトリを意識したクライアントがサイトをどう選ぶかは制御できません。

三つの条件で選ぶ

この順に問うと、たいてい答えは自然に決まります。第一に、そのアプリはそもそもDC Locatorを使うのか、それとも既にコントローラのアドレスを持っているのか。第二に、コントローラが見るのはプールのアドレスか、変換後のアドレスか。第三に、プールはどれくらいの頻度で変わり、固定を更新すべき箇所はいくつあるか。

ディレクトリを意識したアプリと、送信元を保持するルーティングと、変化するプール。この組み合わせならサブネットをマッピングします。検出できないアプリ、あるいは一つのアドレスしか通さないフィルタなら、固定して理由を書き留めます。それ以外は、別の上書きを足すのではなくトポロジを直す案件です。

VPNクライアントから検証し、契約は分けて保つ

既にサイト内にあるLANのワークステーションではなく、実際のリモート経路から試験します。意味を持つのはクライアント自身の見え方だけです。

nltest /dsgetsite
nltest /dsgetdc:corp.example.com /force
echo %LOGONSERVER%

報告されたサイトがマッピングしたサイトなら、オブジェクトは一致しています。クライアントがサイトを報告しない場合、提示しているアドレスはどのサブネットオブジェクトにも入っていません。これは通常、変換か古いプレフィックスを意味します。そのうえで、マッピングが失敗したと決めつける前に、選ばれたコントローラが意図したものかを確認してください。クライアントは検出結果をキャッシュし、障害時の切り替えが正当に別のコントローラを選ぶことがあるからです。

三つの契約を一つの文書にまとめてください。プールとそのサブネットオブジェクト、VPN経路から到達できるコントローラ、そしてサインインしたユーザーが何をしてよいかを決めるポリシーです。サイトはファイアウォールの規則でも封じ込めの境界でもありません。マッピング、ルート、文書化された代替案が一緒に動かなければ、次のプール変更はリモートユーザーをディレクトリのネットワークモデルから静かに切り離します。