現在のMicrosoftネットワークは、度重なる仕様拡張の結果非常に複雑かつ難解なものとなっている。第二回目は一回目に引き続き、NetBIOS名での通信と名前解決の仕組みを解説していく。
まず前号の復習をかねて、WINS の登場に至った背景を簡単に復習しよう。
前号で解説したように、Microsoft ネットワークは本来単一セグメントでしか用いることのできない NetBEUI プロトコルを前提とした仕様となっており、名前解決も全てブロードキャストで行ってきた。TCP/IP を下位プロトコルに採用するにあたり、LMHOSTS ファイルが導入されてセグメントを越える通信が一応可能になったが、可能なサービスはファイル共有等に限定されていた。
これに対する解として Windows NT 3.5 でマイクロソフトが実装したのがWINSである。WINS の外部仕様の一部はNBNS(NetBIOS Name Service)として、RFC1001, RFC1002 で規定されている NBT の仕様に含まれており、筆者も関わっているオープンソースソフトウェアの Samba では、この記述を元に UNIX 上で動作する WINS サーバを実装している(注1)。
WINS の導入により、名前解決の仕組みは大きく変更される。以下WINSを導入したWINS環境について説明していこう。ここでは Windows 95/NT 4.0 を例にとって説明していく。これらのOSでは、WINSクライアントとして動作するにあたり、プライマリ、セカンダリという2台の WINS サーバを設定できる。Windows 98/2000 以降では WINS サーバを 12 台まで登録できるように仕様が拡張されているが、これについては後で述べる。
WINS クライアントになっているマシンの起動時の名前登録のパケットをキャプチャしたものが図1である。フレーム31から33をみると一目で分かるとおりブロードキャストではなく、プライマリWINS サーバ(WINSSRV)に対して NS: Registration req. for [名前] というパケットで名前の登録を行なっているのが分かる。
なお、ブラウジング関連など、一部のブロードキャストベースである必要があるエントリ(ワークグループ名<1d>など)は, 登録自体は成功するが名前解決時にそのエントリは常に無視されるなどの特殊な処理が行われる。詳細は、次回以降で連載予定のブラウジングの説明のところで解説する。
ブロードキャストの場合と異なり、フレーム34から36で登録に成功したという肯定応答が戻るところも異なる点である(注3)。
また、これらのパケットは、クライアント側の 137/udp から送信先の udp/137 に対して送られている。前回記述しなかったが、WINS が存在しない時のブロードキャストも同様である。
図1: WINS 環境における名前の登録
WINS サーバが指定されているにも関わらず WINS サーバに接続できない場合は、レジストリ(注4)で設定された時間の1/8の時間毎にWINSサーバへの接続を試み, 4回試みても接続できない場合(つまり設定された時間の半分を過ぎても接続できない場合)は通信先のWINSサーバをもう一台に切り替えて, 4回同様の登録の試みを行うという動作を繰り返す。
この様子をキャプチャしたものを図2に示す。
このレジストリのデフォルトの値は16分のため, 以下のような動作を行う
登録に成功した場合は, WINS サーバ側から登録成功のパケットが返却されるが, そこには登録した情報のTTL(書き換え間隔)が記述されている。クライアントはTTLの半分を過ぎると名前登録の更新要求を行う。
この様子をキャプチャしたのが図3である。
検証のためWINSのTTLは最小の40分にしてある。18:41分のフレーム24-51で登録したエントリを19:03(フレーム207-313), 19:23(フレーム96-102)でそれぞれ更新している。なお19:30頃にWINSサーバを止めたところ、19:43分の更新は失敗し、その後WINSサーバに対して5分間隔で更新要求を行うようになった。
登録には成功したが, 更新の時点で WINS サーバとの通信ができなくなった場合は, 図3のように、5分毎に自分が登録したWINSサーバへの問い合わせを繰り返す。
この動作はWINSサーバへの通信が回復するか, 何らかの名前解決要求が別のWINSサーバで解決されるまで行われるようである。
実際、当方で確認を行なった際に、何のアクションも行わず放置しておいたところ、切り替わる気配がなかったため, 一昼夜そのままにしておいても5分毎の登録行為を継続していた。
その後新たな名前解決を行ったところ, 最終的に通信可能なWINSサーバに問い合わせて名前解決が行われたが, そのタイミングで名前解決を行ったWINSサーバに対して登録の通信も行われるようになった。
何らかの原因により既に WINS サーバに登録されているNetBIOS名を登録しようとした場合は登録は失敗する。図4では、すでに YUI<00>, YUI<20> といったNetBIOS名が登録されている WINS サーバに対して新規に YUIというコンピュータ名のマシンが名前登録を行おうとしたところである。たとえばフレーム23ではYUI<03>という名前を登録しようとしたが、フレーム26で、YUI<03>,Name Active Errorという形で、すでに「アクティブ」な名前が存在するというエラーになっている。なお、どのような場合に登録が失敗するかについての詳細は、WINSサーバの動作のところで解説する。
マシン停止時(サービス停止時)には名前解放のパケットが送信され、WINS データベース中のエントリを解放する。この様子をキャプチャしたのが図5である。 ブロードキャストの場合と異なり、解放要求は WINS サーバに送付され、また応答が WINS サーバから返却される。例えば、フレーム1253 の NS:Release req. for MAYUMI<00> に対して、フレーム1256で Success という肯定応答が行われている(注6)。
冒頭で触れたように、Windows 98/2000 では、クライアントが設定可能なWINS サーバの台数が 12 台に拡張されている。そこでこれらの OS の動作について確認した。192.168.10.150 ー 192.168.10.153 まで 4 台の実際には存在しない WINS サーバを設定したところ、名前解決を行うタイミングで、WINS サーバに対して通信を行おうと ARP リクエストを行っているのが確認できる。ただし3台以上のWINSサーバを利用できるのは、名前解決の時だけのようである。キャプチャデータは省略するが、名前登録については図xx2のキャプチャと同様にプライマリとセカンダリのWINSサーバにしか登録は行わっていなかった。
このようにWINSを利用することで, 名前登録のブロードキャストトラヒック は減少するが、WINSサーバと通信できる場合, 該当のWINS サーバ上で重複し ていない名前はとりあえず登録されるので、後でローカルサブネットや同じ WINSサーバを指定していないクライアント中にたまたま同じコンピュータ名 のマシンがあると、図6のようにマシン起動後暫くして、登録した名前が重複して名前の登録が重複するという事象が発生してしまう。Microsoft ネットワークの仕様として登録が重複(conflict)した名前は無効になってしまうため, 突如通信できなくなるといった事象が発生する。
従って, WINS を利用する場合はすべてのクライアントをWINSクライアントとして構成するか, 後述するWINSプロキシを利用することが強く推奨される。
WINS プロキシのマシンは, 図7のように bノードによる名前解決パケットを受信して, それをあらかじめ設定した WINS サーバに送信することができる。非WINS クライアントが多かった昔は有用な機能であるが, Windows 95 以降のOSは WINS クライアントになれるので, 現状この設定を行うメリットはないであろう。
WINS の実装と共に名前解決機能も拡張された。各所に同様の図があるが、一
応図8 に現在筆者が理解している名前解決の順序を記載しておく。以下注意すべき点を記述する。
なお、以下のように名前解決の機構は不可解とは言わないまでも各種の設定が影響し、非常に繁雑である。名前解決のトラブルシューティングを行なうときにはこれらの仕様を把握した上で、個々のマシンの設定もしっかり把握する必要がある。
以下, 個々の名前解決の方式について解説する。
名前解決を行なった NetBIOS 名は、デフォルトで 600秒の間(注8)キャッシュされるが、これを NetBIOS ネームキャッシュという。現在どのようなデータがキャッシュされているかは 図9 のようにnbtstat -c で確認できる。
NetBIOS ネームキャッシュ自体は NBT を利用していれば WINS を利用しない場合でも利用される。
また LMHOSTS 内で #PRE を付けたエントリは LMHOSTS ファイル読み込み時やnbtstat -R コマンドの実行時に自動的にキャッシュに格納され、以後永続的にキャッシュされる。この為、WINS 環境においても、NetBIOS 名のエントリを#PRE 付きで LMHOSTS ファイルに記述しておくことで、その名前の名前解決を高速に行なうことが可能である。
ただしデフォルトで(注9)キャッシュされるのは100エントリまでである。
ノードタイプとは、WINS と ブロードキャストの名前解決順を設定する要素であると考えて良い。
ノードタイプ | 説明 |
---|---|
B(Broadcast)ノード | ブロードキャストのみを用いて名前を解 決。 |
P(Point-to-Point)ノード | NetBIOSネームサーバ(WINS)のみを用いて名前を解決 |
M(Mixed mode)ノード | Bノード →Pノードの順に名前を解決 |
H(Hybrid mode)ノード | Pノード → Bノードの順に名前を解決 |
LAN Manager の時代には、Bノード失敗後にLMHOSTS ファイルを参照する前号で解説した実装を「拡張(修正)Bノード」と称していたが, 現在のマイクロソフトの実装では, 上記4つすべてのノードにおいて名前解決に失敗すると, LMHOSTSを参照する実装に拡張されている。従って, 敢えてBノードの拡張に対してのみ特別な呼称を用いることに、もはや意味があるとは言えないと考える。
なおノードタイプ自体はRFC1001, RFC1002で定義されているが、定義されているのは最初の3つだけである。通常利用されるのは、WINS環境でのデフォルトであるHノードか, WINS がない環境のデフォルトであるBノードである。 Q142042 や Q160177 : Default Node Type for Microsoft Clients を参照してほしい。
ただし、筆者が Windows 98 で確認した限り、特にノードタイプが指定されていない DHCP クライアントは Mノードであった。また Windows 9x では、一度設定されたノードタイプはシステム再起動時にしか変更できない。これはノードタイプが DHCP によって設定されている場合も同様であった。
さらに、リソースキットの記述とは異なり、DHCPで設定したノードタイプとレジストリで設定したノードタイプが異なるときは、レジストリが優先されるのではなく、デフォルトの値が利用されている。こうしたところは、仕様として特に明記された文書もなくOSによって異なっている可能性もあるため、もし仕様が問題となる場合は、すべてのケースをOS毎に調べていくしかない。まさにMicrosoftネットワークの混迷の一端を担っていると言えよう。
ノードタイプはDHCPサーバの管理者がDHCPオプションとして指定する際に通常Hノードで指定するという以外では、あまり意識することはないであろうが、トラヒックのチューニングの際には M ノードの利用を考慮しておいた方がよい。詳細は後の連載で解説したい。
WINSサーバにはプライマリとセカンダリがあるが、DNSとは異なり、前述したようにプライマリのWINSサーバで名前解決に失敗した場合は、セカンダリのWINSサーバに問い合わせが行われる。このため、セキュリティ上の具合などで、社員用WINS サーバと派遣社員用WINS サーバを用意し、社員はプライマリに社員用、セカンダリに派遣社員用の WINS サーバを設定するといった運用も技術的には可能である。
なお、Windows 95 にはセカンダリサーバの指定がないとプライマリサーバの指定が無効になるという有名すぎるバグがある。WINS サーバがネットワークに1台しかない場合, Windows 95 クライアントにはプライマリ/セカンダリともに同じ WINS サーバを指定すること。
また前述したように Windows 98/2000 では、設定可能な WINS サーバの台数は 12 台に拡張されているので、より柔軟な運用も可能である。
LMHOSTS ファイルの問い合わせはファイルの先頭から順にエントリを読み込んでいくことにより行われる。従って、LMHOSTS ファイルの先頭に記述したエントリの方が、末尾に記述したエントリよりは早めに解釈される。またコメント行も読み込まれて解釈されるので、不要なコメントは除いた方がわずかだが参照速度は速くなる。
なお LMHOSTS ファイルへの問い合わせの際には、毎回ファイルの内容を参照するので、OS起動後にエントリを追加しても認識される。
ただし、#PRE エントリを書いても明示的に nbtstat -R を行わない限りNetBIOS ネームキャッシュには読み込まれない。nbtstat -R を行わないうちは、単なる LMHOSTS 中のエントリとして扱われる。
NetBIOS 名の解決にも関わらず、優先度は低いながらも hosts/DNS への問い合わせが可能になっている。ただし、hosts/DNS で名前解決が可能なものは、CIFS と同様ファイルサーバを示す識別子 0x20 とドメインログオンに必要な各種 NetBIOS 名だけである(注11)。
この名前解決は DNS サーバへアクセスを行うため、ダイアルアップ環境などで不要なトラヒック増加の原因となる。しかも Windows 95/98 等ではデフォルトで有効になっているため, 利用していないのであれば無効にすることを推奨する。詳細については Q137368: How to Disable NetBIOS Name Resolution on DNS を参照してほしい。
Windows NT 4.0 や Windows 95/98 では、レジストリを変更することで、名前解決の手段の順番を変更することが可能である(注12)。しかしこの名前解決の順番は従来のMicrosoftネットワークの根幹を支えてきたものであるため、この順番を変更した場合何が発生するかは予測がつかない。従って、筆者としては変更は絶対に行うべきでないと考える。Windows 2000 でこのレジストリが機能するかどうかは検証していないが、おそらく動作しないと思われる。
また、筆者が確認を行った限りこの機能は Windows NT 4.0 では動作しない。関連する情報として Q171567: Windows NT 4.0 ServiceProvider Priority Values Not Applied を参照してほしい。
本記事中でも各所でレジストリの変更個所を示唆しているが、NetBIOS 関連のレジストリのほとんどは、以下の場所にある。なお存在するキーの種類などはリソースキットや、以下であげたKB等を参考にしてほしい
ここまでNetBEUIからはじめて、Microsoftネットワークの仕様の拡張を、通信方式と名前解決を中心にして述べてきた。何故Microsoftネットワークがこれほど複雑になったのかの一端をご理解頂ければ幸いである。
なお、ここに記述した内容は筆者が実験を行って確認したものであるが、全てのサービスパックやOSバージョンについて検証を行ったものではないため、記述漏れや誤りがあるかも知れない。その際は気軽にご指摘頂ければ幸いである。
次回はマイクロソフトネットワーク最大の難関であるブラウジングについて解説していきたい。