Chapter 10. ネットワークブラウジング

John H. Terpstra

Samba Team

Jelmer R. Vernooij

The Samba Team

Jonathan Johnson

Sutinen Consulting, Inc.

July 5, 1998

Updated: September 20, 2006

Table of Contents

機能と利便性
ブラウジングとは何か?
議論
NetBIOS over TCP/IP
TCP/IPなしのNetBIOS
DNSとActive Directory
どのようにブラウジングは機能するか
ワークグループのブラウジングの設定
ドメインブラウジングの設定
強制的にSambaをマスターにする
Sambaをドメインマスターにする
ブロードキャストアドレスについての注意
複数のインタフェース
リモートアナウンスパラメーターの使用
Remote Browse Syncパラメーターの使用
WINS: The Windows Internetworking Name Server
WINSサーバーの設定
WINS複製
静的なWINSエントリ
役に立つヒント
Windowsのネットワークプロトコル
名前解決の順序
ブラウジングの技術的な概要
Sambaでのブラウジングサポート
問題の解決方法
サブネット間のブラウジング
よくあるエラー
SambaのNetBIOS名前キャッシュのフラッシュ
サーバーリソースがリスト出来ない
"Unable to browse the network"というエラーメッセージが出た。
共有とディレクトリのブラウジングが非常に遅い
不正なキャッシュされた共有参照はネットワークブラウジングに影響する

この章にはサブネット越しあるいはワークグループ(ドメイン)越しのブラウジング を実行するための早わかりと、さらに詳細な情報を含んでいる。WINSはNetBIOS名 からIPアドレスへの名前解決のために最適のツールである。しかし、WINSは 名前->アドレス解決方法を除いてブラウズリストの扱いを改善するわけではない。

Note

WINSとは何か?

WINSはNetBIOS名をそのIPアドレスに名前解決する機能を提供する。WINSはNetBIOS ネットワーク名のための動的DNSサービスに似ている。

Note

Microsoft Windows 2000 とそれ以降のバージョンでは、NetBIOS over TCP/IP なしで 操作するように設定できる。Samba とそれ以降のバージョンもこの操作モードを サポートしている。NetBIOS over TCP/IP が無効になっている場合、Microsoft Windows マシン名の解決を行う主要な手段は DNS と Active Directory 経由である。 以下の情報は使用するサイトで NetBIOS over TCP/IP が動いていることを仮定している。

機能と利便性

Charles Dickensはかつて次のような名言を言った: それはすべての時世の中で最もよい時世でもあれば、 すべての時世の中で最も悪い時世でもあった。 (訳注:二都物語の冒頭部分:佐々木 直次郎訳、青空文庫より) 振り返れば振り返るほど、あったことをより切望するが、それが決して 戻らないことを望む。(訳注:かなり怪しい)

多くのMicrosoft Windowsネットワーク管理者に対し、その一節はNetBIOSネットワーキングに ついて感じていることを要約している。NetBIOSネットワーキングをマスターした人にとって、 その気まぐれな性質はよくあることである。そのやんちゃな性質を押さえ込むことが全く 管理できない人にとって、NetBIOSはパターソンののろいのようである。

オーストラリアの植物問題をよく知らない人のために、パターソンののろい、すなわち エキウム・プランタギネウムは19世紀の中頃、ヨーロッパから オーストラリアに導入された。それ以来、急激に広まった。種がたくさん出来、 平方メートルあたり何千の密度で、種の寿命は7年以上もあり、年中発芽する能力があり、 正常な条件がそろえば、持続的に雑草として生える能力がある。

この章では、動いているNetBIOS(Network Basic Input/Output System) over TCP/IP を通して実装されているSMBに注目するServer Message Block (SMB)ネットワーキング の不可欠な側面を探求する。Sambaは他のプロトコル上でSMBまたはNetBIOSを実装 していないので、ネットワーク環境で、どのように設定をするかを知る必要があり、 また、すべてのMicrosoft ネットワーククライアント上でTCP/IP以外のものを使う ことはないことを単に覚えておけばよい。

SambaはWINS(Windows Internetworking Name Server)を実現することと、Microsoft のWINS拡張を実現する能力を提供する。これらの拡張は、通常の範囲のMicrosoft WINS を超えて安定したWINS動作を提供することを支援する。

WINSはNetBIOS overTCP/IPが動作しているシステムにのみ適用される サービスである。Microsoft Windows 200x/XPはNetBIOSが無効でも 動作することが出来る。そのような場合、WINSは無関係となる。Sambaは これもサポートする。

NetBIOSが無効になったこれらのネットワークでは(すなわち、WINSを必要としない)、 ホスト名の解決のためにDNSを使うことが必要である。

ブラウジングとは何か?

一般的には、ブラウジングとは、Microsoft WindowsとSambaサーバーがマイネットワーク中に 見える事を意味し、特定のサーバーのコンピューターアイコンをクリックすると、その サーバー上の共有と有効なプリンターを表示するウィンドウが開いて表示される。

とても単純に見えるが、これは実際には、異なった技術の複雑な相互作用によるもの である。これらのすべてを行うために使われる技術(か方式)は以下を含む:

  • ネットワークへのMicrosoft Windowsマシンの存在を登録。

  • ネットワーク上の他のマシンにそれ自身を通知。

  • ネットワーク上の複数の1つ以上のマシンはローカルアナウンスメントをまとめる。

  • クライアントマシンはマシンのリストをまとめたマシンを見つける。

  • クライアントマシンはマシン名をIPアドレスに変換する。

  • クライアントマシンはターゲットマシンに接続する。

ブラウズリスト管理と名前解決を制御するSambaアプリはnmbdである。 nmbdの動作に関連する設定パラメーターは以下の通り:

ブラウジング動作:

名前解決方法:

WINS動作:

(*)というマークが付いたものは通常変更が必要なオプションである。これらのパラメーターが 設定されていなくても、nmbdは動作することが出来る。

Sambaでは、wins server と wins support は相互に排他的なオプションである。 nmbdが起動するとき、smb.confファイル中に両方の オプションが設定されていると、起動に失敗する。nmbd は、それ自身のWINSサーバーを使わなければならないWINSサーバーとして動作する ために、それ自身のインスタンスをフォークする。

議論

すべてのMicrosoft Windows ネットワークは SMBベースのメッセージングを使う。 SMBメッセージングはNetBIOSがあってもなくてもよい。Microsoft Windows 200x は下位互換のために、NetBIOS over TCP/IPをサポートする。Microsoftは段階的に NetBIOSサポートを打ち切っているように見える。

NetBIOS over TCP/IP

Sambaは、TCP/IP上でカプセル化することによって、Microsoft Windows NT/200x/XPが するようなNetBIOSを実装している。NetBIOSベースのネットワークはブラウズリストの 管理を行うために、ブロードキャストメッセージングを使う。NetBIOS over TCP/IP が動いている時、これはUDPベースのメッセージングを使う。UDPメッセージは ブロードキャストかユニキャストのどちらも使える。

通常、ユニキャストUDPメッセージングのみがルータによって転送される。 smb.confのremote announceパラメーターはユニキャストUDB を通じて、リモートネットワークセグメントにブラウズアナウンスメントを公開する ことを支援する。同様に、smb.confremote browse sync パラメーターはユニキャストUDPを使ってブラウズリストの収集を実現する。

名前検索要求(名前解決)を実行するためにMicrosoft Windowsによって使われる方法 はNetBIOSノードタイプと呼ばれる設定パラメーターによって決まる。基本的なNetBIOS ノードタイプは4つある:

  • b-node (type 0x01):UDPブロードキャストを 使ってNetBIOSブロードキャスト要求のみを使うWindowsクライアント。

  • p-node (type 0x02):WINSサーバーに直接UDP ユニキャストを行う、ポイントツーポイント(NetBIOSユニキャスト)要求を使う Windowsクライアント。

  • m-node (type 0x04):、最初にUDPブロード キャストを使ってNetBIOSブロードキャストを行い、次に(NetBIOSユニキャストで) WINSサーバーに直接UDPユニキャストを行うWindowsクライアント。

  • h-node (type 0x08):UDPユニキャスト (NetBIOSユニキャスト)を使ってWINSサーバーに直接要求し、次にUDPブロードキャストを 使ってNetBIOSブロードキャスト要求をするWindowsクライアント。

