[Chapter 1] 1.3 SMB/CIFS ネットワークに詳しくなるために

1.3 SMB/CIFS ネットワークに詳しくなるために

ここまで読んだ方は、Sambaについての要点を理解しただろう。ここでは、Sambaにより実現された環境である: SMB/CIFSネットワークについて詳しくなるために時間を頂きたい。SMBによるネットワークは、UnixのTCP/IPによるネットワークとは異なった動作をしている。それゆえに、新しい幾つかの学ぶべき概念と多くの理解すべき情報がある。まずは、Microsoft による SMB の実装をいくつか見ていきながら、SMB ネットワークの背後にある基本的な概念について議論する。その後で Samba サーバを組み込める状況と組み込めない状況を提示しよう。

1.3.1 NetBIOSを理解する

始めに、過去に遡る必要がある。1984年にIBMが、自社のコンピュータにネットワーク機能を持たせるために、 Network Basic Input/Output System (NetBIOS)と呼ばれる、簡単なアプリケーションプログラミングインターフェイス(API)を提唱した。NetBIOS APIは他のコンピュータと接続してデータ共有するアプリケーションのための基本的なデザインを提供していた。

NetBIOS APIを標準BIOS API呼び出しにネットワーク機能を拡張したものと考えるとよいだろう。BIOSにおいては、低レベルの呼び出しはローカルマシンのハードウェアに限定されており、呼び出し先への到着する過程で如何なる助けも必要としない。しかしながら、NetBIOSでは、もともと命令をIBM PCネットワーク、トークンリングネットワークを経由しコンピュータ同士で交換しなければならなかった。それゆえに、コンピュータから次のコンピュータにリクエストを運ぶために、低レベルの搬送プロトコルが必要とされた。

1985年の後半に、IBMは一つのプロトコルをリリースした。それは、NetBIOS APIを元にして NetBIOS Extended User Interface (NetBEUI)のために拡張するものであった。NetBEUIは、小規模なlocal area networks(LAN)のために設計され、それぞれのマシンが、ネットワークにおいて重複しない名前(最大15文字)を要求するものであった。"小規模LAN"という言葉の意味は、1985年時点で実践的な制限と考えられていた、ネットワーク上のマシンが255ノード以下ということである。

NetBEUIプロトコルは、Windows for Workgroups環境で動作するネットワークアプリケーションで非常に受け入れられた。後に、NovellのNetBIOS over IPXネットワークプロトコルの実装も行われた。これはNetBEUIと競合するものであった。しかしながら、初期のインターネットコミュニティで選択されたネットワークプロトコルはTCP/IP、UDP/IPであって、すぐにNetBIOS APIをそれらのプロトコル上に実装する必要が生じた。

NetBIOSでは名前しか使用しないが、TCP/IPでは例えば192.168.220.100のように、それぞれのコンピュータにアドレス番号を割り当てることを思い出して欲しい。この事が2つのプロトコルを整合させようとする際に大きな問題になった。1987年にInternet Engineering Task Force (IETF)により標準化文書が発行された。これはRFC1001、RFC1002とタイトルが付けられている。この文書で、どのようにNetBIOSがTCP/UDPネットワーク上で動作するかあらましが述べられている。この一組の文書は、今日存在している Sambaシステムと同様にMicrosoftにより提供されるWindowsオペレーティングシステムの実装を未だに規定している。

これ以後、この文書により規定された標準が NetBIOS over TCP/IP、略してNBTとして知られるものとなった。現在、NBT標準(RFC 1001/1002)でネットワーク上のサービスの3つのあらましが述べられている:

一つの名前解決サービス
2つコミュニケーションサービス:
- データグラム
- セッション

名前解決サービスによって、前述した名前-アドレスの変換の問題が解決された。;それにより、それぞれのコンピュータがネットワーク上でマシンに理解出来てIPアドレスに変換可能な特定の名前を宣言することが可能となる。インターネットで現在使用されているDNSのようなものである。データグラムとセッションサービスは、共にネットワーク上のNetBIOSマシンからのデータを送信したり、送信をやり直したりするのに使われる2次的なコミュニケーションプロトコルである。

