Microsoft ネットワークを解剖する

第2回「NetBIOSでの通信と名前解決の仕組み(後編)」

現在のMicrosoftネットワークは、度重なる仕様拡張の結果非常に複雑かつ難解なものとなっている。第二回目は一回目に引き続き、NetBIOS名での通信と名前解決の仕組みを解説していく。

WINS の登場

まず前号の復習をかねて、WINS の登場に至った背景を簡単に復習しよう。
前号で解説したように、Microsoft ネットワークは本来単一セグメントでしか用いることのできない NetBEUI プロトコルを前提とした仕様となっており、名前解決も全てブロードキャストで行ってきた。TCP/IP を下位プロトコルに採用するにあたり、LMHOSTS ファイルが導入されてセグメントを越える通信が一応可能になったが、可能なサービスはファイル共有等に限定されていた。

これに対する解として Windows NT 3.5 でマイクロソフトが実装したのがWINSである。WINS の外部仕様の一部はNBNS(NetBIOS Name Service)として、RFC1001, RFC1002 で規定されている NBT の仕様に含まれており、筆者も関わっているオープンソースソフトウェアの Samba では、この記述を元に UNIX 上で動作する WINS サーバを実装している(注1)。

注1: Samba の WINS は複製が行えないが、これは複製がRFCで規定されておらず、Microsoft の WINS サーバは独自の方式で複製を行っているためである。この他ブラウジング関連や DNS との連携などで、Microsoft の WINS は独自の拡張を行っている。

WINS 環境

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)。

注3: 実際は肯定以外の応答が戻ることもある。否定応答の場合後述するように名前登録が拒否される。無応答の場合はブロードキャストなど別の方法での登録を試みる。

また、これらのパケットは、クライアント側の 137/udp から送信先の udp/137 に対して送られている。前回記述しなかったが、WINS が存在しない時のブロードキャストも同様である。

図1: WINS 環境における名前の登録
図1: WINS 環境における名前の登録

WINS サーバが指定されているにも関わらず WINS サーバに接続できない場合は、レジストリ(注4)で設定された時間の1/8の時間毎にWINSサーバへの接続を試み, 4回試みても接続できない場合(つまり設定された時間の半分を過ぎても接続できない場合)は通信先のWINSサーバをもう一台に切り替えて, 4回同様の登録の試みを行うという動作を繰り返す。

注4: Q154409: Setting WINS Clients Refresh Intervals to Occur Infrequently を参照のこと。ただし, 当方で検証した限り Windows NT での該当するレジストリの名前は InitialRefreshTimeout ではなくInitialRefreshT.O. であった。

この様子をキャプチャしたものを図2に示す。

図2: WINS サーバに接続できない WINS クライアントの送出するパケット
図2: WINS サーバに接続できない WINS クライアントの送出するパケット

このレジストリのデフォルトの値は16分のため, 以下のような動作を行う

  1. クライアントがWINSサーバへの接続を開始する
  2. プライマリWINSサーバ(192.168.1.2)に接続するが動いていないので接続できない 接続を3回試行する。フレーム9-10ではうち2回をキャプチャした
  3. セカンダリWINSサーバ(192.168.1.3)に接続するが動いていないので接続できない フレーム11-13まで、接続を3回試行している
  4. セカンダリWINSサーバに2分毎に8分間接続を試みるが失敗 フレーム101-224まで、2分毎に3回ずつ、計12回試行している
  5. プライマリWINSサーバに2分毎に8分間接続を試みるが失敗 フレーム241で、接続対象がプライマリに変更になったのがわかる
  6. (4)(5)を続ける
なおキャプチャでは、EARTH<1E>の登録で失敗しているため、残りのNetBIOS名の登録試行が行われていないが、EARTH<1E>の登録が成功した場合はD-ANGEL<20>等他のNetBIOS名も登録される。

登録に成功した場合は, 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分間隔で更新要求を行うようになった。

図3: 名前登録の更新要求
図3: 名前登録の更新要求

更新要求の失敗

登録には成功したが, 更新の時点で 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サーバの動作のところで解説する。

図4: 名前登録の失敗
図4: 名前登録の失敗

名前の解放

マシン停止時(サービス停止時)には名前解放のパケットが送信され、WINS データベース中のエントリを解放する。この様子をキャプチャしたのが図5である。 ブロードキャストの場合と異なり、解放要求は WINS サーバに送付され、また応答が WINS サーバから返却される。例えば、フレーム1253 の NS:Release req. for MAYUMI<00> に対して、フレーム1256で Success という肯定応答が行われている(注6)。

注6: 名前登録時と同様、肯定以外の応答が戻ることもあるが、筆者が調査した限りクライアント側の動作に違いはなかった。
図5: WINS 環境における名前解放
図5: WINS 環境における名前解放

Windows 98/2000 の仕様変更