既定値のWindowsネットワーククライアント(あるいはサーバー)のネットワーク設定は、 NetBIOS over TCP/IPを有効にしていて、b-ノードになっている。WINSを使うと、 WINSが故障か有効になっていない場合、クライアントがブロードキャストベースの 名前解決を使えるように、h-ノード(ハイブリッドノード)動作が意味をなすようになる。

SambaがSMBサーバー技術のみのネットワーク中ではnmbd のうち少なくとも1台はWINSサーバーとして設定する必要がある。これは、 ブラウジング環境の管理を簡単にする。もしもおのおののネットワークセグメントが 固有のSamba WINSサーバーを設定している場合、セグメント間のブラウジングを動作させ る唯一の方法はremote announceremote browse syncパラメーターをsmb.confファイルで 使うことである。

もしも全体の複数ネットワークで1つだけのWINSサーバーを使う場合、 remote announceremote browse syncパラメーターの使用は必須ではない。

Samba-3では、WINS複製は作業中である。大量のコードがコミットされていたが、 まだ改良が必要である。Samba-3.0.20のリリース時点ではまだサポートされた機能では ない。希望としては、Samba-3のどこかのリリース時点でサポートされた機能になること を予定している。開発者がこれを完了させようと思うほどの、十分な重要性がないとい う理由で、これは遅れている。

現時点で、SambaのWINSはMS-WINS複製をサポートしていない。これは、SambaをWINSサー バとして設定しても、ネットワーク上で、1つだけnmbdをWINSサーバーとして 設定する必要がある。あるサイトでは(サブネット単位に1つのサーバーを)冗長性のために、 複数のSamba WINSサーバーを使っていて、セグメントをまたいですべてのセグメントの ブラウズリストを集めるために、remote browse syncremote announceを使っている。 この設定では、クライアントがローカル名の解決のみが出来るので、他のサブネット上 を見ることができる、サーバーのIPアドレスを解決するために他のサブネット上の名前を 解決するためのDNSを使うように設定しなければならない。この設定は推奨されないが、 実用的なやり方として(すなわち、もしも他の場合がすべて失敗の場合 というシナリオ)、記述されている。NetBIOS over TCP/IPはとてもひどくて管理しにく いプロトコルである。この置き換えとして、NetBIOSless SMB over TCP/IP is not without its own manageability concerns. NetBIOSベースのネットワークは妥協とトレードオフの固まりである。WINSは DNSに格納出来ない情報を格納する。従って、DNSはNetBIOS over TCP/IPが 使われている時にWINSから得られるものよりも貧弱な代わりにしかならない。 WindowsクライアントはWINSを使うように設計されている。

最後に、ブラウズリストは15分間よりも短い間隔で繰り返される信頼性のない ブロードキャストメッセージの集合から校正されていることに注意。これは、 ブラウズリストを作成するために時間がかかると言うことであり、特に、 ネットワークセグメントをまたぐ場合は、安定するまでには45分かかる可能性が あるということである。

Microsoft Windows 200x/XPシステムでホスト名をIPアドレスに解決しようとする場合、 以下の手順で行う:

  1. hostsファイルを調べる。これは%SystemRoot%\System32\Drivers\etcにある。

  2. DNS 検索を実行する。

  3. NetBIOSネームキャッシュを調べる。

  4. WINSサーバーに問い合わせる。

  5. UDPでブロードキャストの名前検索を行う。

  6. %SystemRoot%\System32\Drivers\etcにあるLMHOSTSファイルのエントリを調べる。

どのようにNetBIOS over TCP/IPプロトコルが実装されているを考えた上で、WINSのみが、 TEMPTATION<1C> というネットワークログオンサーバーを探すための NetBIOS名前問い合わせのようなサービス指向の名前の、信頼性のある名前検索を解決す る能力を持つ。実際、Microsoft ADSでの実装は特に拡張されたサービス指向のDNSエン トリ全体を管理するようになっている。このタイプの機能はNetBIOS over TCP/IPプロト コルの名前空間では実装も、サポートもされていない。

TCP/IPなしのNetBIOS

すべてのTCP/IPが有効なシステムは、いろいろなホスト名解決方法を使う。TCP/IPの ホスト名解決で最初に使う方法は固定のファイル(/etc/hosts) かDNSである。DNSはインターネットを使えるようにする技術である。DNSベースのホスト 名解決はほとんどすべてのTCP/IPが有効なシステムでサポートされている。ごくわずか の組み込みシステムのみがDNSのサポートをしていない。

Windows 200x/XPはダイナミックDNSサーバー(DDNS)にそのホスト名を登録できる。 Windows 200x/XP上で ipconfig /registerdnsを使うことで、 ダイナミックDNSサーバーに強制的に登録できる。

Active Directoyでは、正確に動作しているDNSサーバーが確実に必要である。正しく設定 されていて動作しているDNSサーバーがない場合、Microsoft Windows クライアントとサー バはお互いを認識できず、そのためネットワークサービスはひどく使い物にならないだ ろう。

raw SMB over TCP/IP(NetBIOSレイヤなし)の使用は、Active Directoryドメインのみで 行える。SambaはActive Directory ドメインコントローラーではない:故に、NetBIOSを 使わないで同じ時にSambaをドメインコントローラーとして動かす のは不可能である。SambaをActive Directoryのメンバーサーバー(DMS)として動かしているとき、 NetBIOS over TCP/IPを使わないでSambaを設定することは可能である。Samba DMSは Active Directoyドメインに完全に統合できるが、もしも、NetBIOS over TCP/IPが無効 の場合、SambaまたはADS環境のどちらかで自動的に生成されないという理由で、Samba DMS用に適切なDNSエントリを手動で作成する必要がある。

DNSとActive Directory

時折、Microsoft DNSサーバーの代わりにUNIXベースのDDNSサーバーを使いたいというUNIXネッ トワーク管理者の要望を聞くことがある。これが誰かにとって都合がよい間、Microsoft Windows 200x DNSサーバーはActive Directoryと共に動作するように自動的に設定される。 BIND 8または9を使うのは可能だが、Microsoft Active Directoryクライアントが基本的 なネットワークサービスを確実に使えるために、ホスト名を解決できるために、サービ スレコード(SRVレコード)を確実に作成することがほとんど必要となる。以下は、 Active Directoryが要求する既定値のサービスレコードのいくつかである:

Active Directoryで必要とされるSRV(サービス)レコードを十分にサポートする能力を BIND9を使うときに望まれるため、Active DirectoryでDDNSを使うことは強く推奨される。 もちろん、ADSが動いているとき、ADSとMicrosoft DNSの間で自然な類似性があるという 理由で、Microsoft固有のDDNSサーバーを使うことは意味があることである。

_ldap._tcp.pdc._msdcs.Domain

これは、ドメイン内のWindows NT PDCアドレスを提供する。

_ldap._tcp.pdc._msdcs.DomainTree

ドメイン内のグローバルカタログのアドレスを解決する。

_ldap._tcp.site.sites.writable._msdcs.Domain

サイト上のドメインコントローラーの一覧を提供する。

_ldap._tcp.writable._msdcs.Domain

Enumerates list of domain controllers that have the writable copies of the Active Directory data store.

_ldap._tcp.GUID.domains._msdcs.DomainTree

グローバルな一意の識別子を使うマシンをクライアントが認識するためにMicrosoft Windowsによって使われるエントリ。

_ldap._tcp.Site.gc._msdcs.DomainTree

サイト設定に依存するグローバルカタログサーバーをクライアントが認識するためにMicrosoft Windowsによって使われる。

サンプルのドメインquenya.orgのために基本的なサービスを Microsoftクライアントが認識するために使われる特定のエントリは以下を含む:

  • _kerberos._udp.quenya.org UDP経由でKDCサーバーに接続す るために使われる。のエントリはおのおののKDC向けにポート88にしな ければならない。

  • _kpasswd._udp.quenya.org ユーザーのパスワード変更処理を 行わなければならない時にkpasswdサーバーを見つけるときに使う。 このレコードはマスターKDCのポート464でなければならない。

  • _kerberos._tcp.quenya.org TCP経由でKDCサーバーを見つけ るときに使う。このエントリはおのおののKDCでポート88でなければならない。

  • _ldap._tcp.quenya.org PDC上でLDAPサービスを見つける のに使う。このレコードはPDCのためにポート389でなければならない。

  • _kpasswd._tcp.quenya.org ユーザーパスワード変更を行う ことを許可するためにkpasswdを探すときに使う。これはポート 464でなければならない。

  • _gc._tcp.quenya.org グローバル型ログサーバーを探すとき に使う。これはポート3268でなければならない。

