公開DNSが動いてもActive Directoryが見つかるとは限らない

VPNが接続し、ブラウザが公開サイトを開き、それでもノート PC はドメインにサインインできない。ふつうの結論は、名前が解決するので DNS は問題ないというものだ。問題あり、その理由は、ブラウザでの試験がドメイン参加クライアントに必要な一連の処理のうち一度の問い合わせだけを試すからだ。ドメイン検出はまずサービス レコードを求め、次にそのレコードが示すコントローラーのアドレスを求め、最後にそれらのコントローラーが待ち受けるポートへのルートを求める。公開された応答はこれらの手順を一つも満たさない。

神話：名前が解決するので DNS は完了している

公開サイトが解決するのは、あるリゾルバーが公開ゾーンの名前に対して A または AAAA の問い合わせを一つ答えた、というだけだ。Active Directory は同じプロトコルを、ドメインのサービスがどこにあり、このクライアントがどのコントローラーを使うべきかという別の問いに使う。その問いはドメイン名を冠したゾーン配下の SRV レコードとして表現され、再帰的な公開リゾルバーがそれらを保持する理由はない。

レコードが無い場合、リゾルバーは否定応答を返すが、それは障害ではなく正当な DNS 応答である。その後クライアントはキャッシュされたコントローラー情報があればそれに戻るので、デスクトップは何時間も正常に見え、再起動やパスワード変更のあとに失敗する。

ドメイン クライアントが実際に問い合わせる順序

corp.example のようなドメインでは、汎用のロケーター問い合わせは _ldap._tcp.dc._msdcs.corp.example だ。SRV 応答は候補となるコントローラーとそのポートを示し、次にクライアントは接続を開く前にそれらのホスト名のアドレス レコードを必要とする。サイトを考慮した検出はサイト サブドメイン配下の問い合わせを追加し、その応答がどのコントローラーを優先するかを決め、どれが必須かではない。

nltest /dsgetdc:corp.example
Resolve-DnsName -Type SRV _ldap._tcp.dc._msdcs.corp.example

その順序で連鎖をたどり、問題が起きているネットワークから始める。到達できないアドレスに解決するホスト名はルーティングの失敗であり、DNS の失敗ではない。到達可能なコントローラーでロケーター レコードが欠けている場合は DNS の失敗であり、ルーティングの失敗ではない。どちらも似た利用者の不満を生むが、修理はまったく異なる。

公開リゾルバーが応答するのになぜサインインが壊れるのか

アダプターがクライアントに公開リゾルバーを渡すと、公開名は動き、内部の名前空間は動かない。公開リゾルバーを二台目に加えても、どちらもゾーンを保持していないので助けにならない。また「内部優先、公開は二番目」というよくある一覧もドメインごとの規則としては働かず、最初のサーバーの否定応答は正当な応答なので、応答が空だったというだけでクライアントが二台目のサーバーを再試行することはない。

内部リゾルバーを二台運用する場合、どちらも AD の名前空間を保持し、クライアントの現在のネットワークから到達できなければならない。分割トンネルの設計が壊すのはまさにこの点で、VPN がトンネルのサブネットを運んでも、内部リゾルバーがトンネルのルーティングしないプレフィックス上にあれば、問い合わせは答えられないリゾルバーへ出ていく。

Windows は名前解決ポリシーも適用し、特定の名前空間を特定のサーバーへ向けられるが、アダプターが表示する DNS アドレスがすべてではない。そのポリシーを変えずにアダプターの一覧を変えても実際の構成は変わらないままで、適用したように見える修正が効果を持たない理由はそこにある。

トンネルの DNS とそのルートを一致させておく

リゾルバーを配布してもそれを含むプレフィックスを配布しない VPN プロファイルはクライアントが到達できないリゾルバーを作り、プレフィックスを配布してもリゾルバーを配布しないプロファイルはクライアントをローカルのリゾルバーに問い合わせさせる。この組を一つの構成項目として扱い、プロファイルを変更するたびに両方を確認するのは、配布順の入れ替えや新しい分割トンネル ポリシーが両者を切り離すことがあるからだ。

クライアントが配布された設定をどう扱うかも確認する。DNS サーバーをトンネル インターフェイスにだけ適用し、物理アダプターのリゾルバーをそのまま残すクライアントもあり、どちらが勝つかはインターフェイスのメトリックと問い合わせる名前に依存する。物理アダプターを無効にしたときだけ内部の応答が返るなら、直すべきはその仕組みであり、ドメインのレコードではない。

検出の呼び出しと一度の実操作で受け入れる

役に立つ受け入れ試験は、ロケーター問い合わせを実行し、そのあとにディレクトリに基づく共有を開く、チケットを要求するといった実際の認証済み操作を一度行う。VPN の切り替え前と切り替え後に、同じマシンで、途中で再起動せずに行う。キャッシュされた資格情報とすでに開いたセッションは壊れた経路を喜んで健全に見せるので、デスクトップへのサインイン成功は試験ではない。

Microsoft の DNS クライアントに関する推奨事項 は、内部の名前空間を解決することと公開の問い合わせを上流へ転送することの間に同じ線を引いており、VPN を導入するときに保つべき配置はこれだ。

障害が「失敗」ではなく「遅い」だけなら、遅延を診断から切り離しておく。検出中のタイムアウトは、到達できないコントローラー、遮断されたポート、応答の遅いリゾルバーのいずれからも起こり得て、待っただけではどれも証明されない。リゾルバーの設定を変える前に、実際の問い合わせとその応答、接続の試行を記録する。