第19回 NetBIOS over TCP/IPプロトコル（その2）：基礎から学ぶWindowsネットワーク（2/4 ページ）
ネットワーク環境
実際のプロトコル例を見る前に、パケットをキャプチャしたネットワークの構成について説明しておく。
今回取り上げるNBTプロトコルの例は、サーバ1台、クライアント1台という非常にシンプルなネットワーク構成でキャプチャしている。2台のマシンを以下のように設定し、サーバ側でWindows Server 2003付属の「ネットワーク モニタ」でパケットをキャプチャした。ネットワーク・モニタの使い方については別稿の「Windowsネットワーク・プロトコルの理解と検証」を参照していただきたい。
| サーバ | マシン名 | SERVER | |
| OS | Windows Server 2003 | ||
| IPアドレス | 172.16.1.2/255.255.255.0 | ||
| サービス | DNS／WINSサーバ | ||
| ワークグループ名 | WORKGROUP | ||
| DNSドメイン | d-advantage.jp | ||
| クライアント | マシン名 | PC1 | |
| OS | Windows XP Professional | ||
| IPアドレス | 172.16.1.101/255.255.255.0 | ||
| TCP/IP設定 | DNS／WINSはSERVERを参照 | ||
| テスト環境 | |||
この2台をネットワークで接続し、ワークグループ構成のWindowsネットワークを構築している。NBTの挙動は、WINSサーバがある場合とそうでない場合で少し違いがあるので、以下では両方の環境でそれぞれどうなるかを示している。
ブロードキャスト環境におけるシステム起動時の名前登録
最初に、ブロードキャスト環境（非WINS環境）における、システム起動時のNetBIOS名登録のシーケンスについて見ておく。
NetBIOSのサービスを利用して通信する場合、各マシンには必ず「NetBIOS名」が付けられている必要がある。通信相手を特定する場合は、IPアドレスやMACアドレスではなく、このNetBIOS名が利用されるためである。このNetBIOS名は、一般的には（管理者などによって）各マシン単位に固定的に割り当てられているように思われるが、実際には、システムの起動時に各マシンごとに動的に割り当てるようになっている。つまり、あらかじめ割り当てられたNetBIOS名を、システムの起動時にネットワークにブロードキャストしたり、WINSサーバに登録したりし、それが認められて初めて正式なマシン名として許可されるということである。これが認められなければWindowsネットワークに参加することができず、サービスを提供するだけでなく、ほかのマシンのサービスを利用することもできない（ただし最近のWindows OSではDirecto Hosting SMBプロトコルにより、外部のリソースを利用するだけなら可能になっている）。この点が、IPアドレスさえ割り当てられれば動作するTCP/IPとは大きく異なる。
システムは起動直後、通常は4つのNetBIOS名を「登録」するための通信パケットをブロードキャストで送信する。登録とは具体的には、NetBIOS名の使用をほかのマシンに対して宣言することであり、名前が衝突していなければ、その名前の使用が認められたものとして、自分自身のNetBIOS名前キャッシュに登録する。もしそのNetBIOS名がすでにほかのマシンで使用中であれば、先に使用していたマシンは、登録要求のブロードキャストに対して、やはりブロードキャストで名前が衝突しているという旨を主張する。このあたりのやりとりについては、連載第4回の「2．NetBIOS名前サービスを使った名前の登録 」などを参照していただきたい。
今回のネットワーク環境では、システム起動時には次のような4つのNetBIOS名が登録される。
| リソース・タイプ | ユニーク／グループ | 実際の値 |
|---|---|---|
| 00（ワークステーション・サービス） | ユニーク | PC1<:00> |
| 20（ファイル・サーバ・サービス） | ユニーク | PC1<20> |
| 00（ワークグループ名） | グループ | WORKGROUP<00> |
| 1E（ブラウザ・サーバ／ポテンシャル・ブラウザ・サーバ） | グループ | WORKGROUP<1E> |
| システム起動時に登録される4つのNetBIOS名 一般的なクライアント用途のPCでは、システム起動時にはこのような4つのNetBIOS名が登録される。値の最後にある<00>や<20>、<1E>はNetBIOS名の16byte目の値（16進数表記）であり、リソースの種類を表す。上の2つは、ファイル・サービスのクライアントとサーバのサービスをそれぞれ表し、下の2つは所属しているワークグループ名と、「ポテンシャル・ブラウザ」サービスが利用できることをそれぞれ表す。「ブラウザ」については今後の連載で解説予定。リソース・タイプについては連載第4回の「1．NetBIOS名とは何か？」を参照のこと。 | ||
NetBIOS名のリソース・タイプには、「ユニーク」と「グループ」という2つの種類があるが、このうちユニークなものはどれか1台のマシンしか登録することができない。重複して登録しようとするとエラーとなる。これに対してグループ名は、複数のマシンが登録してもエラーとはならない。この例で分かるように、ワークグループ名（ドメイン名でも同じ）は、同じワークグループ（ドメイン）に属するすべてのマシンが共有している。これにより、同じワークグループに属するコンピュータ同士が情報を共有し、例えばエクスプローラのネットワーク表示において、同じワークグループ名の下に一覧表示されるなどの機能を実現している。
ここで登録されたNetBIOS名は、各マシンの中にあるNetBIOS名キャッシュに記録されるが、この様子は「nbtstat -n」（自マシンの場合）コマンドや、「nbtstat -a <IPアドレス>」（リモート・マシンの場合）などで確認することができる。
C:\>nbtstat -n
Local Area Connection:
Node IpAddress: [172.16.1.101] Scope Id: []
NetBIOS Local Name Table
Name Type Status
---------------------------------------------
PC1 <00> UNIQUE Registered
WORKGROUP <00> GROUP Registered
PC1 <20> UNIQUE Registered
WORKGROUP <1E> GROUP Registered
それではシステム起動時の実際のパケットのやりとりをみてみよう。通信はすべてブロードキャストで行われていることが分かる。パケットの送信先IPアドレスが「172.16.1.255」という、「ディレクティッド・ブロードキャスト」となっている（ブロードキャストの種別については連載第8回「3．さまざまなIPアドレス」を参照）。ブロードキャストにはこのほかにも255.255.255.255という「リミテッド・ブロードキャスト」もあるが、NBTにおけるブロードキャストでは（一般的なアプリケーションでも）、このようにディレクティッド・ブロードキャストが利用される。同じ物理ネットワーク上に、ネットワーク・アドレスが異なる複数の論理ネットワークが存在する場合でも、ある特定の論理ネットワークに属するマシンのみを通信対象とするためである。
システム起動時のNetBIOS名の登録（ブロードキャスト環境）あるクライアント・マシンが起動する場合のNetBIOSの登録パケットの様子（非WINS環境）。ワークグループWORKGROUPに属しているPC1というマシンが起動すると、このようなパケットがブロードキャスト送信されている。なお、途中にある「BROWSER Host Announcement」というブロードキャストは、NetBIOS名の登録ではなく、ブラウザに対するホスト名の登録要求。詳細は今後解説する。
（1）ノード・タイプ<00>のPC1という名前はワークステーション・サービス。
（2）ノード・タイプ<00>のWORKGROUPは、所属しているワークグループ名（ドメイン名）を表す。
（3）ノード・タイプ<20>のPC1という名前はサーバ・サービス。最後の<20>は空白文字と同じなので、このネットワーク・モニタでは表示されていない。
（4）ノード・タイプ<1E>のWORKGROUPは、このワークグループのブラウザ候補を表す。
（5）これは172.16.1.0/255.255.255.0というネットワーク上の全マシンに対するブロードキャスト通信。非WINS環境では、NetBIOS名の登録や検索などはすべてブロードキャストによって行われる。
この例では、同じ登録要求パケットが4回ずつ送信されているが、これは通信を確実に行うためである。1回しかパケットを送信しないと、ほかのマシンがパケットを取りこぼしたり、処理中ですぐには応答できなかったりする場合があるからだ。何度か繰り返して送信することにより、確実にほかのマシンにパケットが届き、その応答が得られるようになる。もちろん現在の高性能なマシンではそのような心配はないだろうが、ネットワーク・プロトコルというものは往々にして、このように過去との互換性を重視して、昔のやり方をそのまま踏襲するようになっている。
WINS環境におけるシステム起動時の名前登録
上の例は、ブロードキャストのみの環境における名前登録例であったが、次はWINSサーバを利用している場合の通信例について見てみる。
ブロードキャストを利用した名前登録は、NetBEUIしか利用できなかった初期のWindowsネットワーク環境との互換性のために存在しているが、現在のNBT環境では、WINSサーバを利用したNetBIOS名の管理が一般的である。WINSはNetBIOS名を集中的に管理するためのネーム・サーバ・テクノロジである。WINSサーバを利用することにより、ネットワーク上のブロードキャストの必要性をほとんどなくすほか、複数のWINSサーバを連携させて、単一の論理ネットワークだけでは実現不可能な、大規模なネットワークを構築することができる。非WINS環境では、ブロードキャストが届かなければ名前解決することができなかったが、WINSサーバと通信することさえできれば、IP的に離れた場所にあるネットワークやマシンと通信することができるようになった。
WINSサーバが存在する場合は、名前の登録や解決は非常にシンプルなものとなる。いままでブロードキャストで行っていた操作に代わり、WINSサーバに登録や問い合わせのパケットを送信するだけで処理が完了するからだ。ネットワークを混雑させる原因となるブロードキャストの必要性がなくなるので、WINSサーバの使用は、ネットワーク的にも望ましいといえる（ただし過去との互換性や、非WINSクライアントなどとの相互運用性のため、いくつかのパケットはブロードキャストでも行われるので、ブロードキャストがまったくなくなるわけではない）。
以下にシステム起動時の具体的な通信の例を示しておく。上の例と違って、このクライアント・マシン（PC1）では、WINSサーバのIPアドレス（SERVER）が指定されており、名前の登録やクエリはすべて、ブロードキャストではなく、WINSサーバに対して行われていることが分かる。しかもネットワークのトラフィックが少なくなるだけでなく、NetBIOS名の登録が完了するまでの時間も、先の例では約20秒かかっていたのが、こちらはわずか2秒程度にまで短縮されている。無駄なタイムアウト待ちなどをする必要がなくなったからだ。
システム起動時のNetBIOS名の登録（WINS環境）あるクライアント・マシンが起動する場合のNetBIOSの登録パケットの様子。非WINS環境では登録要求をブロードキャストして、それに対する異議申し立て（競合の通知）がなければ登録が認められたものとしていたが、WINS環境では、名前の登録や許可／拒否はすべてWINSサーバ側で行われる。そのためWINSサーバに対する問い合わせの送信と結果の受信だけで処理が完了する。
（1）ワークステーション・サービス（PC1<00>）の登録要求をWINSサーバへ送信すると、許可されたという応答（「Success」応答）が戻ってきた。
（2）ワークグループ名（WORKGROUP<00>）の登録要求とそれに対する許諾応答。
（3）サーバ・サービス（PC1<20>）の登録要求とそれに対する許諾応答。
（4）所属しているワークグループ名（WORKGROUP<1E>）の登録要求とそれに対する許諾応答。
（5）すべての通信は、PC1とSERVER間のユニキャスト通信（1対1の通信）で行われている。
DNS更新要求
これはNetBIOSの通信モデルとは直接関係ないことだが、Windows 2000以降のWindows OSでは、システムの起動時にDNSサーバに自分自身を登録するという「動的更新」の機能が用意されている。それ以前のWindowsネットワークでは、マシンの名前解決にはNBTプロトコルやWINSのみが利用されていたが、Windows 2000以降では、Active Directoryとの連携なども行うため、DNSサービスと融合した名前空間の管理アーキテクチャが導入されたのである。
NT以前のWindowsネットワークでは、多数のマシンを「ワークグループ」や「（NT）ドメイン」というグループに分類して管理することができたが、これは階層構造がとれないため、マシンの数が多くなると管理がしづらいという難点があった。これに対してActive Directoryでは、ネットワーク全体を階層的なツリー構造（階層的な名前空間）に分割して管理する機能が導入された。そこで重要な意味を持つのがDNSサービスである。
DNSは、もともとはインターネットの世界で、コンピュータやドメインの名前空間を階層的に構築・管理するために作られたものである。Active DirectoryではこのDNSを利用して、Active Directoryドメイン階層内のコンピュータ名などをDNSの名前空間にマッピングして利用している。このためActive Directoryを利用する場合は、各コンピュータ名などがDNSサービスでもアクセスできるようになっていると都合がよい。そこで導入されたのがDNSの動的更新機能を使ったコンピュータ名のDNSサーバへの自動登録である。Windows 2000以降のOSでは、この動的更新機能がデフォルトでオンになっている。
DNSの動的更新が有効になっている場合、システムの起動時には、NetBIOSの名前登録に加えて、DNSサーバに対する更新要求の送信も行われる。具体的には以下のように、そのマシン名のFQDN名に対して、DNSエントリの更新要求が送られる。DNSサーバでは、ドメインの「正引き（FQDN名からIPアドレスを求めること）」のほかに「逆引き（IPアドレスからFQDN名を求めること）」も管理しているため、それぞれのゾーンに対して更新要求が送信されている。
DNSの動的更新要求Windows 2000以降のWindows OSでは、システム起動時に自身のIPアドレスをDNSサーバに登録する。これにより、たとえIPアドレスが変わっても、ほかのクライアントから正しくアクセスすることができるようになる。
（1）PC1.d-advantage.jpという正引きのエントリが登録されているかどうかの確認。DNSサーバに対する送信と応答で1パケットずつになっている。
（2）PC1.d-advantage.jpに対する動的なIPアドレスの更新要求。
（3）101.1.16.172.in-addr.arpaという逆引きのエントリが登録されているかどうかの確認。
（4）101.1.16.172.in-addr.arpaに対する動的なコンピュータ名の更新要求。
DNSの動的更新機能を利用することにより、例えばマシンの再起動でIPアドレスが変わってしまっても（IPアドレスをDHCPサーバで管理していると、このようなことが起こる可能性がある）、新しいIPアドレス情報がDNSサーバに反映されるようになる。だがDNSにこのような動的更新を許可していない場合は、この機能を禁止することもできる。詳しくはWindows TIPS「DNSの動的更新を無効にする」を参照していただきたい。
Copyright© Digital Advantage Corp. All Rights Reserved.
注目のテーマ
ITmediaはアイティメディア株式会社の登録商標です。