以下のレコードも、Windows ADS ドメインコントローラー上の重要なサービスを 探すために、Windowsドメインクライアントによって使われる。

  • _ldap._tcp.pdc._msdcs.quenya.org

  • _ldap.gc._msdcs.quenya.org

  • _ldap.default-first-site-name._sites.gc._msdcs.quenya.org

  • _ldap.{SecID}.domains._msdcs.quenya.org

  • _ldap._tcp.dc._msdcs.quenya.org

  • _kerberos._tcp.dc._msdcs.quenya.org

  • _ldap.default-first-site-name._sites.dc._msdcs.quenya.org

  • _kerberos.default-first-site-name._sites.dc._msdcs.queyna.org

  • SecID._msdcs.quenya.org

正しいDNSエントリの存在は以下を実行することによって検証できる:

root#  dig @frodo -t any _ldap._tcp.dc._msdcs.quenya.org

; <lt;>> DiG 9.2.2 <lt;>> @frodo -t any _ldap._tcp.dc._msdcs.quenya.org
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3072
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 2


;; QUESTION SECTION:
;_ldap._tcp.dc._msdcs.quenya.org. IN        ANY


;; ANSWER SECTION:
_ldap._tcp.dc._msdcs.quenya.org. 600 IN SRV 0 100 389 frodo.quenya.org.
_ldap._tcp.dc._msdcs.quenya.org. 600 IN SRV 0 100 389 noldor.quenya.org.


;; ADDITIONAL SECTION:
frodo.quenya.org.  3600  IN      A       10.1.1.16
noldor.quenya.org. 1200  IN      A       10.1.1.17


;; Query time: 0 msec
;; SERVER: frodo#53(10.1.1.16)
;; WHEN: Wed Oct  7 14:39:31 2004
;; MSG SIZE  rcvd: 171

どのようにブラウジングは機能するか

Microsoft WindowsマシンはそのNetBIOS名を起動時に登録する(すなわち、動作に対する おのおののサービスタイプのためのマシン名)。この名前登録の正確な方法は、 Microsoft Windowsクライアント/サーバーにWINSサーバーアドレスが与えられているか否か か、LMHOSTS検索が有効になっているか否か、NetBIOS名の名前解決にDNSを使うかどうか か否か、あるいはその他によって決まる。

WINSサーバーがない場合、名前検索と同様、すべての名前登録は、UDPブロードキャストに よって行われる。これは、すべての名前とIPアドレスの一覧を用意するLMHOST を使う以外、ローカルサブネット単位で分割した名前解決を行う。このような状態で、 リモートのMicrosoft Windowsネットワークのブラウズリスト中にSambaサーバーの名前を 強制的に入れ込むことによる方法を提供する (remote announceを使って)。

WINSサーバーを使う場合、Microsoft Windows蔵案とはWINSサーバーにUDPユニキャストで名 前を登録する。このようなパケットはルーティング出来、WINSはルーティングされたネッ トワークを超えて名前解決が出来る。

スタートアップ処理中、すでに存在していなければ、ローカルマスターブラウザー(LMB)の 選定が起こる。おのおののNetBIOSネットワークで、ある1つのマシンがドメインマスター ブラウザー(DMB)として機能するように選択される。このドメインブラウジングは、 Microsoftセキュリティドメインコントロールとは何らの関係もない。その代わり、DMB は(WINSまたはLMHOSTを使って見つけた)おのおののLMBに接続する役割を行い、ブラウズ リストの内容を交換する。このようにして、すべてのマスターブラウザーは、結果として、ネットワーク 上にあるすべてのマシンの完全な一覧を得ることになる。毎11から15分ごとに、どのマ シンがマスターブラウザーになるかという選択が行われる。使用される選択基準の性質によ り、最も大きなuptime、あるいは最も上位のプロトコルバージョン、あるいは、そのた の基準を持つものがDMBとして選択される。

WINSサーバーが使われているとき、DMBはそのIPアドレスをドメインの名前とNetBIOS名前 タイプ1B(すなわちDOMAIN<1B>)を使ってWINSサーバーに登録する。WINSサーバーを使 うすべてのLMBも、ドメインの名前とNetBIOS名前タイプ1Dを使ってそのIPアドレスを登 録する。タイプ1Bの名前はドメインセキュリティコンテキスト内であるサーバー1つだけに 割り当てられ、たった1つのタイプ1Dの名前がおのおののネットワークセグメントで登録 される。タイプ1Dの名前を登録したマシンは、そのマシンがいるネットワークセグメン トにおける、ブラウズリストメンテナの権限を持つ。DMBはLMBから得られたブラウズリ ストを同期させることに責任がある。

ネットワークをブラウズしようとするクライアントは、このリストを使うが、有効なIP アドレスへの名前解決の有効性に依存する。

Any configuration that breaks name resolution and/or browsing intrinsics will annoy users because they will have to put up with protracted inability to use the network services.

Sambaはsmb.confファイル中にremote browse sync パラメーターを使うことで、ルーティングされたネットワーク越しにブラウズリストの 同期を強制的に行う機能をサポートしている。この機能のためにSambaはリモートネットワーク上 のLMBに接続し、ブラウズリストの同期を要求する。これはルータによって分離された2 つのネットワークを効果的に接続する。2つのリモートネットワークはブロードキャスト ベースの名前解決か、WINSベースの名前解決のどちらを使っても良いが、 remote browse syncパラメーターがブラウズリストの同期を提 供するが、それは名前からアドレスへの解決とは異なることに注意する必要 がある。別の言い方をすると、サブネット間のブラウジングをきちんと機能させるため には、名前解決メカニズムが提供されていることが基本であるということである。この メカニズムとはDNS、/etc/hosts、あるいはその他である。

ワークグループのブラウジングの設定

ネットワークが、NTドメインでない、ワークグループに属するマシンを含むサブネット 間のブラウジングを設定するために、ある1つのSambaサーバーをDMBにする必要がある( NTドメイン中では両方の役割を同じマシンが担うが、これはPDCとは違うと言うことに注 意)。DMBの役割はワークグループ中に参加しているマシンがあるすべてのサブネット上 のLMBからブラウズリストを収集することである。DMBとして設定されたマシンがないと、 おのおののサブネットは分離された、他のサブネットのマシンを見ることができないワー クグループとなってしまう。これが、ワークグループに対してサブネット間ブラウジングをさせ るDMBの存在理由である。

ワークグループ環境で、DMBはSambaサーバーでなければならず、ワークグループ名につき1 つのDMBでなければならない。SambaサーバーをDMBとして設定するためには、smb.conf ファイル中の[global]セクションに以下のオプションを記述 する:

domain master = yes

DMBはそれがいるサブネット上でのLMBであるべきである。これを達成するためには、 smb.confファイル中の[global]セクション中に、 ドメインマスターブラウザーのsmb.conf で示されるオプションを設定する:

Example 10.1. ドメインマスターブラウザーのsmb.conf

[global]
domain master = yes
local master = yes
preferred master = yes
os level = 65

必要であれば、DMBはWINSサーバーと同じマシンでも良い。

次に、ワークグループに対するLMBとして振る舞うことが出来るマシンを、おのおののサ ブネットごとに存在するようにする。任意のWindows NT/200x/XPマシンはこれが出来、 Windows 9x/Meマシン(しばしばリブートの必要があるため、この目的に使うのには適さ ないが)もできる。SambaサーバーをLMBにするには、以下の、 ローカルマスターブラウザーのsmb.confで示されているよ うに、smb.confファイルの[global]セクション中に以下の オプションを記述する。

Example 10.2. ローカルマスターブラウザーのsmb.conf

[global]
domain master = no
local master = yes
preferred master = yes
os level = 65

おのおののサブネットごとに1つ以上のSambaサーバーに対してこれを行わないこと。そう しないと、LMBになるための競合が発生してしまう。

local masterパラメーターはSambaに、LMBとして機能するように させる。preferred masterは、nmbdに対 して起動時にブラウザー選択を強制的に実行するようにさせ、 os levelパラメーターは、Sambaが、ブラウザー選択に勝つために 必要十分となる大きな値を設定する。

