「やっちまったゼ」
ひとことで言えば、そんな印象のトラブルシューティングを経験しました。
一部始終を実況中継しましょう。
コントロールパネルの[システム]からクライアントコンピュータからドメイン名を指定して[OK]ボタンをポチッとするのが、
Active Directoryドメインに参加する、一般的な方法だと思います。
■画面1
そして、このダイアログ(画面2)が出てくれば、ドメインコントローラーへの接続は成功、
失敗すればDNSサーバーからSRVレコードをうまく引っ張ってこれてない、というのが定石の考え方ですね。
■画面2
ところが、私が経験したのは画面2でユーザー名とパスワードを入れて、ポチッとすると
出てきたのが画面3。
■画面3
接続できないのであれば、そもそも画面2のダイアログは出てこないはずなのに、
どういうわけか、接続できませんと言ってきます。
そこで、WireSharkを使って、一連の動作で行われるパケットをキャプチャしてみることにしました。
■画面4
まず、画面1でドメイン名を指定して[OK]を押すと、クライアントコンピュータ(192.168.10.12)から
DNS兼ドメインコントローラー(192.168.10.10)へDNSクエリのパケットが送信されています(No51)。
そして、それに対する応答が帰ってきています(No54)。
これを見る限り、DNS兼ドメインコントローラーにはきちんと接続できていますし、DNSサーバーの構成にも
問題がないことがわかりますね。
そして、問題は画面2で[OK]を押した後のパケットの流れ。
画面5
いくつかのパケットでドメインコントローラー(192.168.10.10)と通信できていない様子が確認できるのですが、
典型的なのはパケットNo289。ハイライトしてあるので、No289のパケットの詳細は中段、下段でも確認できますが、
TCP445のパケットをクライアント(192.168.10.12)からドメインコントローラー(192.168.10.10)に向けて
送信しています。そして、このパケットはTCPの最初の通信ですので、3ウェイ ハンドシェイクのSYNパケットとして
送信されています。
ところが、3ウェイ ハンドシェイクのSYNパケットを送ったら、相手からACK/SYNパケットが帰ってくるはずなのに
それがありません(No289以降)。
ここまでのことをまとめてみると、次のことがわかりました。
・ ドメインコントローラーとはDNS(UDP53)の通信はできた
・ ドメインコントローラーとはTCP445の通信はできない
このように同じコンピューターとの通信なのに、ポート番号によって通信できたり、できなかったり、
というのはファイアウォールに違いない！ということで、ファイアウォールの設定を確認していたら、気がついたのです。
「このドメインコントローラーは仮想環境だ！」ということに。
仮想環境(今回私が使ったのはVMware Workstation)だと、
ネットワーク上のコンピューターと、仮想マシン(ゲストOS)の間で通信するためには、
ホストOSのファイアウォールとゲストOSのファイアウォールの両方でパケットの受信を許可するようになっていないと、
ブロックされてしまうのです。
そして今回の私はホストOSで、UDP53→許可、TCP445→拒否
だったので、以上のような現象が起きたのです。
「ああ、やっちまったゼ」
この問題を解決するのに無駄に時間を使ってしまった、、と自己嫌悪に陥ったのでした。
追伸
「UDP53→許可、TCP445→拒否」というルールになっている私のテストマシン(Win7)も何か不思議な感じですね。
