図1: ブラウジングの概念
前回はMicrosoftネットワークのトラブルの温床であるブラウジング機能について条件をなるべく単純化して解説したが、それでもかなり難解なものになってしまったのは否めない。今回は更に条件を複雑にした場合のブラウジング機能を取り上げる。今回は前回の内容を踏まえた内容になるため、今回のセミナに臨む前に、是非前回のセミナをもう一度読み返して欲しい。
今回は解説のためにネットワーク構成図を多用し、ブラウズリスト交換に関する通信は、前回説明したように通常のSMB 通信と見分けが付かないので基本的に割愛している。
まず前号の復習をかねて、単一セグメントのブラウジングの仕組みを簡単に復習しよう。
図1に示したとおりブラウザ(注1)が持つブラウズリストの内容を取得、参照することがブラウジング機能の実体である。ブラウズリストの内容は、各クライアントが定期的に自分の情報を登録/更新/削除することによって維持され、ブラウザ自身は、ブラウザ選定という機構によって選ばれる。
なお本章では図1を含め、特に明記しない限り図中の各マシン間でIPレベルでの通信(ping
しかし、マスタブラウザへの通信や、ブラウザ選定などの各所にブロードキャストが用いられており、このままでは複数セグメントに及ぶTCP/IPネットワークには対応できない。この環境にどのようにして対応していったかを理解し、トラブル解析を可能にするのが今回の課題である。
以下早速見ていこう。なお、とくに断らない限り、プロトコルはNBTであると仮定する。またWINSも用いず、名前解決はLMHOSTSで行うと仮定する。もちろん現実にはWINSサーバを用いることが多いだろう。WINSサーバを用いれば以下で説明する複雑な内部動作を知らなくてもブラウジングを適切に行うことが可能になる場合が多い。しかしブラウジング動作を理解し適切なトラブルシューティングを可能にするという本セミナの目的のために、前半は敢えてWINSがない前提で説明を行っていく。
WINS を導入した環境との差異に付いては後半で説明する。
単一ワークグループ内に複数のワークグループ(注2)が存在すると、図2のように「ネットワークコンピュータ」でワークグループの一覧が列挙されるようになる。この仕組みを説明しよう。
まずは、起動直後のマシンPC1が、図2の情報を入手したときのパケットをキャプチャした結果を図3に、流れを図4に示す。
----- 図4: 別ワークグループのブラウズリストを要求する際の動作プロセス COE_MB TS_MB COEのブラウザ TSのブラウザ |(1) / | ______________/(2) MONYO93C2/ ワークグループCOEに所属 -----
最初はフレーム1219で自分が所属するワークグループCOEのブラウザとの通信を要求(注3)し、フレーム1366〜1416までCOE_MBからブラウズリストを入手する。
この時点でクライアントでは図2を表示する情報を受け取っており、ワークグループTSの存在も認識している。そこでクライアントはその情報を用いて、フレーム1438のように通信先としてTS<1D>を指定することで別のワークグループTSのマスタブラウザTS_MBに直接接続にいく。後は前号で述べたようにフレーム1443でTSワークグループのマスタブラウザがブラウザのリストを返却、クライアントは任意の3台を選択してキャッシュし、その内の1台に対してブラウズリストを要求するという処理をフレーム1451からはじまる一連の通信で行っている(注4)。
当然2回目以降はキャッシュがあるので、直接該当のワークグループのブラウザに対して接続を行う。
それではクライアントが所属するワークグループのマスタブラウザは、どうやって別のワークグループのマスタブラウザの存在を知るのかに付いて説明しよう。
マスタブラウザはデフォルトで定常時15分毎に、図5のようなWorkgroup Announcementパケットをブロードキャストで送信する。
パケットの構造は前号で紹介したHost Announcementパケットと同様であるが、写真xx3中のBROWSER 行の下から3行目のように必ずDomain Enumフラグが設定されている点が大きな違いである(注xx5)。また送信先はフォーカスしている行のように、<01><02>__MSBROWSE__<02><01>という特殊なNetBIOSグループ名である。この名前は写真xx4のように、マスタブラウザが必ず登録しているNetBIOSグループ名である。なお nbtstat コマンドなどで見ると、0x01 や0x02という16進数を表示することができないため「.」で代用されているので注意して欲しい。
これにより、各マスタブラウザは別のマスタブラウザの存在を知ることができるのである。
----- 注xx5: 観察した限り、Domain Enum フラグ以外はOS種別を示すビットしか設定されないようであるが、断言するには到っていない。 ----- (WG-announce1.bmp) - WG-announce1.cap Workgroup Announcement が 15分おき、前回解説したLocal Master Announcementが12分おきに送信されていることが確認できる。Local Master Announcement があるため、FLAIL は COE ワークグループのマスタブラウザであることが確認できる。なお FLAIL はCOEというワークグループに所属するWindows 2000 Serverである。 ----- 写真xx4: nbtstat コマンドをマスタブラウザで実行した結果 (nbtstat-a.bmp) COE<1D> といった表示に加え、..__MSBROWSE__.<01> という表示が確認でき る。 -----
通知を受け取った各ワークグループのマスタブラウザは、ワークグループの情報を受領するが、実際に意味を持つのは受領したワークグループ名だけである。前述したように、実際のブラウズリストの内容はクライアントが個別にブラウズマスタを検索して取得しにいく必要があることに注意して欲しい。
なおこの情報も、前号で説明したブラウズリストへの登録と同様に、3回更新に失敗するまでブラウズリストから消去されない。従って、最高45+12分間(注xx6)は「ネットワークコンピュータ」上に表示が残る可能性がある。なおワークグループを構成する最後のマシンが停止するときであっても、ワークグループ名の解放という処理は行われない。これは前号で紹介したようにマシン停止後にブラウザ選定が行われる関係上、マシンの停止時に自分が最後の1台であることを知ることが不可能なのでやむを得ない仕様であろう。
----- 注xx6: この値は単一セグメントに限った場合である。45分は15分間隔で3回更新に失敗するのに要する時間。12分は、その情報がバックアップブラウザに伝達されるのに要する時間(いずれもデフォルト値)である。 -----
また、このパケットの送出間隔についてもWindows 9x のマスタブラウザでは、10分おき、8分おき等、何通りかの送出間隔が確認された。
このタイトルをに違和感を感じた方は、「ワークグループは複数セグメントにわたって構成することができない」というMicrosoft ネットワークの常識をご存知の方であろう。実際のところ、この常識は見方によって正しいとも正しくないともいえるものである。以下その理由も含め説明する。
なぜドメイン構成をとると複数セグメントにわたるブラウズリストを構築できるのか、その鍵はドメインマスタブラウザ(以下DMB)という役割のマシンの存在にある。
ドメイン構成をとった場合、図xx3のようにドメインのPDCは自分が存在するセグメントで必ずブラウザ選定で勝利してセグメント内の所属ワークグループ(ドメイン)のマスタブラウザとなると同時にドメインマスタブラウザとして機能する。前号のブラウザ選定の説明でPDCはブラウザ選定で必ず勝利しないといけないと述べたが、これはドメインマスタブラウザとなる為である。
ドメインマスタブラウザは「ワークグループ名<1B>」という特殊なNetBIOS名を登録するが、これが後述するように重要な役割を持つことになる。
PDCが存在しない各セグメントでは前号で述べたようにセグメント毎にワークグループのマスタブラウザが選定されるが、これをドメインマスタブラウザと対比する意味でローカルマスタブラウザ(LMB)(注xx7)と呼ぶ。
----- 注xx7: セグメントマスタブラウザ(SegMB)と呼ぶこともある。マイクロソフト社の技術情報でも両方の呼称が使われているが、ここではリソースキットでも用いられているローカルマスタブラウザの呼称を用いた。 -----
似たような用語が出てくるので、混乱しないように再度整理する。
DMBもLMBもセグメントのマスタブラウザという点では同一の機能を果たす。DMBやLMBといった区別は、あくまで複数セグメント間のブラウズリストを構築する際に発生する役割の区分である。またDMBとなれるのはブラウザ選定の結果マスタブラウザとなったPDCのマシンのみである。
-----
図xx3: DMBとLMB
Seg1----+ +-Seg2-----
WG1-DMB |-------[router]------+ WG1-LMB
SV1(PDC) | | |
---------+ |
+----+-----+
| WG1-LMB |
| |
+----Seg3--+
-----
それではDMBとLMBはどのようにしてセグメントを越えたブラウズリストの統合を行なうのであろうか。写真xx5にDMBとLMBの通信のキャプチャを示す。
LMB(ここではHILDE)は「ドメイン名(ここではCOE)<1B>」という名前に対して、デフォルト12分(注xx8)毎にフレーム1345のようなMaster Announcementを行なう。DMBはこの要求を受けてフレーム1347、1351でLMBの持つブラウズリストを取得し、フレーム1356、1359で、LMBのセグメントにあるワークグループの一覧とそのマスタブラウザの情報を入手する。またLMBはフレーム1358、1360ー1372でDMBの保持するブラウズリストを入手し、フレーム1376、1377でDMB の持つワークグループの一覧とそのマスタブラウザの情報を入手している。なお、この際は差分ではなく、全ての情報が送信される。実はフレーム1358、1360の受渡しで、一回LMBはDMBの持つブラウズリストを入手しようとしたのだが、あまりにも巨大で用意していたバッファに収まらないため、改めてフレーム1364で取得要求を出し、1365、1372でその応答を受領している。このようにブラウズリストが巨大になると、内容は複数パケットに分けて送信されることになる。
このようにワークグループのブラウズリストを収集する過程で各セグメントに存在するワークグループの一覧も収集されるため、各セグメントに存在するワークグループの一覧も別セグメントのマスタブラウザに転送されている筈である。しかし、この情報は活用されずに捨てられてしまっているようで、統合されるのはDMBとLMBが所属するワークグループのブラウズリストの情報のみとなっている。
----- 注xx8: ネットワーキングガイドではP.125等では この間隔は15分となっているが、筆者が確認した限り12分である。なおWindows 2000 Server リソースキット TCP/IP ガイドのP.921-P.922 等では12分という数字もあるが、P.917では15 分ととれる記述もあり、混乱がみられる。 なおこの値はMasterPeriodicityというレジストリの値で調整できることを確認している。 ----- 写真xx5: DMBとLMBとの間の通信 (Blist-ex1.bmp) - (Blist-ex1.cap) 下部のペインに現れている文字列と実際のネットワーク情報とを突き合わせると、これはLMBがDMBに送信したLMBのセグメント内のワークグループの情報であることが推測される。 -----
ここまで述べて来たブラウズリストの統合を行うには、当然ブロードキャストだけでは行なえないため、適切な名前解決を行えることが前提である。
各セグメントのLMBは「ドメイン名<1B>」の名前解決が行える必要がある。もちろん後述するWINSを用いれば正しく解決できるが、LMHOSTSでも可能である。ただし、Windows NT/2000とWindows 9xでは多少異なる。Windows NT/2000では
x.x.x.x DOMPDC #PRE #DOM:DOMAIN
のようにLMHOSTS内でドメインのPDCを指定していれば、直接的に「ドメイン名<1B>」を指定する必要はない。しかしWindows 9xでは上記の指定だけでは不十分で、上記に加え以下のような記述をLMHOSTS に行い、明示的に「ドメイン名<1B>」の解決を有効にする必要がある。
x.x.x.x "DOMAIN \0x1B"(注xx8.5)
注xx8.5: LMHOSTSの文法に付いては前号を参照して欲しい
これはWindows NTでは NetGetDcName() というクエリを「#DOM」で指定した各ドメインコントローラに対して行うことで、ドメインコントローラの中からDMBを発見する実装になっているのに対して、Windows 9x の実装ではそれを行わないためである。本件も含め、LMHOSTSを用いて複数セグメント間でのブラウジングを行う際の注意点に付いては「J030016: [NT] TCP/IP および LMHOSTS ファイルを使用したドメインブラウジング」に詳細な記述があるので、是非ご参照頂きたい。
なお、マイクロソフトの技術情報中にはWindows 9xはLMBになれないという趣旨の情報もあるが、これは誤りでWindows for Workgroup 3.11を含め、LMBとして動作することは可能である(注xx9)。
----- 注xx9: ただし Windows for Workgroup 3.11 は TCP/IP 関連モジュールのアップデートが必要である。入手方法などに付いては J029995: [NT]Windows 95 は Windows NT のドメイン参照リストを共有できます を参照のこと。 また、Windows 9x および Windows NT 3.51 以前ではブラウズリストの大きさが64KB以内という制限があり、このため数千のコンピュータを含むブラウズリストを維持できない可能性がある。詳細に付いてはJ041306: [W95] ブラウズ マスタ の設定および、選定について 等を参照のこと。 -----
なお注意すべき点としてDMBの側でも各LMBの名前解決(LMBのコンピュータ名<20>)が行えることが必要であることがあげられる。これができない場合、LMBはDMBのブラウズリストを取得できるが、DMBではLMBのブラウズリストを取得できないという事象が発生する。
これは写真xx5に示したように、ブラウズリストの取得はプル型(注xx9.5)であるため、LMBの持つブラウズリストはDMB側から通信を開始して取得する必要があるためである。
----- 注xx9.5: プル(pull)型とは、情報を受信したい側から通信を開始する形式を意味する。反意語はプッシュ(push)型で、これは情報を送信したい側から通信を開始する形式になる。 -----
このため、LMHOSTSで複数セグメント間のブラウズリストを構築するためには、PDC側のLMHOSTSにはドメインの全てのポテンシャルブラウザ(注xx10)を登録するか、前号で記述したように各セグメントにBDCを配置する、IsDomainMasterというレジストリの値を1にする等してLMBとして動作するマシンを固定した上でそのマシンをLMHOSTSに記述する必要がある。
----- 注xx10: ポテンシャルブラウザに付いての説明は前号を参照して欲しい -----
実は前述したJ030016に明記されているが、LMHOSTSを用いたセグメント間のブラウズリストの構築について、マイクロソフト社としては「動作するがサポートはしない」というスタンスをとっている。LMHOSTSでブラウズリストの構築を行なう際には頭の片隅にいれておいて欲しい。
実際LMHOSTSを用いて規模の大きいネットワークのブラウズリストを維持するには、トラブルシューティングも含めるとWINS以上に知識とノウハウが必要であると考える。筆者の推測だが、LMHOSTSによるブラウジングのトラブルシューティングをサポートした場合の費用対効果を考慮した結果、このような扱いになったと考えている。
ここまでの説明を読むと、複数セグメント間のブラウズリストの統合には、ドメイン構成が必要のように思われる方も多いかも知れない。しかし実際のところ、必要なのはドメインでもPDCでもなく、ドメインマスタブラウザであることに注意して頂きたい。マイクロソフト社の実装では、DMBになれるのはPDCだけであるため、実質的にはドメイン構成が必要になる。しかし、例えばSambaのように非PDCかつDMBとして機能できるプロダクトを利用すれば、ドメイン構成でなくとも複数セグメント間のブラウズリストの統合が可能である(注xx11)。
----- 注xx11: SambaをDMBとして稼働させるにはdomain master = yes とする。なお、PDCとして稼働させるためのオプションはdomain logons = yesである。 ただし、Sambaのドキュメントでもドメインコントローラ機能とDMB機能とを別のマシンで運用することは決して推奨できないという記述があり、通常は同時にyesもしくはnoに指定する。 -----
LMBになるマシンもドメインのメンバである必要はない。所属するワークグループ名(ドメイン名)がDMBの所属するワークグループ名(ドメイン名)と合致していればよい。 つまり図xx4のような構成をとった上で適切な名前解決を行なえば、ドメイン構成をとらずとも複数セグメント間のブラウズリストの統合が可能となる。
-----
図xx4: 複数セグメント間のブラウズリストの統合の例
Seg1 Seg2
WG1-DMB WG1-LMB
Samba WG1ワークグループ(ドメインではない)に所属
domain master = yes
-----
なぜ「ワークグループは複数セグメントにわたって構成することができない」という言葉が正しいとも正しくないともいえるものなのか、ここまでの説明を理解して頂ければその答えは自明であると思う。
また、ブラウジングにおいて、「ドメイン」という概念は基本的に存在しないことも理解して頂けたと思う。ドメインマスタブラウザという非常に紛らわしい用語が用いられているため混同しやすいが、あくまでこれはブラウジング上の役割であり、NTドメインの機能とは本質的に関係ない。
実は、<ドメイン名1B>はドメインマスタブラウザの位置を示す以外にもブラウジングにおいて重要な役割を持っている。
通常、クライアントがマスタブラウザからブラウズリストを入手しようとする時は、「ワークグループ名<1D>」に対して通信を行うと説明したが、実はこの名前解決が失敗すると、「ワークグループ名<1B>」との通信を試みる。この様子再現するために図xx5のような環境で、MONYO65C2の起動直後のパケットをキャプチャしたのが写真xx6である。
-----
図xx5:
MONYO65C2(*1) -- [router] -- TS5_PDC
WINSクライアント WINSサーバ(*2)
TS5 ワークグループ
(*1) Microsoft ネットワーク共有サービスの「ブラウズマスタ」の値を「無効」にしているので、LMBになれない
(*2) 今回はWINS サーバをたてた環境で行なったキャプチャを掲載したが、MONYO65C2 に以下のような LMHOSTS ファイルを記述しておけば、WINS は不要である。
x.x.x.x "TS5 \0x1B"
x.x.x.x TS5_PDC #PRE
----
写真xx6:
(1B-Browse-3.bmp)
図xx5のようなネットワーク構成でMONYO65C2を起動直後のパケットをキャプチャしたもの。
-----
フレーム17までで前号までで述べた名前の登録やブラウズリストへの登録の試みを行なった後、フレーム18-20までTS5<1D>にブロードキャストを行なっているが、応答がないため、フレーム21-22でWINSサーバにTS5<1B>の名前解決を行ない、23-26でDMBからブラウザのリストを受け取り、27-28でブラウザの名前解決を行ない、これ以降でブラウズリストの入手を試みている。
これにより、「マイクロソフトネットワーク共有サービス」をインストールしていないWindows 9xから構成されたセグメントのように、セグメントにLMBが存在しない場合でも、個々のマシンがDMBにアクセスさえできればブラウズリストの入手が行えるが、半面問い合わせによるWANトラヒックの発生やISDNルータの発呼に留意する必要がある。
ここまでの知識を踏まえて複数のワークグループが複数のセグメントに存在している図xx6のような状況でのブラウズリストの構築を考えてみよう。
単一ワークグループに関しては、前述したように各セグメントのLMBがDMBと協力して、複数セグメントにわたるワークグループのブラウズリストを維持する。
このため、各セグメントのワークグループのLMBやDMBは、各々ワークグループ全体のブラウズリストを保持することになる。
またワークグループの存在は、やはり前述した15分毎のWorkgroup Announcementによりセグメント内の別のワークグループのマスタブラウザに伝達される。従って、図xx6のように、あるワークグループ(仮にWG1とする)と同一セグメント内に、複数セグメントにわたる別のワークグループWG2のLMB(もしくはDMB)があれば、WG1に所属するマシンは、WG2全体のブラウズリストを入手することが可能である。
しかし、WG2がブラウズリストの交換を行う際に、WG1の存在の情報は交換されない(実際には本文中で記述したように交換するが破棄される)ため、別セグメントにあるWG3からWG1のブラウズリストを参照することはできない。
-----
図xx6:
Seg1 Seg2
WG1 WG3
-- BrowseList -- -- BrowseList --
WG1-Seg1 のマシン WG3-Seg2 のマシン
WG2 ワークグループ WG2 ワークグループ
|
| --[Router]--
WG2 WG2
-- BrowseList -- -- BrowseList --
WG2-Seg1 のマシン WG2-Seg1 のマシン
WG2-Seg2 のマシン WG2-Seg2 のマシン
WG1ワークグループ WG3ワークグループ
-----
このように、通常は別ワークグループのブラウズリストを入手するためには、そのワークグループに所属するLMB(もしくはDMB)が存在していることが必要である。
実はコラムに書いたように、リモートセグメントのDMBと直接通信することで、リモートセグメントに存在するワークグループのブラウズリストを入手することは可能である。
しかし、LMHOSTSを用いてこれを行うのは、かなりトリッキーであり、実運用において決して勧められるものではないだろう。
また、コラムの通り、この通信は「ドメイン名<1B>」に対して行われるので、この方法を用いてもDMBでないマスタブラウザからブラウズリストを入手することはできない。
DMBはPDC以外なることが出来ないため、PDCの存在する、いわゆるNTドメインを構成するワークグループのブラウズリストしか入手できない(注xx12)。
----- 注xx12: 何度か記述しているようにSamba を用いてPDCでないDMBを別途構成するなどすればこの限りではない -----
|
=====
コラム: DMB以外でも別セグメントのDMBからブラウズリストを入手する方法 J030016の技術情報には、LMHOSTS中に以下のように「ワークグループ名<1B>」のエントリを記述した上でnet viewコマンドを発行することによりブラウジングを可能にする方法に付いての記述がある。しかしこれでは上記技術情報にも書かれているように、「ネットワークコンピュータ」から参照することが出来ないので、いわゆる「見える」状態とはとても言えないだろう。 図xx: LMHOSTS ファイルへの記述 x.x.x.x "Domain-Name \0x1b" 筆者も試行錯誤を行ったが、Windows NT Serverがローカルセグメントにあれば、DMB でなくてもLMHOSTSやWINSを用いてリモートセグメントにあるワークグループをブラウジングする方法を発見したので、この場を借りて紹介する。
|
このように適切な設定を行なうことで複数セグメント間でのブラウズリストの構築が可能となり、ワークグループに所属するマシンのリストが入手可能となる。ただし、当然のことながら、これはそれらのマシンの名前解決が可能であることを意味するものではない。
ワークグループWG1に所属するマシンが図xx7のように設置されている場合を考えてみよう。
----- 図xx7: LMB PC1 DMB PC2 | | | | +----------[router]---+-----+ -----
この場合、DMBとLMBの間で名前解決ができていれば、ブラウズリストのやりとりは可能であり、例えばPC1 からPC2がブラウズできる。しかしPC1 がWINS や LMHOSTS を利用してPC2 のアドレスを知らない限り名前解決はできない。従って、PC1 ではネットワークコンピュータにPC2 が見えているにも関わらず、クリックすると、「\\PC2にアクセスできません。ネットワークパスが見つかりません」というエラーが発生することになる。
なお、セグメント内でのブラウジング関連の通信は、基本的にブロードキャストで行なわれるため、名前解決の設定を明示的に行なう必要はないが、別セグメントのDMBからブラウズリストを入手するにはワークグループ名<1B>の名前解決が行なわれる必要がある。また前述したようにDMB と LMB とでブラウズリストの交換を行なうにはDMB がLMB<20> の名前解決を行なえる必要がある。
ここまでLMHOSTSを用いて複数セグメント間のブラウズリストを構築する方法に付いて述べて来た。また話を一般化するため敢えてPDCとDMBの機能を切り離し、DMB の機能だけを切り出して説明してきた。しかし実際のところ、WINSサーバやPDCだけに特有の機能も存在するようである。
これから説明する機能は、確かに複数セグメントにわたるブラウズリストの構築に非常に有用である。しかし実装の仕方がいかにも場あたり的で、結果的にはマイクロソフトネットワークの混迷をいっそう深めているというのもまた事実であると強く感じる。
以下、その点に付いて説明する。なお、一般にWINSサーバ設置のメリットとしてあげられるのがLMHOSTSファイル保守の負担軽減である。特にDHCP環境においては動的に付与されるIPアドレスの名前解決手段としてWINSのメリットは大きいが、名前解決自体はLMHOSTSでも可能であるため、ブラウジングの機能に関して言えば、WINSによる動的な名前解決の実現は、本質的な違いではない。
Windows NTのDMB(つまりはPDC)とWINSを使うと簡単にできることに、別セグメントにあるワークグループのブラウジングがある。ただし別セグメントのワークグループはDMBが存在するもの、つまり通常はいわゆるNTドメインに限られる(注xx)。別セグメントに存在するDMBの存在しないワークグループのブラウジングはWINSを用いても不可能である。
----- 注xx: これはDMB のみが ワークグループ名<1B> を登録し、リモートからのブラウズリストの取得要求に答えることが出来るからである。 -----
ネットワーキングガイド P.379に解説があるように、WINSクライアントとなっているWindows NT 3.51以上のマスタブラウザは定期的にWINS サーバに接続し、WINSサーバが保有するドメイン名<1B>のリストをブラウズリストに追加していく。このため前述したような<01><02>__MSBROWSE__<02><01> へのWorkgroup Announcement を用いずに、別セグメントのワークグループの存在を認識でき、セグメント内の別ワークグループと同様にしてクライアントからの要求に答えることが可能である。図xx の状況でDOM_EARTHドメインのPDCの起動直後のパケットを写真xxに示す。
フレーム379までは今まで述べて来た名前の登録などである。フレーム383 から397まで、MSRPCを用いて直接WINS サーバとの間で通信が行なわれており、フレーム397を見ると、ワークグループ名の一覧を確認できる。セグメント1に存在しているWATER_FIRE ワークグループの名前が確認できる。もちろんネットワークコンピュータアイコン上でも3つのワークグループのアイコンが確認できる。
-----
図xx:
Seg1 (192.168.1.0/24) Seg2 (192.168.2.0/24)
WIND_EARTH DOM_EARTH
WINS サーバ
WINSSV GNOME_SV_4_2
(WIND_EARTH ドメインPDC) (DOM_EARTH ドメインPDC)
|
| --[Router]--
WATER_FIRE WIND_EARTH
WATER_FIRE ドメインPDC WIND_EARTH ドメイン(*) メンバサーバ
(*)すべてのマシンはWINS クライアント
(*) ネットワークモニタを取得する関係上存在しているが、リモートセグメントのブラウズリスト取得上は無関係である。実際このマシンを停止した状態でも同様にブラウズリストが取得できることを確認している。
-----
写真xx:
(WINS-PDC.bmp) - WINS-PDC2.cap
-----
NBT を利用せず、WINS サーバとMSRPC を利用して直接通信を行なうのが特徴である。
ただし、当方が確認した限り、この通信を行なう場合ローカルセグメントのマスタブラウザもDMBである必要がある。従って、コラムに書いた方法を用いない限り、ワークグループからは別セグメントのワークグループのブラウジングは出来ない。
前回で述べたようにセグメント内のブラウズリストの維持は、マスタブラウザとの通信や、ブラウザ選定などにおいて、ブロードキャストを多用することによって行われる。一方前々号ではWINSクライアントは起動時にWINS サーバに名前の登録を行なうことも説明した。
しかしこの仕様には問題がある。図xx8の環境を考えてみよう。
-----
図xx8:
ワークグループWG1のLMB
MB1
|
+-----[Router]------+---------------+
| |
WINS ワークグループWG1 のLMB
サーバ MB2
-----
MB1もMB2もセグメント内ではWG1のマスタブラウザであるため、WG1<1D>という名前をWINSに登録してしまう。これではどちらかの登録が失敗することになり、ブラウジングがうまく行かない。同様のNetBIOS名にワークグループ<1E>(注xx12.3)や<01><02>__MSBROWSE__<02><01>(注xx12.5)もある。
----- 注xx12.3: ワークグループ<1E> はブラウザ選定の際のブロードキャストの宛先。詳細は前号を参照のこと ----- 注xx12.5: <01><02>__MSBROWSE__<02><01> は同一セグメント内に存在するワークグループ間で互いに存在を知らせあうためにブロードキャストする宛先。詳細はP.xxx を参照のこと。 -----
これらはブラウジングの仕様上セグメントにブロードキャストすることによって名前解決される必要があるため、WINSに登録することは望ましくないのだ。これらの名前に関して、Microsoftネットワークではトリッキーな動作を行なうことで対応している。
まず、WINSサーバはこれらの名前の登録に付いては、常に肯定応答を行なう。つまりクライアントから見ると名前の登録は正常に行なわれる。WINSサーバ上で見ても正しく登録されているように見える。これをキャプチャしたのが写真xx7である。フレーム7,8、11,12、12,14等でブロードキャストで解決されるべき名前の登録が行なわれている。
しかし、これらの名前解決をWINS で行なうと問題が発生するため、ネットワーキングガイド等を見ると、これらの名前解決の要求をWINS サーバに行なうと、WINS サーバは常に名前が存在しないという否定応答を示すことによって、結果的にブロードキャストによる名前解決を行なうという記述がある。
これを確認しようとして実験を行なったが、実際にはクライアントはこれらの名前をWINSに問い合わせることなく常にブロードキャストを行なうため、確認できなかった。いずれにしてもこうした仕様により、ブラウジング関連のパケットはセグメントにブロードキャストされ、ブラウジングが正しく機能することになるのである。
まさに仕様の矛盾に対処すべく、場あたり的に対応した仕様と言えよう。
文献による調査と実験結果を突き合わせると、「インターネットグループ名」という特殊なグループ名を除く、すべてのNetBIOSグループ名と、ブラウジングが動作する上でブロードキャストすることが必要な「ワークグループ名<1D>」のNetBIOSユニーク名がこの動作の対象となる筈である(注xx12.7)
----- 写真xx7: (WINS-REGIST.bmp) - REGIST-WINS.cap フレーム8 <01><02>__MSBROWSE__<02><01> やフレーム12 WORKGROUP_2<1D> も WINS サーバから登録成功のメッセージが返却されている点に注意。 ----- 注xx12.7: 実際に確認しているのは <01><02>__MSBROWSE__<02><01>、ワークグループ名<1D>、ワークグループ名<1E>、ワークグループ名<00>である。 -----
直観的には非常に分かりにくい表現であるが、ネットワーキングガイドのP.737の各NetBIOSグループ名の説明中でも、ここでもNetBIOS 名の識別子が<1D>,<1E> の場合や、<01><02>__MSBROWSE__<02><01> の場合はブロードキャストで名前解決を行なうという記述がある。
最後に複数のプロトコルが存在している場合について説明しよう。
複数プロトコルが存在している環境では、プロトコル毎にマスタブラウザが存在し、そのプロトコルのブラウズリストの維持を行う。
例えばワークグループWG1では NetBEUIとNBTが利用されていたとすると、WG1ではNetBEUIでのマスタブラウザとNBTでのマスタブラウザとが存在することになる。
もちろん一台のマシンが各プロトコルのマスタブラウザの役割を兼任する可能性は充分考えられる。実際全てのマシンが各プロトコルを利用している場合は、先ほど説明したブラウザ選定の仕組み上、必ず1台のマシンが全てのプロトコルにおけるマスタブラウザの役割を兼任する筈であり、大きな問題は発生しないが、ブラウザ選定などのブラウジング関連のトラヒックは各プロトコル毎に発生するので、決して推奨される環境ではない(注xx13)。
----- 注xx13: NBTでの名前解決に要する時間自体もNetBEUI,IPX/SPX,TCP/IPが入っていてTCP/IP が一番低い優先順位の場合、実測で10秒以上かかる場合がある。 -----
また一部のPCには一部のプロトコルしかインストールされていない場合は非常に複雑である。
----- 図xx9: PC1 PC2 PC3 NetBEUI TCP/IP & NetBEUI TCP/IP | | | +---------+---------------------+ -----
図xx9でPC2 がPC1,PC3 よりブラウザ選定基準が高く、マスタブラウザになっている場合、PC2 のネットワークコンピュータからはPC1,PC2,PC3がブラウズ出来るが、PC3 からはPC2 とPC3。PC1 からはPC1 と PC2 しかブラウズ出来ない。
なお、筆者は利用したことがないので具体的な動作は不明であるが、ネットワーキングガイドなどを読む限り、IPX上のNetBIOSを利用している場合は、NBTとは異なりブラウジング機能に関して各セグメント間のルータはブリッジ的に動作するため、ルーティングされたIPX 環境全体でブラウズリスト的には1つのセグメントを構成し、1台のマスタブラウザが選定される。
以上、ブラウジングに付いて考えられる状況を一通り全て記述したつもりである。
ネットワーク上に存在するコンピュータの一覧とその属性を入手するためのブラウジングであるが、以下に不安定で複雑な仕組みの上になりたっているかを理解して、今後のトラブルシューティングに役立てて頂ければ幸いである。
次回はマイクロソフトネットワークのセキュリティがどのようにして構成されているか、ドメイン構成にすることは、セキュリティ的にどういう意味を持つものなのかに付いて記述して行く予定である。