もしもLMBにしたいNTマシンがサブネット上にある場合、以下の、 マスターブラウザーにならないsmb.confで 示されているように、smb.confファイル中の[global] セクション中に、以下のパラメーターを設定して、SambaがLMBにならないようにする。

Example 10.3. マスターブラウザーにならないsmb.conf

[global]
domain master = no
local master = no
preferred master = no
os level = 0


ドメインブラウジングの設定

もしも、Windows NTドメインにSambaサーバーを追加する場合、SambaサーバーをDMBとして設 定してはならない。既定値では、ドメインに対するWindows NT PDCはそのドメインに対 するDMBでもある。WINSを使って、DMB NetBIOS名 (DOMAIN<1B>)をSambaサーバーがPDCとして登録すると、 ネットワークブラウジングは崩壊する。

Windows NT PDCを含んでいる以外のサブネットでは、Sambaサーバーを説明しているように LMBとして設定しても良い。SambaサーバーをLMBにするためには、以下の ローカルマスターブラウザーにするためのsmb.conf のように、smb.confファイル中の[global]セクション中に 以下のオプションを設定する。

Example 10.4. ローカルマスターブラウザーにするためのsmb.conf

[global]
domain master = no
local master = yes
preferred master = yes
os level = 65

もしも、同じサブネット上のマシンとの間で選択作業を行いたいのであれば、 os levelパラメーターをより小さな値に設定しても良い。 これを行うことで、LMBになり得る、動いているマシンの順番を調整することができる。 より詳細については 強制的にSambaをマスターにする を参照のこと。

もしもすべてのサブネット上でのドメインのメンバーであるWindows NTマシンがあり、 それが常時確実に動いているならば、以下で示される、 マスターにブラウザーにならないsmb.conf のように、smb.confファイル中の[global] セクション中で以下のオプションを指定することで、Sambaがブラウザー選択を しなくなり、LMBに絶対にならないようにすることができる。

Example 10.5. マスターブラウザーにならないsmb.conf


強制的にSambaをマスターにする

マスターブラウズになるマシンはブロードキャストを使った選択プロセスで決められる。 各選択パケットには選択作業において、ホストがどのような優先項目(バイアス)を持つ べきかを決定するための、たくさんのパラメーターを含んでいる。既定値では、Sambaは、 各Windowsサーバー又はクライアントについて、低い優先度を持ち結果として選択からは外 れる。

Sambaを選択したい場合には、smb.conf中のos levelグロー バルオプションをより大きい数字に設定する。既定値では20である。34を使うと、他の すべてのシステム(他のSambaシステムを除く)との選択に勝つ。

os levelが2の場合はWindows for Workgroupsと Windows 9x/Meに勝つが、Microsoft NT/200x サーバーには勝てない。Microsoft Windows NT/200x サーバーのドメインコントローラーはレベル32を使う。os levelの最大値は255である。

もしも、起動時にSambaに選択を強制させたいならば、smb.conf中の preferred masterグローバルオプションを yesに設定する。Sambaは優先マスターブラウザーでない、他のポテン シャルマスターブラウザーよりも若干の優位性を持つようになる。これは注意深く使うこと。 そうしないと、同じローカルサブネット上でpreferred masteryesに設定した2つのホスト(Windows 9x/MeかNT/200x/XPかSamba) があった場合、LMBになるための強制的な選択が、定期的かつ継続的に発生してしまう。

もしも、SambaをDMBにしたいならば、ブロードキャストが届かな い分離されたサブネット上のLMBでもない、LANまたはWAN全体のDMBにSambaがならないと いう理由で、 preferred masteryesに設定するこ とを推奨する。

2つのSambaサーバーがドメイン用にDMBになるように試みることは出来る。最初のサーバーは DMBになる。その他のすべてのサーバーは5分ごとにDMBになるように試行する。それらは、 すでに他のSambaサーバーがDMBであることを見つけて失敗する。これは、現在動いている DMBが故障したときに、自動的な冗長性を提供する。ブラウザー選択のネットワークバンド 幅のオーバーヘッドは相対的に小さく、おおよそ1つの選択ごとかつ1つのマシンごとに4つのUDPパ ケットを要求する。最小のUDPパケットは576バイトである。

Sambaをドメインマスターにする

ドメインマスターブラウザーは複数のサブネットのブラウザーリストを集めることに責任があ り、それゆえ、サブネット間でのブラウジングが可能になる。smb.conf中に domain master = yesを設定することで、Samba をドメインマスターブラウザーにすることが出来る。既定値では、ドメインマスターになる設 定ではない。

SambaをNT/200xドメインと同じ名前を持つワークグループ向けのドメインマスターに設定 してはならない。もしも、同じネットワーク上で同じ名前を持つWindows NT/200xドメイ ンと同じワークグループ名用にドメインマスターとしてSambaを設定すると、ネットワーク ブラウジングの問題が確実に発生する。

Sambaがドメインマスターでマスターブラウザーの場合、他のサブネット上のLMBからのマスター アナウンスをリッスンし(おおよそ12分間隔)、ブラウザーリストの同期を行うために、そ のマシンに接続する。

Sambaをドメインマスターにしたい場合、選択に勝つために、 os levelを十分に大きな値にすべきであり、 preferred masteryesにし、 起動時にSambaに強制的に選択を行わせるようにする。

(Sambaを含む)すべてのサーバーとクライアントは、NetBIOS名を解決するためにWINSサー バを使うべきである。もしもクライアントがNetBIOS名を解決するためにブロードキャス トのみを使うと、以下の2つが発生する:

  1. ローカルサブネットのみしか見えないため、LMBはDMBを見つけられなくなる。

  2. もしもクライアントがドメイン全体のブラウズリストを入手し、そのリストに あるホストにアクセスしようとした場合、そのホストに対するNetBIOS名の解決 が出来なくなる。

しかし、Sambaとクライアント両方がWINSを使う場合:

  1. LMBはWINSサーバーに接続し、SambaがDMBである間はWINSサーバーに登録を行い、 LMBはDMBとしてSambaのIPアドレスを受け取る。

  2. クライアントがドメイン全体のブラウズリストを入手し、ユーザーがそのリスト 中のホストに接続しようとしたとき、そのホストに対するNetBIOS名を解決する ために、WINSサーバーに接続する。同じWINSサーバーにホストのNetBIOS名が登録さ れている間はそのホストを認識することが出来る。

ブロードキャストアドレスについての注意

ゼロベースのブロードキャストアドレスをネットワークが使っている場合(たとえば、0 で終わる)、問題が発生する。Windows fore Workgroupはゼロベースのブロードキャスト をサポートしていないようなので、ブラウジングと名前検索が動かないだろう。

複数のインタフェース

Sambaは複数のネットワークインタフェースをサポートする。もしも複数のインタフェー スがある場合、smb.conf中のinterfacesオプションを使っ て設定を行う必要がある。たとえば、eth0, eth1,eth2, eth3 という4つのネットワークインタフェースを持つマシンがあり、 eth1eth4のみSambaが使う場合があったとす る。この場合、この意図に合わせるようにするためには、smb.confファイル中に以下 のエントリを記述する:

interfaces = eth1, eth4
bind interfaces only = Yes

bind interfaces only = Yesは指定されていな いインタフェース上でTCP/IPセッションサービス(ポート135,139と445)を含めない時に 必要である。nmbdはリストされていないポート上でのUDPポート137 から来るパケットをリッスンするが、それには返答しないことに気がつくこと。しかし ながら、リストされていないインタフェース上でブロードキャストパケットは送信する。 完全にイーサネットインタフェースを分離するには、Sambaサーバーがアクセスできないよ うにしなければならないすべてのネットワークインタフェース上で、ポート137と 138(UDP)、ポート135、139と445(TCP)をファイアウォール上でブロックすることが必要 である。

リモートアナウンスパラメーターの使用

smb.conf中のremote announceパラメーターは ネットワーク上のすべてのNetBIOS名がリモートネットワークにアナウンス されることを保証するために使うことが出来る。 remote announceパラメーターの文法は以下の通り:

remote announce = 192.168.12.23 [172.16.21.255] ...

or

remote announce = 192.168.12.23/MIDEARTH [172.16.21.255/ELVINDORF] ...

ここで:

192.168.12.23 and 172.16.21.255