1.3.2 名前を取得する

人間にとっては名前を知ることは容易なことである。しかし、NetBIOSネットワーク上のマシンにとっては少々複雑な問題となってくる。ここで、いくつかの問題点を検討する。

NetBIOSの世界では、各マシンがネットワークに参加する際に自分自身の名前を宣言することが必要である;このことは 名前登録と呼ばれている。しかしながら、同じワークグループに所属するマシン同士の間で、同じ名前を宣言することはあってはならない;同じ名前を宣言してしまうと、その名前のマシンとコミュニケーションを行おうとするマシンにとって決して解決されることのない混乱が起きてしまうだろう。このことを起らないようにするための2つの異なった手法が存在する:

NetBIOS Name Server (NBNS)を使用して、ホストが登録したNetBIOS名を記録する。
ネットワーク上のそれぞれのマシンが、他のマシンが同じ名前を使おうとした際に、その名前を登録出来ないようにすることを可能とする。

図 1.8NetBIOS名前解決サーバが、ある場合とない場合において、名前登録が失敗している様子を示している。

図 1.8: NetBIOS名前解決サーバを使用した名前登録対 NetBIOS名前解決サーバを用いない場合の名前登録

更に、上記したようなNetBIOS名をIPアドレスに変換する方法が必要である。;この事は 名前解決と呼ばれている。同様にNBTでは、異なった2つの方式が取られている:

NetBIOS名を問い合わせるブロードキャスト要求を各マシンが"聴取する"際に、各マシンがIPアドレスの返答を行なう。
NetBIOS名をIPアドレスに変換する際にNBNSを使用する。

図 1.92つのタイプの名前解決の方式を図説している。

図 1.9: NBNSを用いた名前解決とNBNSを用いない名前解決

予想通り、NBNSをネットワーク上に配置することは非常に有用である。なぜそうなるかキチンと理解するためにNBNSを用いない手法について見てみることにしよう。

クライアントが起動する際に、自身の特定のNetBIOS名を登録するためのメッセージをブロードキャストする。名前の登録が試みられてから、他のマシンがその名前を使用していなければその名前を使用できる。一方、ローカルサブネット上の他のマシンが、その時点で要求された名前を使用していた場合には、その名前は既に使用中であると要求を行なったクライアントにメッセージが返答される。この方法は、ホスト名を重複登録を防ぐ方法として知られている。この方法を用いるシステムでは、クライアントが予期せずにネットワークで停止した場合でも、他のマシンがその名前を問題なく取得できる。ただし、簡単な名前登録にでさえ、ネットワークのトラフィックが過度の量になってしまう。

NBNSを用いて同様の事が可能である。ただし通信はリクエストを行なったマシンとNBNSサーバにのみ限定される。マシンが名前登録を行なう際にブロードキャストは行なわれない。;登録を行なうためのメッセージは、単にクライアントからNBNSサーバに直接送信されて、リクエストを行なった名前が既に使用されているかされていないかNBNSサーバより応答が行なわれる。これは ポイント-ポイント通信と呼ばれており、一つ以上から構成されるサブネットを持つネットワーク環境で有益である。これはルータにより、サブネット上のすべてのマシンへのブロードキャストを行なう内方向へのパケットをフィルタリングするように予め設定されていることがあるからである。

同じ原則に基づいて名前解決が行なわれる。NBNSがない環境では、NetBIOS名前解決はブロードキャスト機構を用いて同様に行なわれるだろう。リクエストパケットは、問い合わせを行なったマシンにリクエスト先のマシンから応答があるだろうと期待されて、ネットワーク上のそれぞれのコンピュータに送られる。この時点で、NBNSサーバとポイント-ポイント通信を名前解決に用いることにより、ネットワークを名前解決リクエストのブロードキャストで溢れ返らせるよりも遥かに少ないトラフィックでネットワークを運用できることが明らかである。