冒頭で触れたように、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サーバと通信できる場合, 該当のWINS サーバ上で重複し ていない名前はとりあえず登録されるので、後でローカルサブネットや同じ WINSサーバを指定していないクライアント中にたまたま同じコンピュータ名 のマシンがあると、図6のようにマシン起動後暫くして、登録した名前が重複して名前の登録が重複するという事象が発生してしまう。Microsoft ネットワークの仕様として登録が重複(conflict)した名前は無効になってしまうため, 突如通信できなくなるといった事象が発生する。

図6: WINS クライアントと非WINS クライアントの不整合
図6: WINS クライアントと非WINS クライアントの不整合

従って, WINS を利用する場合はすべてのクライアントをWINSクライアントとして構成するか, 後述するWINSプロキシを利用することが強く推奨される。

WINS プロキシ

Windows NT 3.5 以降には, 非WINSクライアントが間接的に WINS サーバを利用できるように, WINS プロキシという機能が実装された。なお Windows NT4.0 以降では需要が減少したと判断されたためか, レジストリ(注7)を直接編集しないとこの機能は有効にならない。
注7: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Netbt\Parameters に EnableProxy: REG_DWORD というエントリを追加して値を 1 にする。

WINS プロキシのマシンは, 図7のように bノードによる名前解決パケットを受信して, それをあらかじめ設定した WINS サーバに送信することができる。非WINS クライアントが多かった昔は有用な機能であるが, Windows 95 以降のOSは WINS クライアントになれるので, 現状この設定を行うメリットはないであろう。

図7: WINSプロキシの動作概念図
図7: WINSプロキシの動作概念図
WINS サーバが同時に WINS プロキシになることはできない。
またWINS プロキシはブロードキャストベースのクライアントマシンに対するサービスであるため、
サービスを利用するクライアントマシンが存在する各セグメント毎に必要である。

名前解決

WINS の実装と共に名前解決機能も拡張された。各所に同様の図があるが、一 応図8 に現在筆者が理解している名前解決の順序を記載しておく。以下注意すべき点を記述する。
なお、以下のように名前解決の機構は不可解とは言わないまでも各種の設定が影響し、非常に繁雑である。名前解決のトラブルシューティングを行なうときにはこれらの仕様を把握した上で、個々のマシンの設定もしっかり把握する必要がある。

以下, 個々の名前解決の方式について解説する。

図8: NetBIOS名の名前解決の順序

NetBIOS ネームキャッシュ

名前解決を行なった NetBIOS 名は、デフォルトで 600秒の間(注8)キャッシュされるが、これを NetBIOS ネームキャッシュという。現在どのようなデータがキャッシュされているかは 図9 のようにnbtstat -c で確認できる。

図9: nbtstat -c の結果(Windows NT 4.0)
図9: nbtstat -c の結果(Windows NT 4.0)
現在キャッシュされているエントリとキャッシュされる残り時間が表示されている。
キャッシュ時間が-1 となっているのは LMHOSTS で静的に登録された、有効期限切れにならないエントリを示す。
なお、表示は秒単位であるにも関わらず、残り時間は 10 秒単位でしか更新されないという不可解な仕様になっている。
ただしこの仕様は Windows 2000 では改善されており、きちんと1秒単位で表示される。

NetBIOS ネームキャッシュ自体は NBT を利用していれば WINS を利用しない場合でも利用される。

注8: このキャッシュ時間を変更することも可能である。方法は Q188655, Q158474 等にある CacheTimeout というレジストリキーを参照されたい。筆者は Windows 2000 でこのパラメータの動作を確認している。

また LMHOSTS 内で #PRE を付けたエントリは LMHOSTS ファイル読み込み時やnbtstat -R コマンドの実行時に自動的にキャッシュに格納され、以後永続的にキャッシュされる。この為、WINS 環境においても、NetBIOS 名のエントリを#PRE 付きで LMHOSTS ファイルに記述しておくことで、その名前の名前解決を高速に行なうことが可能である。
ただしデフォルトで(注9)キャッシュされるのは100エントリまでである。

注9: Q102725 等にNetBIOSネームキャッシュの最大エントリ数を変更する方法が記述されている。上記ドキュメント中のレジストリキー MaxPreload を参照して欲しい。

ノードタイプ

ノードタイプとは、WINS と ブロードキャストの名前解決順を設定する要素であると考えて良い。

表1: ノードタイプ一覧
ノードタイプ説明
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ネットワークの混迷の一端を担っていると言えよう。

なお、HノードはRFCに定義されていないMicrosoftの独自仕様である。また RFC ではLMHOSTS ファイルの記述はない 。従って厳密には最初の3つも含め、RFC の仕様を独自に拡張した実装となっているとも言える。

ノードタイプはDHCPサーバの管理者がDHCPオプションとして指定する際に通常Hノードで指定するという以外では、あまり意識することはないであろうが、トラヒックのチューニングの際には M ノードの利用を考慮しておいた方がよい。詳細は後の連載で解説したい。

WINS サーバへの問い合わせ