はリモートネットワークのLMBのIPアドレスか、ブロードキャストアド レスである。これは、LMBが192.168.1.23か、ネットマスクが24ビット (255.255.255.0)であるときに172.16.21.255として与えられる。 リモートアナウンスがリモートネットワークのブロードキャストに対 して行われるとき、各ホストはこのアナウンスを受け取る。これはノイズであり、 好ましくないが、もしもリモートLMBのIPアドレスが分からないときには必要である。

ワークグループ

はオプションで、自ワークグループかリモートネッ トワークのワークグループを指定できる。リモートのネットワークの ワークグループ名を使う場合、自マシンのNetBIOS名はそのネット ワークに所属するように見えるようになる。これは名前解決問題 を引き起こしかねず、避けるべきである。

Remote Browse Syncパラメーターの使用

smb.confremote browse syncパラメーターは 手元のSamba LMBとの間で同期を取らなければならない他のLMBへアナウンスを行うのに 使用する。これは、そのネットワークセグメント上でSambaサーバーがが同時にLMBの時に のみ動作する。

remote browse syncパラメーターの文法は以下の通り:

ここで、192.168.10.40は、リモートのLMBのIP アドレスか、リモートセグメントのネットワークブロードキャストアドレスである。

WINS: The Windows Internetworking Name Server

WINSの使用(Samba WINS又はWindows NTサーバーWINS)は強く推奨する。 各NetBIOSマシンは、有効なサービスのサービスタイプの名前タイプの値と共に、 名前を登録する。ユニーク名(タイプ0x03)として名前を直接登録する。 また、LanManager互換のサーバーサービス(他のユーザーに対してファイル共有と プリンター共有を提供する)が動いているときには、サーバー名(タイプ0x20) を登録することによりその名前も登録する。

すべてのNetBIOS名は最大15文字である。名前タイプの値が名前の後に付加され、 合計16文字となる。15文字より小さい名前は15文字になるように空白が埋め込まれる。 そのため、すべてのNetBIOS名は16文字(名前タイプ情報を含め)である。

WINSは登録された16文字長の名前を格納できる。ネットワークにログオンしたい クライアントはNetLogonサービス名前タイプで登録されたすべての名前のリストを WINSサーバーに問い合わせる。これはブロードキャストトラフィックを減少し、 ログオン処理を高速化する。ネットワークセグメント越しにブロードキャスト による名前解決が出来ないため、このタイプの情報はWINSサーバーがいないときに、 すべてのクライアントが内包しなければならないlmhosts ファイルを固定的に設定するか、WINSサーバーによってのみ提供される。

WINSはすべてのLMBによってブラウズリストの同期を強制的に行う。LMBはDMB を使ってそのブラウズリストを同期し、WINSはそのDMBの識別をLMBに対して 手助けする。定義によって、これは単一のワークグループ内でのみ動作する。 DMBはMicrosoft NTドメインとして呼ばれているとは無関係であることに注意。 DMBがブラウズリスト情報のみに関してマスターコントローラーとしてDMBが言及する 間、後者はセキュリティ環境について言及する。

WINSは、WINSサーバーのためにすべてのTCP/IPプロトコルスタックが設定されて いる時のみ正しく動作する。あるクライアントがWINSサーバーを使うように設定 されておらず、ブロードキャストでの名前登録のみを引き続き使うようになって いる場合、WINSはそれを認識できない。この場合、WINSサーバーで名前登録を 行わないマシンは、他のクライアントによる名前-アドレス変換が失敗し、 それゆえ、ワークステーションへのアクセスエラーが発生する。

SambaをWINSサーバーとして設定するためには、 smb.confファイルの[global]セクションで、 wins support = yesを追加する。

SambaがWINSサーバーに登録するためには、smb.confファイルの [global]セクションで wins server = 10.0.0.18を追加する。

Important

特にその固有IPアドレスを指定して、 wins support = yesと一緒に、 wins server = 10.0.0.18 を使わないこと。両者を同時にsmb.confで指定すると起動しなくなる!

WINSサーバーの設定

SambaサーバーまたはWindows NTサーバーのどちらも、WINSサーバーとして設定できる。 SambaサーバーをWINSサーバーとして設定するためには、選択したサーバーのsmb.conf ファイルに以下を[global]セクションに追加しなけ ればならない:

wins support = yes

Samba 1.9.17より前のバージョンでは、このパラメーターは既定値でyesになって いる。もしも、ネットワーク上で古いバージョンのSambaを使っている場合、 最新のバージョンへのアップグレードを強く推奨する。そうしないと、 それらすべてのマシンでこのパラメーターをnoに設定しなければ ならなくなる。

wins support = yesを設定したマシンは、 登録されたすべてのNetBIOS名を保持し、NetBIOS名のためのDNSとして機能する。

単一のWINSサーバーを設定することを強く推奨する。ネットワーク上で2つ以上の サーバーに、wins support = yesを 指定しないこと。

Windows NT/200xサーバーをWINSサーバーとして設定するためにはWINSサービスを設定する。 詳細は、Windows NT/200xの説明書を参照のこと。Windows NT/200xのWINSサーバーは、 お互いに複製が出来、複雑なサブネット環境で2つ以上設定できる。Microsoftが 複製プロトコルの開示を行っていないため、Sambaは現在それらの複製機能に参加でき ない。Samba間同士のWINS複製プロトコルは将来作成する予定だが、その場合、2つ 以上のSambaマシンがWINSサーバーとして設定できるようになる。現在は、1台のみの Sambaサーバーがwins support = yesと設定 できる。

WINSサーバーを設定後、ネットワークに参加しているすべてのマシンはこのWINSサーバー のアドレスを設定するようにしなければならない。もしも、WINSサーバーがSambaマシン ならば、コントロールパネル->ネットワーク接続->ローカルエリア接続等-> プロパティ->インターネットプロトコル(TCP/IP)->プロパティ->詳細設定-> WINSダイアログ中のWINSアドレスフィールド にSambaマシンのIPアドレスを設定する(WindowsXPの場合)。SambaサーバーにWINS サーバーのIPアドレスを設定する場合には、すべてのsmb.confファイルの [global]セクションに以下を追加する:

wins server = <名前またはIPアドレス>

ここで、<名前またはIPアドレス>は、WINSサーバーのDNS名かそのIPアドレスである。

この行はSambaサーバー自身がWINSサーバーとして動作する場合に、smb.confファイル 中に設定してはならない。もしも wins support = yesオプションと wins server = <name>オプションを 同時に設定すると、nmbdは起動に失敗する。

サブネット間のブラウジングを設定するためには2つの方法がある。 最初のもの詳細は、Windows NTドメインの一部としては設定されていない、Windows9x/Me、 SambaとWindows NT/200xを含むネットワーク上でのサブネット間ブラウジングを 設定するものである。2番目のものの詳細は、NTドメインを含むネットワーク上 でのサブネット間ブラウジングを設定するものである。

WINS複製

Samba-3はWINS複製をサポートしていない。これを実装する試みはあり、 wrepldと呼ばれていたが、すでに開発は停止している。

一方、samba4WINSというプロジェクトがあり、これは、 Samba-3バージョン3.0.21から、Samba-4のWINSサーバーを並列に動かせるように するものである。samba4WINSに付いての詳細は、 http://ftp.sernet.de/pub/samba4WINS を参照のこと。

静的なWINSエントリ

Samba WINSサーバーに静的なエントリを追加するのはとても簡単である。 通常/usr/local/samba/var/locks/var/run/sambaにある wins.datファイルに行を追加するだけである。

wins.dat中のエントリは以下の形式である:

"NAME#TYPE" TTL ADDRESS+ FLAGS

ここでNAMEはNetBIOS名、TYPEはNetBIOS名前タイプ、TTLはそのエントリの、秒単位の 生存時間、ADDRESS+は登録したい1つ以上のアドレス、FLAGは登録時に使うNetBIOS フラグである。

Note

nmbdを再起動するまで、wins.datへの変更は反映されない。 wins.datは動的に変更されるので、nmbdはこのファイルを 変更する前に停止しておかなければならないことに注意。このファイルを編集後、 nmbdを再起動するのを忘れないこと。

通常の動的エントリは以下のようになる:

"MADMAN#03" 1155298378 192.168.1.2 66R

NetBIOS名を静的に(恒久的に)するためには、以下のように、単純にTTLを0にする:

"MADMAN#03" 0 192.168.1.2 66R