1.3.3 ノードタイプ

名前登録と解決を実行する際にそれぞれのクライアントがネットワーク上でどのような戦略を取るか説明出来るだろうか?。NBTネットワーク上のそれぞれのマシンでは、如何にして名前登録と解決を行なうか決定するための方法を取得するための設計図を持っている:それは、b-node、p-node、m-nodeとh-modeである。それぞれのノードのタイプの挙動の仕方は表 1.1に示されている。

表 1.1: NetBIOS ノードタイプ
役割	値
b-node	ブロードキャストによる名前登録と解決のみ使用する。
p-node	ポイント-ポイント通信による名前登録と解決のみ使用する。
m-node	ブロードキャストによる名前登録を使用する。成功すると、NBNSサーバに結果を通知する。名前解決にブロードキャストを使用する。;ブロードキャストによって解決出来なかった場合にはNBNSサーバを使用する。
h-node (hybrid)	名前登録と解決にNBNSサーバを使用する;NBNSサーバから応答がない場合やサービスが実行されていない場合にはブロードキャストを使用する。

Windowsクライアントの場合には、通常 h-nodes つまり hybrid nodesを使用しクライアントの一覧を取得する。ちなみに、h-nodeはより堅牢な方法としてMicrosoftによって後に拡張されたものである。RFC 1001/1002には記述されていない。

ipconfig /allとコマンドラインからタイプしノードタイプを記述している行を探すことによってWindowsマシンのノードタイプを知ること出来る。

C:\> ipconfig /all

Windows 98 IP Configuration
...
  Node Type .  .  .  .  .  .  .  .  .  .  : Hybrid
...

1.3.4 名前の構成方式

NetBIOSで使用する名前は、よく知っているだろうDNSホスト名とまったく違ったものである。まず、NetBIOS名はフラットな名前空間である。別の言葉で言えば、ora.comやsamba.orgのようなホスト名を区分するための修飾子は存在しない;各マシンは、単一でユニークな名前から構成される。次に、NetBIOS名は15文字以内に制限されていて、アスタリスク(*)文字から始まることはない。さらに、標準的なアルファベット文字(a-z、A-Z、0-9)と次に示す文字のみから構成される:

! @ # $ % ^ & ( ) - ' { } . ~

NetBIOS名では、ピリオド(.)を使うことが許されているけれども、将来のバージョンのNetBIOS over TCP/IPで動作することは保証されていないので、使用することを推奨しない。

全てのDNS名が、また同様にNetBIOS名に一致することはない。実際に、SambaサーバでのDNS名がNetBIOS名として再利用されることが多い。例えばphoenix.ora.comと云うマシンがあるとしよう。このマシンのNetBIOS名はおそらくPHOENIX(空白文字が8文字続く)となるだろう。

1.3.4.1 リソース名とタイプ

NetBIOSでは、各マシンは自身の存在を宣言するだけでなく、他のマシンに自身がどのようなサービスを提供するか宣言する。例えばphoenixは、単なるワークステーションでなくてファイルサーバでWinPopupメッセージを受信できる事を示すことが出来る。これは、マシン(リソース)名の終りの部分に、リソースタイプと呼ばれる16バイト目の情報を加えることによって行なわれる。更に名前の登録は何度も行なわれる。図 1.10を見て欲しい。

図 1.10: NetBIOS名の構造

1バイトからなるリソースタイプで、名前を持っているマシンにより提供される一意なサービスが表現される。本書では、NetBIOS名の後で不等号で区切られて(<>)表されるリソースタイプをしばしば見ることになる。例えば、次のようになる:

PHOENIX<00>

それぞれのNBTマシンにどのような名前が登録されているか、WindowsのコマンドラインからNBTSTATユーティリティを使うことによって知ることが出来る。これらは、一意に決まるサービスなので(すなわち、一つ以上登録されることはない)ので、出力で一意なタイプの一覧を知ることが出来る。例えば、以下に示す部分の出力では、hydra サーバについて記述されている:

D:\> NBTSTAT -a hydra

       NetBIOS Remote Machine Name Table
   Name               Type         Status
---------------------------------------------
HYDRA          <00>  UNIQUE      Registered
HYDRA          <03>  UNIQUE      Registered
HYDRA          <20>  UNIQUE      Registered
...

この出力によって、サーバにはマシン(ワークステーション)名としてhydraというNetBIOS名が登録されていて、WinPopupメッセージを受け取ること出来て、ファイルサーバである事が分かる。それぞれの名前に付随するリソースタイプの属性の幾つかを表 1.2.に示した。

表 1.2: NetBIOS名に割り与えられるリソースタイプ
リソース名	16進数で表される値
標準ワークステーションサービス	00
メッセージサービス(WinPopup)	03
RASサーバサービス	06
ドメインマスタブラウザサービス(プライマリドメインコントローラとして構成される)	1B
マスタブラウザ名	1D
NetDDEサービス	1F
ファイルサーバ(プリントサーバを含む)	20
RASクライアントサービス	21
ネットワークモニターエージェント	BE
ネットワークモニタユーティリティ	BF

DNS名ではリソースタイプを持っていないために、設計者は意図的に16進数の20(アスキー文字のスペース)をファイルサーバの値のデフォルトとした事を知っておいて欲しい。

1.3.4.2 グループ名とタイプ

SMBには、各マシン自身の登録先としてグループの概念も導入されている。前述した例では、マシンは ワークグループに所属すると述べた。これは同じネットワークに所属する一群のマシンの部分集合である。例えば、ビジネスでは、会計と販売ワークグループを持つことが一般的である。それぞれの部署では別々にサーバとプリンタを持っている。Windowsの世界では、ワークグループとSMBグループは同じ概念である。

NBTSTATの例を用いて話を続けよう。SambaサーバであるhydraはSIMPLEワークグループ(グループ属性は00(16進数))のメンバーでもあり、ブラウズマスタ(グループ属性は1E)の選出の際に立候補をする。NBTSTATユーティリティの出力結果の残りの部分は次のようになる。 :

       NetBIOS Remote Machine Name Table, continued
   Name               Type         Status
---------------------------------------------
SIMPLE           <00>  GROUP       Registered
SIMPLE           <1E>  GROUP       Registered
..__MSBROWSE__.  <01>  GROUP       Registered

マシンの状態を表すグループ属性の一覧は表 1.3に示した。更に多くの情報がO'Reillyから刊行されている Windows NT in a Nutshell Eric Pearc著に載っている

表 1.3: NetBIOS グループリソースタイプ
リソース名	16進数で表されるバイト値
標準ワークステーショングループ	00
ログオンサービス	1C
マスタブラウザ名	1D
通常のグループ名(ブラウザ選定で使用された名前)	1E
インターネットグループ名(管理用)	20
`<01><02>__MSBROWSE__<02>`	01

最後の __MSBROWSE__は、他のマスターブラウザに自身のグループをアナウンスするのに使われる。名前の中の制御文字は、NBTSTATの出力では点で表わされる。すべてのリソースとグループタイプを理解していなくても心配しなくても良い。幾つかはSambaでは必要でないし、残りの章を読み進むうちに取り上げていく事になる。ここで覚えていて欲しい重要なことは、名前解決のメカニズムの仕組みである。

1.3.5 データグラムとセッション

話はそれてしまうが、ここでは上述した他に、NBTにおいて異なる2つのNetBIOSマシン間で保証される接続サービスについて紹介する:実際には、NetBIOS over TCP/IPにより2つのサービスが提供されている。 セッションサービスと データグラムである。これら2つのサービスがどのように機能しているか理解することは、Sambaを使っていく上で必須のことではない。しかしながら、この事を理解すれば、どのようにNBTが動作していて、Sambaでトラブルが発生した際にどのように問題解決を行なうかについて考え方を身につけることが出来る。

