SQL Server をインストールしたクリーンインストール直後の XP SP3 のマシンに、別PC(Vista)から Management Studio からアクセスをしようとしました。
この時、XP マシンのWindowsファイアウォールは有効で、UDP 1434 と sqlserver.exe については通信を許可するように設定してあります。
また、この XP マシンのIPアドレスはDNSサーバには登録してません。
その際、 Management Studio の｢サーバの参照｣→｢ネットワークサーバ｣で、自動的にLANからみつけた SQL Server インスタンスから選択させました。
｢サーバの参照｣→｢ネットワークサーバ｣で出てきたリストにはちゃんと対象の XP マシンが表示されてるので、つながるだろうともって接続しましたが、接続エラーに。。。
つまり SQL Swever Browser のサービスはネットワークから使えるのに、SQL Server インスタンス自体がネットワーク的につながらないのです。
ちゃんと FW で sqlserver.exe 許可してるのにおかしいと思ったんで、Management Studio からIPアドレスを直接たたいてアクセスするとつながりました。
どうやら名前解決あたりがあやしいらしいです。
ということで、一体どういうパケットを投げて失敗してるのか Wireshark というパケットキャプチャソフトでチェックしてみました。
すると、ブロードキャストで UDP 137 宛てにその XP マシン名を投げてるパケットがあります。
下記がパケットキャプチャしたイメージです。
もしかして思って、XP マシンのファイアウォールの設定を見ると、｢ファイルとプリンタの共有｣のチェックが外れてます。というより、インストール直後はデフォルトでチェックが無いっぽいですね。
ここで、｢ファイルとプリンタの共有｣の詳細で、UDP 137 を許可してやると、 Management Studio の｢サーバの参照｣からでもアクセスできるようになりました。
どうやら最初の失敗時の流れとしては下記のような感じになっていたっぽいです。(名前解決の詳細は(MCP70-642)2.5 クライアントコンピュータの名前解決構成参照。)
クライアントPC：Management Studio でLAN内の SQL Server インスタンス検索
↓
サーバPC：UDP1434 はFW許可されてるので、 SQL Server Browser が応答を返す(この時サーバのIPではなく名前を返す)
↓
クライアントPC：ユーザが一覧に出たLANのインスタンスを選択し、接続(この時サーバ名でアクセス)
↓
クライアントPC：サーバ名の名前解決を試みる。
まずDNSサーバに問合わせ。→対象マシンはDNSサーバに登録してないのNG。
クライアントは Vista なので、LLMNR で問合せ。→対象マシンはXPなのでNG。
NetBios による名前解決。ブロードキャスト(UDP137)で問合せ。→対象マシンはUDP137をFWで拒否ってるのでNG。
↓
クライントPC：接続失敗
DNSが無いLAN内での名前解決には UDP 137 が未だに必要なんだ。。ということでここからちょっといろいろ試してみました。
まず、TCP/IPの設定で、NetBIOS 設定というがあります。ここは NetBIOS orver TCP/IP の有無に関する設定ですが、デフォルトは｢既定値｣になっています。
規定値の意味についてWindowsヘルプを見るとIP アドレスが自動的に取得される場合は、[既定値] オプションが選択されます。これにより、このコンピュータは、IP アドレスと構成リースを取得するときに、DHCP サーバーによってオプションで提供される NetBIOS orver TCP/IP(NetBT) 設定を使用するようになります。[NetBIOS over TCP/IP を無効にする] DHCP オプションが DHCP サーバーにより提供される場合は、このオプションの値で NetBT を有効にするか、無効にするかが決まります。[NetBIOS over TCP/IP を無効にする] DHCP オプションが DHCP サーバーにより提供されない場合は、NetBT は有効になります。とあります。
今回DHCPは有効になっていますが、DHCPサーバはルータで NetBIOS に関するオプションは無いので有効になるんですね。
試しにサーバとなる PC で NetBIOS over TCP/IP(NBT) を無効にしてみました。(DNSには未登録です)
ファイアウォールでは NetBIOS が使うポート UDP 137,138 TCP 139 を開放します。
そして、クライアントPCのエクスプローラから \\コンピュータ名 でアクセスを試みます。
結果名前解決に失敗したようで、｢ネットワークパスが見つからない｣というエラーとなりました。
ということで、NetBIOS が使うポートが開放されてても、NBT が無効かつDNSサーバに名前が登録されていない場合は、\\コンピュータ名 でアクセスできないということが分かりました。
次に、Windows ファイル共有においては Windows 2000 あたりから CIFS という SMB を拡張した NetBIOS に依存しないファイル共有のプロトコルが追加されてます。
CIFS はポート 445 のみ使うので、ファイアウォールで TCP445 のみを許可 + NetBIOS 無効にしてクライアントから接続。(DNSには未登録です)
結果は接続失敗でした。
で、調べてみると CIFS では名前解決には DNS を使うようです。そして DNS がダメなときは NetBOIS によるブロードキャストで名前解決を試みるようです。上記では DNS も NetBIOS もダメということで、名前解決に失敗し接続できなかったんですね。
詳しくはITPro:Windowsに潜むデフォルト設定の落とし穴（下）の図と、@IT:第20回 ファイル共有プロトコルSMB／CIFSからの一連の連載が非常に参考になります。
LAN内で名前解決するには、DNSサーバに登録するか、 NetBIOS over TCP/IP(NBT) を使うかになるんですが、NBT を使う場合は、デフォルトでは遮断になっている UDP 137 ポートをあける必要と、TCP/IP の設定で、｢NetBIOS over TCP/IP を有効にする｣(DHCPサーバでNetBIOS有効の設定か項目ない時はは既定値でもOK)にしとかないと、ダメだということがよく理解できました。
ついでに、DNSサーバにIPとホスト名登録済みかそうでないかと、NetBIOS over TCP/IP が有効無効かという条件で、ファイアウォールでファイル共有と名前解決のポート(NetBIOSのポートのみ。DNSで使用するポートは開放済み)の開放可否の組み合わせで、ファイル共有ができるかどうかの表を作ってみました。
※クライアントPCは NBT が有効になっていることとします。
┌─────┬──────┬──────┬──────────────┐
│ │ │ │FWで許可しているポート │
├─────┼──────┼──────┼────┬─────┬───┤
│ │ │ │UDP137 │UDP137 │TCP445│
│ │ │ │TCP139 │TCP445 │ │
│ │ │ │(NBT) │(CIFS+NBT)│(CIFS)│
├─────┼──────┼──────┼────┼─────┼───┤
│パターン1 │DNS登録済み │NetBIOS有効 │○ │○ │○ │
├─────┼──────┼──────┼────┼─────┼───┤
│パターン2 │DNS登録済み │NetBIOS無効 │× │○ │○ │
├─────┼──────┼──────┼────┼─────┼───┤
│パターン3 │DNS未登録 │NetBIOS有効 │○ │○ │× │
├─────┼──────┼──────┼────┼─────┼───┤
│パターン4 │DNS未登録 │NetBIOS無効 │× │× │× │
└─────┴──────┴──────┴────┴─────┴───┘
パターン1は DNS による名前解決＋NetBIOS による名前解決OKの状態ですね。
パターン2は DNS による名前解決はできるけど NetBIOS による名前解決はできない状態です。DNS対応のCIFSでのみアクセスできます。
パターン3は NetBIOS による名前解決なので、CIFSオンリーはダメです。NetBIOSのみのファイル共有かCIFS+NetBIOS名前解決というハイブリッドなら行けます。
パターン4は名前解決手段が無いので、どっちもダメです。(ただ、Vista以降なら LLMNR があるので、CIFSによるアクセスは出来るかも知れません。)
小規模なネットワークではLAN内にDNSサーバ運用してるところはまれなので、結局コンピュータ名で何かしようとすると、NBT を有効にし UDP137(ファイル共有する場合は TCP139 or TCP445)を開放しないといけないということですね。