NetBIOSフラグは16進数で、ビット単位に意味を持つ: 00 - Bノードの登録、20 - Pノードの 登録、40 - Mノードの登録、60 - Hノードの登録、02 - 恒久名、04 - アクティブ名、 80 - グループ名 である。'R'は登録レコードであることを表示する。そのため、 66Rは ハイブリッドノードで、アクティブで、恒久的なNetBIOS名であることを意味する。これら の値は、Sambaソースコードリポジトリのnameserv.hで定義されて いる。それらはNBフラグのための値である。

初期のSamba-3バージョンから、この方法は動作するが、WINS複製機能が追加された、 将来のバージョンでは変更の可能性がある。

役に立つヒント

多くのネットワーク管理者がつまずく点なので、以下のヒントは十分に検討する 必要がある。

Windowsのネットワークプロトコル

Microsoft Windowsマシン上で2つ以上のプロトコルをインストールした場合、 よくあるブラウジングの問題が発生する。

Warning

2つ以上のプロトコルをMicrosoft Windowsクライアントでは使わない。

すべてのNetBIOSマシンは15分間隔のLMB(とDMB)の選択プロセスに参加する。 複数の選択基準がこの選択プロセスでの決定の順番を決めるのに使われる。 動作しているSambaまたはWindows NTは優先順位が変更されていて、そのため、 最も適したマシンが予想通り決定に勝ち、この役割を保持する。

選択プロセスはすべてのNetBIOSネットワークインタフェースで、 いわば、最後まで行われる。 TCP/IPとIPXがインストールされ、NetBIOSが両方のプロトコルで有効な Windows 9x/Meマシンの場合、選択は両方のプロトコル上で行われる。しばしば 発生するが、もし、Windows 9x/Meマシンが両方のプロトコルを持つ唯一のマシン ならば、LMBはIPXプロトコル上でのNetBIOSインタフェース上で勝つ。 Sambaは、Windows 9x/Meが、LMBがどのマシンかということを知っていると 主張することによって、LMBでなくなる。SambaはLMB機能をやめるため、 すべてのTCP/IPのみで動くマシンのブラウズリスト操作はそのために失敗する。

Windows 95、98、98SEとMeは一般的に Windows9x/Meと言われる。Windows NT4、 200xとXPは共通のプロトコルを使う。これらはざっとWindows NTファミリと言われるが、 2000と XP/2003は、Microsoft Windows NT4とは異なる動作をする新しい 拡張プロトコルを導入したと認識されねばならない。一般的に、サーバーはより新しいか 拡張プロトコルをサポートせず、NT4プロトコルで処理をするようになる。

最も安全な、従うべきルールのすべては単一のプロトコルを使う! である。

名前解決の順序

NetBIOS名からIPアドレスへの名前解決は、いくつもの方式を使って行われる。 NetBIOS名前タイプ情報を提供可能なものは以下の通り:

  • WINS 最適の方法。

  • LMHOSTS 静的でメンテナンスしづらい。

  • Broadcast UDPを使うが他セグメントの名前を解決できない。

名前解決の別の意味は以下を含む:

  • Static /etc/hosts メンテナンスしづらく、名前タイプ情報が欠落している。

  • DNS は良い選択肢だが、基本的なNetBIOS名前タイプ情報が欠落している。

ブロードキャスト名前解決のトラフィックを防ぐこととDNS検索の制限をしたい と考えているサイトが多数ある。name resolve order パラメーターはこれをとても助ける。name resolve order パラメーターの文法は以下の通り:

name resolve order = wins lmhosts bcast host

or

name resolve order = wins lmhosts (bcastとhostを省略)

既定値は:

name resolve order = host lmhost wins bcast

ここで、hostは、UNIXシステムに実装されているgethostbyname() 呼び出しを使う方法である。これは、通常/etc/host.conf/etc/nsswitch.conf/etc/resolv.conf によって制御される。

ブラウジングの技術的な概要

SMBネットワークは、browse listと呼ばれる ネットワーク中のマシンのリストにクライアントがアクセスできる機能を 提供するメカニズムである。このリストには、ネットワーク中の他のマシンに 対してファイルまたは印刷サービスを提供するマシンを含んでいる。サーバーの 機能を現在提供出来ない他のマシンは含んでいない。ブラウズリストはすべての SMBクライアントによって頻繁に使われる。SMBブラウジングの設定はある種の Sambaユーザーには問題があり、そのためにこの文書????? Configuration of SMB browsing has been problematic for some Samba users, hence this document.

Microsoft Windows 2000 とその後継バージョン、Samba とその後継バージョン は、NetBIOS over TCP/IP を使わないように構成できる。この方法で構成した 場合、(DNS/LDAP/ADSでの) 名前解決を正しく設定して動くようにしておくことは 必定である。SMB マシン名から IP アドレスへの名前解決が正しく機能しない場合、 ブラウジングは動作しない。

NetBIOS over TCP/IPが有効な時、WINSサーバーを使うことは、NetBIOS(SMB) 名からIPアドレスへの名前解決を支援するために強く推奨される。 名前解決の他のどの手段でも提供出来ない、リモートセグメントクライアントの NetBIOS名前タイプ情報を提供することがWINSでは出来る。

Sambaでのブラウジングサポート

Sambaはブラウジングを容易にする。ブラウジングはnmbdでサポートされて、 smb.confファイル中のオプションで制御される。Sambaはワークグループの LMBとして動作でき、ドメインログオンとスクリプト機能をサポートする能力を 現在持っている。

SambaはワークグループのDMBとしても動作する。これは、LMBからのリストを 広範囲のネットワークサーバーリストに集めることを意味する。このリスト中 にある名前をブラウズクライアントが解決するために、Sambaとクライアント両方が WINSサーバーを使うことを推奨する。

NTドメインにおいて同じ名前を持つ、ワークグループのドメインマスターに設定 してはならない。各ワイドエリアネットワークで、それがNTかSambaか、 あるいはこのサービスを提供する他のタイプのドメインマスターに関わらず、 ワークグループ毎に一つのみのDMBを設定するようにしなければならない。

Note

nmbdはWINSサーバーとして設定できるが、特段、Sambaを WINSサーバーとして使用することは必要ない。Microsoft Windows NT4、 Microsoft Windows Server又は Advanced Server 200xをWINSサーバーとして 設定できる。WAN上でのNT/200xとSambaの混在環境では、Microsoft WINS サーバーの能力を使うことを推奨する。Sambaのみの環境では、ある1つのSamba サーバーをWINSサーバーとして使うことを推奨する。

ブラウジングを機能させるために、nmbdを通常どおり動作 させるが、どのワークグループにSambaが属するかを制御する、smb.conf 中のworkgroupオプションを使わなければならない。

Sambaは他のサブネット上のブラウジングのために、それ自身を提供するために 便利なオプションも持っている。このオプションは通常でない 使い方のためにのみ使うことを推奨する。例をあげると、インターネット越しの通知 である。smb.confマニュアルページのremote announce を参照のこと。

問題の解決方法

もしもうまく動かない場合、問題を把握するためにlog.nmbd ファイルが役に立つ。問題を発見するために、log level を2または3にしてみる。現在のブラウズリストはbrowse.dat というファイル中に、テキスト形式で格納されていることにも注意。

もしもうまく動かない場合、ファイルマネージャ中で サーバー名を\\SERVERという形で入力することが出来、 enterを入力すると、ファイルマネージャは有効な共有の 一覧を表示する。

[global]セクションでguest accountを 有効なアカウントとして設定していないと、何人かはブラウジングに失敗する。 共有を表示するためのIPC$接続は、guestで行われ、そのため、有効なguest account を設定しておかなければならない。

Note

IPC$共有はすべてのSMB/CIFSクライアントで、 サーバー上で有効なリソースのリストを得るために使われる。 これは、SMB/CIFSサーバーが、Windowsサーバーに対してマイネットワーク経由で Windowsエクスプローラーがリソースを閲覧するために使われる時の、共有とプリンターの リストの元になるものである。この時点で、クライアントは \\server\IPC$リソースに接続を行う。共有をクリックすると、 \\server\shareに接続する。

Microsoft Windows 2000とその後継(Sambaも)はIPC$共有に対する匿名(すなわち guest account)アクセスを無効に出来る。この場合、SMB/CIFSクライアントとして 動作するMicrosoft Windows 2000/XP/2003マシンは、IPC$共有に問い合わせるために 現在ログインしているユーザーの名前を使う。Microsoft Windows 9x/Meはこれが できず、サーバーリソースをブラウズできない。