データグラムサービスでは、あるマシンとその他のマシンの間で安定した接続を保証しない。データのパケットは、単にあるマシンから他のマシンに送信されるか、ブローキャストされるかだけである。この際、目的先に到着する際の順序は考慮されないし、到着するかどうも保証されない。データグラムは、セッションほどネットワークに負荷をかけないが、賢くないやり方でデータグラムを使用すると、ネットワークを泥沼にはめる(前に説明した、ブロードキャストでの名前解決を思い出して欲しい)。以上よりわかるように、データグラムは手っ取り早く、一つあるいはそれ以上の他のマシンに、シンプルなデータブロックを送信するのに用いられる。データグラムサービス通信の簡単な基本要素を表 1.4に示す。

Table 1.4: データグラムの基本要素
基本要素	記述
データグラムの送信	マシン、あるいはマシンのグループに送信されたデータグラム
ブロードキャストデータグラムの送信	ブロードキャストデータグラムの受信のために待機しているマシンへのブロードキャストデータグラム
データグラムの受信	マシンからデータグラムの受信
ブロードキャストデータグラムの受信	ブロードキャストデータグラムのための待機

セッションサービスはより複雑である。セッションを用いた場合は、2つのNetBIOSアプリケーションの間で生じた接続障害を検知することが、理論上は可能となる。NBTセッションは、電話での呼出しに置き換えて考えると良いだろう[5]。全2重接続は、接続を行なうマシンと接続されるマシンの双方の間で行なわれる。通信が続いている間は、ずっと接続は開いていなければならない。互いのマシンが、呼び出している側のマシンと呼び出される側のマシンが誰であるか知っており、表 1.5に示される簡単な基本要素を使って通信を行なうことが出来る。

[5]RFC 1001を見ると分かるだろうが、電話の類例はNBTサービスによく当てはまる。

表 1.5: セッションの基本要素
基本要素	記述
呼出し	特定の名前で待機しているマシンのセッションを初期化する。
待機	既知の呼出し元、あるいはすべての呼出し元からの呼出しを待つ。
受話機を置く	呼出しを終わらせる。
送信	他のマシンにデータを送信する。
受け取り	他のマシンからデータを受け取る。
セッションの状況	リクエストを受けたセッションの情報を取得する。

セッションは、NBTネットワークでリソース共有ための屋台骨となっている。特に、サーバのディスク共有・プリンタ共有に対してクライアントマシンから安定した接続を確立するために、セッションが用いられている。クライアントは、サーバに"接続"してから、開きたいファイル、交換したいデータ、その他の情報の処理を行う。このような接続は、時間単位、日単位のように長時間連続して持続される。エラーが発生すると、セッションソフトウェア(TCP)によって、正しくデータが受信されるまでデータの再送信が行われる(データグラムサービス(UDP)の"パントし結果を祈る"的な手法とは異なるわけだ)。

実際のところセッションは問題のある通信を操作出来ると仮定されているが、そうでない事もある。Windowsネットワークを使っている人は既にこのことに気づいているだろうが、これはNBTセッションを使用する上で深刻な問題となっている。何かの理由で接続が台無しにされた場合、2つのコンピュータの間で開かれていたセッション情報は、容易に無効になってしまう。この事が発生すると、セッション情報を修復する唯一の方法は、お互いのコンピュータが再度お互いを呼び出して、セッションを最初から張り直すしかない。

これらのサービスについて、より詳細な情報を入手したい場合はRFC 1001を参照することをお勧めする。ただし、ここで覚えておいて欲しい重要な事が2つある:

セッションは常に 2つの - それ以上でなく、それ以下でないNetBIOS マシンの間で行われる。セッションサービスが台無しにされた場合、クライアントは、接続を再確立するのに十分な状態に関する情報を保持していると仮定されている。ただし実際には、これはほとんどあてにできない。
データグラムは複数のマシンにブロードキャスト可能である。ただし、信頼性は保証されない。言い換えると、送信されたデータグラムが確実に目的先に到達したか知るための方法はないと言うことである。


1.2 Sambaができること		1.4 Microsoftによる実装

Using Samba