WINSサーバにはプライマリとセカンダリがあるが、DNSとは異なり、前述したようにプライマリのWINSサーバで名前解決に失敗した場合は、セカンダリのWINSサーバに問い合わせが行われる。このため、セキュリティ上の具合などで、社員用WINS サーバと派遣社員用WINS サーバを用意し、社員はプライマリに社員用、セカンダリに派遣社員用の WINS サーバを設定するといった運用も技術的には可能である。

なお、Windows 95 にはセカンダリサーバの指定がないとプライマリサーバの指定が無効になるという有名すぎるバグがある。WINS サーバがネットワークに1台しかない場合, Windows 95 クライアントにはプライマリ/セカンダリともに同じ WINS サーバを指定すること。
また前述したように Windows 98/2000 では、設定可能な WINS サーバの台数は 12 台に拡張されているので、より柔軟な運用も可能である。

LMHOSTS ファイルへの問い合わせ

LMHOSTS ファイルの問い合わせはファイルの先頭から順にエントリを読み込んでいくことにより行われる。従って、LMHOSTS ファイルの先頭に記述したエントリの方が、末尾に記述したエントリよりは早めに解釈される。またコメント行も読み込まれて解釈されるので、不要なコメントは除いた方がわずかだが参照速度は速くなる。
なお LMHOSTS ファイルへの問い合わせの際には、毎回ファイルの内容を参照するので、OS起動後にエントリを追加しても認識される。

ただし、#PRE エントリを書いても明示的に nbtstat -R を行わない限りNetBIOS ネームキャッシュには読み込まれない。nbtstat -R を行わないうちは、単なる LMHOSTS 中のエントリとして扱われる。

DNS/hosts ファイルによる名前解決

NetBIOS 名の解決にも関わらず、優先度は低いながらも hosts/DNS への問い合わせが可能になっている。ただし、hosts/DNS で名前解決が可能なものは、CIFS と同様ファイルサーバを示す識別子 0x20 とドメインログオンに必要な各種 NetBIOS 名だけである(注11)。

注11: DNS のみでドメインログオンを実装する方法に付いては J041750: Windows NT のドメインを認識する DNS の設定 を参照のこと。筆者の環境でこの設定でドメインにログオンできることは確認している。

この名前解決は DNS サーバへアクセスを行うため、ダイアルアップ環境などで不要なトラヒック増加の原因となる。しかも Windows 95/98 等ではデフォルトで有効になっているため, 利用していないのであれば無効にすることを推奨する。詳細については Q137368: How to Disable NetBIOS Name Resolution on DNS を参照してほしい。

名前解決の手段の優先順位を変更する

Windows NT 4.0 や Windows 95/98 では、レジストリを変更することで、名前解決の手段の順番を変更することが可能である(注12)。しかしこの名前解決の順番は従来のMicrosoftネットワークの根幹を支えてきたものであるため、この順番を変更した場合何が発生するかは予測がつかない。従って、筆者としては変更は絶対に行うべきでないと考える。Windows 2000 でこのレジストリが機能するかどうかは検証していないが、おそらく動作しないと思われる。

注12: Q139270: How to Change Name Resolution Order on Windows 95 and Windows NT および関連する KB(Q170619, Q171567)を参照して頂きたい。

また、筆者が確認を行った限りこの機能は Windows NT 4.0 では動作しない。関連する情報として Q171567: Windows NT 4.0 ServiceProvider Priority Values Not Applied を参照してほしい。

NetBIOS の動作を規定するレジストリ

本記事中でも各所でレジストリの変更個所を示唆しているが、NetBIOS 関連のレジストリのほとんどは、以下の場所にある。なお存在するキーの種類などはリソースキットや、以下であげたKB等を参考にしてほしい

Windows NT/2000
Windows 95/98/Me

次回予告

ここまでNetBEUIからはじめて、Microsoftネットワークの仕様の拡張を、通信方式と名前解決を中心にして述べてきた。何故Microsoftネットワークがこれほど複雑になったのかの一端をご理解頂ければ幸いである。
なお、ここに記述した内容は筆者が実験を行って確認したものであるが、全てのサービスパックやOSバージョンについて検証を行ったものではないため、記述漏れや誤りがあるかも知れない。その際は気軽にご指摘頂ければ幸いである。
次回はマイクロソフトネットワーク最大の難関であるブラウジングについて解説していきたい。

注記・補足

  1. 本文書は、日経オープンシステム 2000 年 10 月号の「オープンセミナー」に掲載された「Microsoft ネットワークを解剖する 第2回「NetBIOSでの通信と名前解決の仕組み(後編)」の草稿を筆者の方で HTML 化して掲載しているものです。
  2. 本連載を元にして、「アンドキュメンテッド Microsoft ネットワーク」を出版しておりますので、併せてご参照ください。
  3. 元々の原稿では、紙面が限られていたため、「注」を多用していますが、HTML 化に伴い、本来「注」にする必要のないものについては、本文中に戻しました。

Copyright (C) 1998-2009 TAKAHASHI, Motonobu
Last update: 2006-07-12 00:00:19 JST
webmaster@monyo.com