他の大きな問題はブロードキャストアドレス、ネットマスク、あるいはIPアドレスが 間違っている場合(smb.conf中でinterfaces を指定した場合)である。

サブネット間のブラウジング

Samba1.9.17(α1)のリリースから、Sambaはサブネット境界をまたがってのブラウズリスト の複製をサポートしてきた。この節ではどのようにこの機能を異なった設定中で設定 するかを説明する。

TCP/IPサブネットをまたがったブラウズリストを見るために(すなわち、ブロードキャスト パケットが通らない、ルータによって分離されたネットワーク)、少なくとも1つのWINS サーバーを設定する必要がある。WINSサーバーはNetBIOS名のためのDNS都市的脳する。これは、 WINSサーバーに直接問い合わせを行う事によって、NetBIOS名からIPアドレスへの変換を 可能にする。これは、WINSサーバーマシンのポート137に直接UDPパケットを投げることで 行われる。WINSサーバーは、問い合わせたマシンからのUDPを使うことによって行われる、 既定値のNetBIOSからIPアドレスへの変換の必要性を防ぐ。これは、ある1つのサブネット は、WINSサーバーを使わないで他のサブネット上のマシンの名前を解決することができない ということである。Sambaのハック、すなわちremote browse syncremote announceはUDPのブロードキャストによる伝搬を防ぐ 普通の制限をうまく乗り越えるようにできている。ハックは一般的な解ではなく、 WINSがあるところでは使うべきではなく、最後の手段として考えるべきである。

ネットワーク越えのブラウジングを正しく動かすために、すべてのマシン、すなわち、 Windows95、WindowsNTあるいはSambaサーバーはDHCPサーバー経由かあるいは手動で、 WINSサーバーのIPアドレスを設定する必要があることを思い出してほしい: Windows 9x/MeとWindows NT/200x/XPでは、これはネットワーク設定配下の TCP/IPプロパティ中にあり、Sambaではsmb.confファイル中にある。

NetBIOS over TCP/IPなしでSamba-3を動作させることは可能である。もしも、これを 行う場合、Microsoft ADSの外側で使うと、これは、ネットワークブラウジングサポートを やめることになると警告される。ADSは、すべてのSambaサーバーのために適切な DNSレコードが挿入されるDNSを経由してブラウジングをサポートしている。

サブネット間ブラウジングの動作

サブネット間のブラウジングはとても複雑で、多数の動いている部分を含んでいる。 正確に動くコードが出来るまで、Microsoftは数年掛けることになり、Sambaは それから数年遅れて追いついている。設定が正しければ、Sambaはサブネット間の ブラウジングが出来る機能がある。

サブネット間ブラウジングの例のようなネット ワーク設定を考えてみることにする。

Figure 10.1. サブネット間のブラウジングの例

サブネット間のブラウジングの例

これは、2つのルータ(R1,R2)で接続されている3つのサブネット(1,2,3)から成り立ち、 それらはブロードキャストが届かない。サブネット1はその中に5つのマシンがあり、 サブネット2は4つ、サブネット3は4つマシンがある。すべてのマシンは同じワーク グループ名(単純にするために)に設定されている。サブネット1上のマシンN1-Cは DMB(すなわち、ワークグループのブラウズリストを集める)として設定されている。 マシンN2_DはWINSサーバーとして設定されていて、すべての他のマシンはそのNetBIOS名 をそこに登録している。

それらのマシンが起動するとき、3つのサブネット上それぞれで、マスターブラウザーの 選択作業が発生する。サブネット1上ではマシンN1_Cが選択され、サブネット2上で はN2_Bが、サブネット3上ではN3_Dが選択されると仮定する。それらのマシンはその マシンがいるサブネット上ではLMBとなる。N1_CはそれがDMBとして設定されている ために、サブネット1上のLMBとなる。

各3ネットワーク上で、共有サービスを提供するように設定されたマシンは、その サービスを提供していることをブロードキャストする。各サブネット上のLMBは そのブロードキャストを受け取り、マシンがサービスを提供していることを記録 する。この記録のリストはブラウズリストの基礎となるものである。この場合、 すべてのマシンがサービスを提供するように設定されていることを仮定しているので、 すべてのマシンがブラウズリスト上に載る。

各ネットワークで、そのネットワークのLMBは、ローカルブロードキャスト 経由で受け取ったすべての名前を信頼できると 考える。これは、ローカルブロードキャスト経由でのLMBで見えるマシンは ローカルマスターブラウザーとして同じネットワーク上にいなければならない という理由であり、そのため、信頼された、かつ 検証可能なリソースである。ブラウズリストを 収集する時に学習した他のネットワーク上のマシンは、LMBからは直接見え ない。これらのレコードは信頼できない

この時点で、ブラウズリストは ブラウズリストの例1のようになる (それらはたった今特定のネットワーク上でネットワークコンピューターを 見た時に見えるマシンである)。

Table 10.1. ブラウズリストの例1

サブネットブラウズマスターリスト
サブネット1N1_CN1_A, N1_B, N1_C, N1_D, N1_E
サブネット2N2_BN2_A, N2_B, N2_C, N2_D
サブネット3N3_DN3_A, N3_B, N3_C, N3_D


この時点で、すべてのサブネットは分離され、任意のサブネットをまたいで見える マシンはない。

次に、サブネットのブラウズの例2中のサブネット2を 眺めてみよう。NB_2がLMBになると同時に、そのブラウズリストを同期するDMBを探す。 これは、NetBIOS名 WORKGROUP<1B>に関連づけられているIPアドレスをWINS サーバー(N2_D)に問い合わせることによって行われる。この名前は、WINSサーバーが起動 するとすぐにDMB(N1_C)によって登録される。

N2_BがDMBのアドレスを知ると、DMBに対して、UDPのポート138を使って、 マスターアナウンスパケットを送ることによって、サブネット2 のLMBであることを告げる。次に、NetServerEnum2コールを 行うことで、DMBとの同期作業を行う。これは、DMBが知っているすべてのサーバー名を 送信元に送るようにさせる。DMBがマスターアナウンスパケットを 受け取ると、そのパケットの送信者への同期要求をスケジュールする。両方の同期が 終了すると、ブラウズリストは、 サブネットのブラウズの例2中のようになる。

Table 10.2. サブネットブラウズの例2

サブネットブラウズマスターリスト
サブネット1N1_CN1_A, N1_B, N1_C, N1_D, N1_E, N2_A(*), N2_B(*), N2_C(*), N2_D(*)
サブネット2N2_BN2_A, N2_B, N2_C, N2_D, N1_A(*), N1_B(*), N1_C(*), N1_D(*), N1_E(*)
サブネット3N3_DN3_A, N3_B, N3_C, N3_D

サーバー名の後に(*)が付いたものは信頼されていない名前である。

この時点で、ユーザーは、サブネット1または2上で両方のすべてのサーバーを、ネット ワークコンピューターで見ることができる。サブネット3上のユーザーは引き続き 自分がいるサブネット上のもののみが見える。

N2_Bで起きた同じ手順のイベントがサブネット3のLMB(N3_D)に対して起こる。DMB(N1_A) とブラウズリストの同期を行うと、サブネット1とサブネット2のサーバーエントリを得る。 N3_DがN1_Cと同期を取るとvica versa、ブラウズリストは サブネットのブラウズの例3 のようになる。

Table 10.3. サブネットのブラウズの例3

サブネットブラウズマスターリスト
サブネット1N1_CN1_A, N1_B, N1_C, N1_D, N1_E, N2_A(*), N2_B(*), N2_C(*), N2_D(*), N3_A(*), N3_B(*), N3_C(*), N3_D(*)
サブネット2N2_BN2_A, N2_B, N2_C, N2_D, N1_A(*), N1_B(*), N1_C(*), N1_D(*), N1_E(*)
サブネット3N3_DN3_A, N3_B, N3_C, N3_D, N1_A(*), N1_B(*), N1_C(*), N1_D(*), N1_E(*), N2_A(*), N2_B(*), N2_C(*), N2_D(*)

サーバー名の後に(*)が付いたものは信頼されていない名前である。

この時点で、サブネット1または3上でのネットワークコンピューターでは、 サブネット2上のユーザーが引き続きサブネット1と2上のサーバーのみが見え、 3が見えないのに対し、すべてのサブネット上のサーバーを見る事ができる。

