今回は「インターネット」ではなくて、「イントラネット」に繋がらないというケースについて書いてみます。
今、Active Directoryで構成されたWindowsネットワーク(ドメイン名sample.lcoal)があるとして、そこにintraという名前のメンバサーバーがあり、そこでイントラサイトが稼働しているとしましょう。このときのURLは何になるでしょうか?
- http://intra/
- http://intra.sample.local/
さて、どちらが正解でしょうか?
正解は、「どちらも正解」です。
「なんだ、それは」と思うかもしれませんが、これがなかなか奥深い話もあったりします。たとえば1のhttp://intra/というアドレスを使っている場合。クライアントの設定によってはつながったりつながらなかったりします。繋がる場合でも、名前解決の方法が異なったりします。ちょっと詳しく見てみましょう。
名前解決の手段は何か?
まず、http://intra/というURLですが、実際にはintraというホストのIPアドレスを知らなくてはいけません。最終的にはTCP/IPで接続するわけですから。
名前解決の手段としては様々なものがある、という話は以前しました。
- 参考：[NETBIOS名とホスト名の違い](https://windowsadmin.ebisuda.net/2009/02/10/netbios%e5%90%8d%e3%81%a8%e3%83%9b%e3%82%b9%e3%83%88%e5%90%8d%e3%81%ae%e9%81%95%e3%81%84/)
この場合intraを名前解決する方法は以下のパターンがあるわけです。
- hostsファイル(ホスト名)
- DNS(ホスト名)
- lmhostsファイル(NETBIOS名)
- WINS(NETBIOS名)
- ブロードキャスト(NETBIOS名)
で、厄介なのが2に関してです。
ドメインサフィックス
DNSとして考えたときに「intra.」なんていうホスト名はあり得ないわけです。本来は「intra.sample.local」です。なので「intra」を裏で「intra.sample.local」に変更してくれている仕組みが存在するわけです。
マイネットワーク→プロパティ→(対象NIC)→プロパティ→インターネットプロトコル(TCP/IP)→プロパティ→詳細設定→DNSタブ (なんてわかりづらい所にあるんでしょう…)
- 「プライマリおよび接続専用のDNSサフィックスを追加する」
- 「プライマリDNSサフィックスの親サフィックスを追加する」
- 「以下のDNSサフィックスを順に追加する」
- 「この接続のDNSサフィックス」
そしてもう一か所あります。
マイコンピュータ→プロパティ→コンピュータ名タブ→変更→詳細 (なんてわかりづらい所にあるんでしょう…)
- 「このコンピューターのプライマリDNSサフィックス」
- 「ドメインのメンバシップが変更されるときにプライマリDNSサフィックスを変更する」
これらの設定が"仕組み"になります。
勝手にドメインサフィックスが追加される理由
通常は以下のような流れで、勝手に適切なドメインサフィックスが追加されるようになっています。
- Active Directoryに参加する
- 「ドメインのメンバシップが変更されるときにプライマリDNSサフィックスを変更する」が既定で有効であるため、ドメイン名(sample.local)が「このコンピューターのプライマリDNSサフィックス」として設定される
- DNSを使った「intra」の名前解決の際に「プライマリおよび接続専用のDNSサフィックスを追加する」および「プライマリDNSサフィックスの親サフィックスを追加する」が有効であるので「intra.」だけではなくて「intra.sample.local」も検索される
うまくいかないケース
ここまでの説明が理解できれば、http://intra/ではアクセスできないケースがあることが理解できるのではないかと思います。
具体的なケースを示します。まず前提として以下のケースで、
- hostsファイルに記載されていない
- lmhostsファイルに記載されていない
- WINSが構成されていない
- 対象サーバーと同一サブネットに無い(ブロードキャストでの名前解決はできない)
これらすべてに加えて、以下のどれかの条件に当てはまる時です。
- DNSの検索時にドメインサフィックスを追加するように設定されていない
- ドメインに参加していない
- 違うドメインに参加している
ちょっと混乱するのが、同じActive Directoryフォレストに参加しているのだけれども、ドメインが異なる場合です。この場合、DNSの設計やクライアントの設定にも依存しますが、「子ドメインから親ドメインのホストは名前解決できる」のに「親ドメインから子ドメインのホストは名前解決できない」というようなことが起こりえます。
きちんと名前解決の問題を起こさないようにしたければホスト名だけでのアクセスはやめて、FQDNでのアクセスをするべきなのです。これであれば名前解決には失敗しません。
FQDNの場合の落とし穴
ではいつでもhttp://intra.sample.local/のようにFQDNでアクセスすれば問題が起きないかというと、そうでもないのがまた難しいところです。
ブラウザにおいて、逆に「http://intra/なら接続できるのにhttp://intra.sample.local/では接続できない」というようなことが起こりえます。
これはIEのProxy接続に関する挙動の問題です。問題の設定箇所は以下の場所にあります。
ツール→インターネットオプション→接続タブ→LANの設定
この中の「ローカルアドレスにはプロキシサーバーを使用しない」という設定がくせ者です。この設定の名称だけを見ると、「名前解決をした結果のIPアドレスが、同一サブネット内に存在すれば」というような意味合いに思ってしまいがちです。
でも、よく考えてみると、Proxyサーバーを利用するケースではそもそも名前解決はホストでは実施せず、名前解決の段階からProxyにすべてを任せます。ですので、上記の解釈はそもそも成り立たないわけです。
で、結論としては、この設定は
- 「URLの中に.(ドット)があればローカルアドレスではない(Proxyを使う)」
- 「URLの中に.(ドット)がなければローカルアドレスである(Proxyを使わない)」
という意味になります。
Proxy経由でもintraにアクセスできるなら別にどうでもいい問題なのですが、Proxy経由ではintraにはアクセスできないので直接アクセスしなくてはいけない、というような場合には気をつける必要があります。
ちなみにこの「.(ドット)があるかどうかで判断」という話はIEのセキュリティゾーンの話にも関連してくるのですが、長くなりすぎたのでそれはまた別エントリで書こうと思います。