最後に、サブネット2のLMB(N2_B)は再度DMB(N1_C)と同期をとり、抜けていた サーバーエントリを受け取る。最終的に、定常状態(1台もマシンが削除されず、 停止もしていない状態)になると、ブラウズリストは サブネットのブラウズの例4のようになる。

Table 10.4. サブネットのブラウズの例4

サブネットブラウズマスターリスト
サブネット1N1_CN1_A, N1_B, N1_C, N1_D, N1_E, N2_A(*), N2_B(*), N2_C(*), N2_D(*), N3_A(*), N3_B(*), N3_C(*), N3_D(*)
サブネット2N2_BN2_A, N2_B, N2_C, N2_D, N1_A(*), N1_B(*), N1_C(*), N1_D(*), N1_E(*), N3_A(*), N3_B(*), N3_C(*), N3_D(*)
サブネット3N3_DN3_A, N3_B, N3_C, N3_D, N1_A(*), N1_B(*), N1_C(*), N1_D(*), N1_E(*), N2_A(*), N2_B(*), N2_C(*), N2_D(*)

サーバー名の後に(*)が付いたものは信頼されていない名前である。

DMBとLMBの同期は引き続き行われるが、これは定常状態の操作として 行われる。 Synchronizations between the DMB and LMBs will continue to occur, but this should remain a steady-state operation.

もしもルータR1かR2が故障した場合、以下のことが発生する:

  1. アクセスできないネットワーク部分にある各コンピューター名は、ネットワークコンピューター ネットワークコンピューターのリスト中に36分維持される。

  2. それらアクセスできないコンピューターへの接続は失敗するが、ネットワークコンピューター のリスト中からは消えない。

  3. もしも、あるネットワーク部分からWINSサーバーが見えなくなると、サブネットで 分割されたブロードキャストによるNetBIOS名前解決を使ったローカルサブネット 上のサーバーにのみアクセスできる。この結果はDNSサーバーへのアクセスが出来なく なることと似ている。

よくあるエラー

ブラウジングに関する質問は数多くメーリングリスト上に投稿される。 ブラウジングに関する大多数の問題は、NetBIOS名前解決の間違った設定に 起因するものである。ただ、いくつかは特に注目に値する。

SambaのNetBIOS名前キャッシュのフラッシュ

Sambaを再起動しないでSambaのNetBIOS名前キャッシュをフラッシュする方法はあるか?

Sambaのnmbdプロセスはすべてのブラウザーリストハンドリングを 制御する。通常の環境では、nmbdの再起動に問題はない。これは SambaのNetBIOS名キャッシュをフラッシュする効果があり、再構築を行う。 これは、異常なマシン名は再度ブラウズリストに現れないということが確実になる わけではない。nmbdがサービスを停止後、ネットワーク上の他の マシンがブラウズマスターになる。この新しいリスト中には異常なエントリがそのまま 含まれるかもしれない。もしもリストから異常なマシンを消したいのならば、ネットワーク 上のすべてのマシンをシャットダウンし、すべてのマシンが停止後に再起動しなければ ならない。完全な再起動に失敗すると、唯一出来る他のことは、エントリがタイムアウト するまで待ち、その後リストからフラッシュされる。これは、ある種のネットワークでは 長い時間(月単位)かかる。

サーバーリソースがリスト出来ない

あるクライアントは"This server is not configured to list shared resources."と報告した。

おそらく何らかの理由でゲストアカウントが無効になっている。Sambaは smbdでブラウジングするためにゲストアカウントを使う。 ゲストアカウントが有効か確認する。

smb.conf マニュアルページのguest accountも参照 のこと。

"Unable to browse the network"というエラーメッセージが出た。

このエラーは複数の原因が考えられる:

  • LMBがない。nmbdを設定するか、他のマシンでLMBを立てる。

  • LMBマシンにログオンできない。 ゲストユーザーでログオンできるか?

  • LMBに対してIPレベルで接続できない。 ブロードキャストで到達可能か?

共有とディレクトリのブラウジングが非常に遅い

テストネットワークに2台だけマシンがあったとする。1つはSambaサーバーで他はWindows XPマシンである。 認証とログオンは正常に動作するが、Sambaサーバー上の共有を表示させようとするとWindows XP クライアントは反応がなくなる。時々、数分反応がなくなる。最終的にはWindowsエクスプローラーは 反応して問題なくファイルとディレクトリを表示する。

しかし、共有はコマンドシェル(cmd)でDOSコマンドを使うと すぐに使える。これはSambaの問題か、それともWindowsの問題か?この問題の解決 方法は?

いくつかの可能性がある:

ネットワークハードウェアの不良

最も一般的な、不完全なハードウェアの問題は、低コストまたは不完全なハブ、 ルータ、ネットワークインタフェース(NIC)と良くないケーブルに集中する。 もしも、ハードウェアの1部分が不良だと、ネットワーク全体が被害を受ける かもしれない。悪いハードウェアはデータの喪失を引き起こす。ほとんどの ネットワークハードウェアの不良問題は見た目のネットワークトラフィックの 増大をもたらすがそれだけではない。

Windows XPのWebClient

数多くのサイトで、同様のネットワークブラウジングが遅くなる問題が報告され、 WebClientサービスを停止すると、問題が出なくなることがわかっている。これは、 動けば簡単な解であるという理由で、確かに探求されるべきことで ある。

矛盾しているWINSの設定

このタイプの問題は、あるクライアントがWINSサーバーを使うように設定され て(それはTCP/IP設定で)、ネットワーク上にWINSサーバーがない場合である。 言い換えると、WINSサーバーがあり、Sambaがそれを使うように設定されて いない場合である。NetBIOS over TCP/IPを使う場合はWINSの使用は強く 推奨される。すべてのクライアントでNetBIOS over TCP/IPを無効にしている ならば、SambaはWINSサーバーとして設定されるべきでも、それを使うように されるべきでもない。

不正なDNS設定

もしも、NetBIOS over TCP/IPが無効になっているならば、Active Directory が使われ、DNSサーバーが正しく設定されない。詳細な情報は、 DNSとActive Directory を参照のこと。

不正なキャッシュされた共有参照はネットワークブラウジングに影響する

Microsoft Windowsクライアント(ワークステーションまたはサーバー)上での、存在しない 共有あるいはサーバーに対するキャッシュされた参照はそれらの共有に接続する際に、 Microsoft Windowsエクスプローラーが無反応になると言う現象を引き起こす。しばらく経つと (かなり長い時間だが)、タイムアウトになり、ブラウジングが通常通りになる。

この現象を除くために、腐ったキャッシュされた参照は取り除かれるべきである。 これは自動的には起こらず、手動での作業が必要である。これはMicrosoft Windows のデザインによるものであり、Sambaで変えることは出来ない。現時点で無効になって いる、マイネットワーク内の共有またはサーバーへの無効な ショートカットを削除するためには、 HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\ 配下にあるWindows レジストリを編集する必要がある。エントリ MountPoints2(Windows XP以降、またはWindows 2000以前では MountPoints)を編集する。 \\server\shareという名前(ここで'server'と'share'は 存在しないサーバーまたは共有を参照している)のすべてのキーを削除する。

Note

存在しないネットワークリンクの削除はユーザー単位で行う必要がある。言い換えると、 Microsoft Windowsエクスプローラー内でのマイネットワーク 中のショートカットは、右クリックして削除を選択することで 削除できる。

Sambaのユーザーは、Windows、SambaとNovellサーバーのネットワークブラウジングに 対して、これらの存在しない参照が、悪影響を及ぼすと報告している。これは Sambaサーバーに関連しない一般的な問題であると思われる。Sambaユーザーは、 Sambaが、時として人柱ツールとして見られていることがあるために、しばしば これを経験するかもしれない。これは、異なった名前、異なった共有で何回かSamba サーバーを再設定したり元に戻すことをユーザーが行うことという事実の結果は、 不完全(不正)なキャッシュされた共有参照が出来てしまうことを増大させてしまう。 Windowsクライアントは、それらの参照を満了としないので、手動による削除を必要とする。

現在アクセスするディレクトリにいなくても、すべてのキャッシュされた参照を見に いくことを試みるので、ダイアログボックスのオープンは (たとえばWordやExcel)、一般的に反応がとても遅くなる。