Chapter 29. Microsoft Windows ネットワークへのSambaの統合
Prev | Part III. 詳細な設定方法 | Next

## Chapter 29. Microsoft Windows ネットワークへのSambaの統合

### John H. Terpstra

Samba Team

`<jht@samba.org>`

(Jan 01 2001)

この章ではNetBIOS over TCP/IPの名前からIPアドレスを解決する事について取り扱う。もしも、使用しているWindowsクライアントがNetBIOS over TCP/IPを使うように設定されていない場合、この章は使用している環境には適用されない。もしも使用している設定が、NetBIOS over TCP/IPを使うのであれば、この章はネットワークの問題を解決するのに手助けとなるだろう。

### Note

NetBIOS over TCP/IPはNetBEUIとは関係ない。NetBEUIはNetBIOS over Logical Link Control(LLC)である。最近のネットワークでは、NetBIOSを動かさないことを強く推奨している。また、NetBEUI over TCP/IPというようなものはない。そのようなプロトコルは、全く完全に誤解である。

## 機能と利便性

多くのMicrosoft Windows ネットワーク管理者は、UNIX/Linux OS中で実装されているような基本的なTCP/IPネットワーキングに一度も出会ったことはない。同じく、多くのUNIXとLinux管理者は、Microsoft Windows TCP/IPベースのネットワークの複雑さ(とそれに対する願望は無いかもしれない)に出会ったことがない。

この章では、各OS環境において、どのように、名前がIPアドレスに解決されるかについての基本について、簡単に紹介する。

## 背景情報

Microsoft Windows 2000から、Microsoft Windows ネットワークをNetBIOS over TCP/IPなしで動かすことが可能になった。NetBIOS over TCP/IPは、NetBIOS名前解決にUDPポート137を、NetBIOSセッションサービスにTCPのポート139を使う。NetBIOS over TCP/IPが、Microsoft Windows 2000とそれ以降のクライアントで無効になると、TCPポート445のみが使われ、UDPポート137とTCPポート139は使われなくなる。

### Note

Windows 2000かそれ以降のクライアントを使うとき、もしも NetBIOS over TCP/IPが無効になっていない場合、クライアントはUDPポート137(NetBIOSネームサービスであり、Windows Internet Name serviceあるいはWINSとしても知られている)とTCPポート445(実際のファイルと印刷データの転送)を使う。

NetBIOS over TCP/IPが無効の場合、DNSの使用が基本である。現在ほとんどの、NetBIOS over TCP/IPを無効にした環境では、Microsoft Active Directoryサービス(ADS)を使っている。ADSはサービスリソースレコード(SRV RR)と増分ゾーン転送(IXFR)を使う、ダイナミックDNSを要求する。ADSと同時にDHCPを使うことは、クライアントワークステーションネットワーク設定上で集中制御管理を行う手段として推奨される。

## 純粋なUNIX/Linux環境中での名前解決

この節が対象としている重要な設定ファイルは以下の通り:

- `/etc/hosts`

- `/etc/resolv.conf`

- `/etc/host.conf`

- `/etc/nsswitch.conf`

### `/etc/hosts`

このファイルは静的なIPアドレスと名前の一覧を含んでいる。

    127.0.0.1	localhost localhost.localdomain192.168.1.1	bigbox.quenya.org	bigbox	alias4box

`/etc/hosts`の目的は、名前解決メカニズムを提供することであり、ユーザはIPアドレスを覚えなくても済むようになる。

物理的なネットワーク転送レイヤ上で送られたネットワークパケットは、IPアドレスを使うのではなく、メディアアクセスコントロールアドレス、あるいはMACアドレスを使って通信を行う。IPアドレスは、現在32ビット長で、通常ドット(あるいはピリオド)で分割された4つの十進数で表現される。たとえば、168.192.1.1である。

MACアドレスは48ビット(あるいは6バイト)であり、通常2桁の16進数をコロンで分離して表現される。たとえば 40:8e:0a:12:34:56.である。

すべてのネットワークインタフェースはMACアドレスを持たねばならない。MACアドレスに対して1つ以上のIPアドレスを割り当てることができる。IPアドレスとMACアドレスの間に何らの関係はない。そのようなすべての割り当ては、任意、あるいは自由に行える。最も基本的なレベルでは、すべてのネットワーク津心は、MACアドレスを使って行われる。MACアドレスがグローバルに一意で、一般的に、特定のインタフェースに固定されているので、IPアドレスの割り当てはネットワーク管理の視点から意味をなす。1つ以上のIPアドレスをMACアドレス毎に割り当てられる。1つのアドレスはプライマリIPアドレスである必要がある。これは、アドレス解決プロトコル(ARP)の問い合わせで帰ってくるアドレスである。

ユーザあるいはプロセスが他のマシンと通信したい場合、プロトコルは、“マシン名”あるいは“ホスト名”が、TCP/IP設定制御ファイルで制御される方法で、IPアドレスに解決されるように実装されている。`/etc/hosts`はそのようなファイルの1つである。

送信先のインタフェースのIPアドレスが決まったとき、ARP/RARPと呼ばれるプロトコルが、対象インタフェースのMACアドレスを識別するのに使われるARPは、すべて1であるMACアドレスを使って、ローカルネットワークセグメント上のすべてのインタフェースに対してUDPを使って送信する、ブロードキャストベースの方法である。ネットワークインタフェースは2つのMACアドレスのみに返信する。そのインタフェース固有のアドレスと、ff:ff:ff:ff:ff:ffというアドレスである。ARP要求からの返信パケットにはMACアドレスと各インタフェースのプライマリIPアドレスが含まれている。

`/etc/hosts`ファイルはすべてのUNIX/Linux TCP/IPインストールの基本であり、最低でも、localhostとローカルネットワークインタフェースのIPアドレスとローカルマシン上のプライマリ名を含んでいる。このファイルは、名前解決方法の出発点となる。つまり、その他の名前解決機構を利用する前に、基本的な名前解決は行われている。

### `/etc/resolv.conf`

このファイルで名前解決ライブラリを指定する:

- マシンが存在するドメインの名前

- 完全に一意でないホスト名をIPアドレスに解決しようとする時に 自動的に検索されるべき任意のドメイン名。

- 名前解決検索を実行するのに問い合わせされる、有効なドメイン ネームサーバのIP仇レスか名前。

### `/etc/host.conf`

`/etc/host.conf`は、`/etc/resolv.conf`中で設定できるようにするための主要な手段である。これはきわめて重要な設定ファイルである。このファイルは名前解決が処理されるかもしれない順序を制御する。通常の構造は以下の通り:

    order hosts,bindmulti on

両方のアドレスが返されるべきである。詳細については、`host.conf`マニュアルページを参照のこと。

### `/etc/nsswitch.conf`

このふぁいるは実際の名前解決先を制御する。ファイルは通常以下のようにリゾルバオブジェクト指定を記述する:

    # /etc/nsswitch.conf## Name Service Switch 設定ファイル#passwd:		compat# Alternative entries for password authentication are:# passwd:	compat files nis ldap winbindshadow:		compatgroup:		compathosts:		files nis dns# Alternative entries for host name resolution are:# hosts:	files dns nis nis+ hesiod db compat ldap winsnetworks:	nis files dnsethers:		nis filesprotocols:	nis filesrpc:		nis filesservices:	nis files

もちろん、それらの各メカニズムは、適切な機能かサービスを正しく設定する事を要求する。

ネットワーク要求/メッセージを送ることが必要にならない限り、TCP/IPネットワークは何もデータを送らないことに注意すべきである。すべてのTCP/IP通信は、必要時にのみ通信を行うという原則を仮定している。

バージョン 2.2.0から、Sambaはname service switch機構用の拡張のために、Linuxをサポートするようになり、Linuxクライアントは、Microsoft Windows NetBIOSの名前解決機能を使えるようになった。この機能を使うためには、Sambaはmakeコマンドで適切な引数を付けてコンパイルする必要がある(すなわち、`make nsswitch/libnss_wins.so`)。次に名前解決ライブラリを`/lib`ディレクトリにインストールし、`wins`パラメータを、`/etc/nsswitch.conf`ファイル中の“hosts:”行に追加する必要がある。この時点で、SambaサーバとMicrosoft Windowsマシンが存在するワークグループ内にいる、どこかのMicrosoft Windowsマシンに対してNetBIOSマシン名でping出来る。

## Microsoft Windowsネットワーク内でのような名前解決

Microsoft Windowsネットワークは、各マシンに割り当てられた名前をベースにしている。これは、“コンピュータ名”,“マシン名”,“ネットワーキング名”,“NetBIOS名”あるいは“SMB名”という、種々の(そして矛盾した)名前で呼ばれている。すべての単語は、ワークグループかドメイン名の名前にも適用できる“NetBIOS名”を除いて同じものを意味する。“ワークグループ”と“ドメイン”という単語は、実際、どのマシンが関連づけられているかという、単なる名前である。すべてのNetBIOS名はきっかり16文字である。16番目の文字は予約されている。登録されたNetBIOS名のサービスレベル情報を指定する1バイトとして使われる。そのため、NetBIOSマシン名は、クライアント/サーバによって提供される各サービスタイプで登録される。

一意なNetBIOS名とグループ名の表は、典型的なNetBIOS名前/サービスタイプ登録一覧である。

Table 29.1. 一意なNetBIOS名

MACHINENAME<00> | MACHINENAME上でサーバサービスが動いている
MACHINENAME<03> | 一般的なマシン名(NetBIOS名)
MACHINENAME<20> | LanManサーバサービスがMACHINENAMEで動いている
WORKGROUP<1b> | ドメインマスタブラウザ

Table 29.2. Group Names

WORKGROUP<03> | WORKGROUPのすべてのメンバによって登録された一般的な名前
WORKGROUP<1c> | ドメインコントローラ/ネットログオンサーバ
WORKGROUP<1d> | ローカルマスタブラウザ
WORKGROUP<1e> | ブラウザ選定サービス

すべてのNetBIOSマシンは、それに固有の名前を一意なNetBIOS名とグループ名単位で登録することに注意すべきである。これは、システム管理者が、`/etc/hosts`中か、DNSデータベース中で、各IPアドレスに割り当てられる名前を決める伝統的な決め方をするTCP/IPでの流儀と大きく異なる。

明確な説明の中の、1つの重要なポイントに注意すべきである。`/etc/hosts`ファイルとDNSレコードは、それが必要かもしれないサービスのタイプを見つけることに、Microsoft Windowsクライアントが依存する、NetBIOS名前情報を提供しない。これの例は、Microsoft Windowsクライアントがドメインログオンサーバを捜そうとする時に起こる事である。クライアントは名前タイプ*<1C>を登録しているすべてのマシンを列挙するために(NetBIOSブロードキャスト経由で)検索を実行することによって、このサービスと、このサービスを提供しているサーバのIPアドレスを捜す。次にログオン要求は、IPアドレスの一覧として返された各IPアドレスに送られる。どれかのマシンが最初に応答すると、次にそのマシンがログオンサービスを提供することになる。

Microsoft Windows ネットワークのセキュリティアーキテクチャを示している付加的な意味を持っているので、“ワークグループ”および“ドメイン”という名前は、まったくもって紛らわしい。“ワークグループ”という単語は、ネットワーク環境の基本原則がピアツーピア構造になっている事を示している。ワークグループにおいては、すべてのマシンは、自分自身のセキュリティについて責任があり、一般的にそのセキュリティは、パスワードの使用で制限される(共有レベルのセキュリティとして知られている)。ピアツーピアのネットワークを使うほとんどの場合、自分自身のマシンを制御するユーザは単に全くセキュリティを持たないように(訳注:共有しないように)するだろう。ワークグループ環境でもユーザレベルのセキュリティを使うことは可能で、その場合、ユーザ名と対応するパスワードを使うことを要求する。

Microsoft Windowsネットワークは、ローカルとリモートマシンすべてでのメッセージ通信用のマシン名を使うために、前もって決定される。使われるプロトコルは、Server Message Block (SMB)と呼ばれ、これはNetBIOSプロトコル(Network Basic Input/Output System)を使って実装される。NetBIOSはLLC(Logical Link Control)プロトコルを使ってカプセル化される。 この場合、結果のプロトコルはNetBEUI(Network Basic Extended User Interface)と呼ばれる。NetBIOSは、Novell NetWareによって使われるIPX(Internetworking Packet Exchange)上でも動作できる。また、TCP/IPプロトコル上でも動作でき、この場合、結果のプロトコルは、NBTあるいはNetBT、すなわちNetBIOS over TCP/IPと呼ばれる。

Microsoft Windows マシンは、たくさんの複雑な名前解決メカニズムを使う。主にTCP/IPで接続するので、このデモはその領域にのみ限っている。

### NetBIOSネームキャッシュ

すべてのMicrosoft Windowsマシンは、おおよそ過去10分から15分の間に通信したすべての外部マシンのNetBIOS名とIPアドレスを格納する、メモリ中のバッファを使う。設定されたすべての名前解決機構を使って行うよりも、ローカルキャッシュからマシンのIPアドレスを得る方がより効率的である。

もしも、ローカル名前キャッシュにその名前があるマシンが、キャッシュ上で満了になり削除される前にシャットダウンした場合、そのマシンへメッセージ交換を行おうとすると、そのマシンはタイムアウトするだろう。その名前がキャッシュにあるので、名前解決は成功するが、マシンは反応しない。これは、ユーザにとって不満を感じさせるが、これはプロトコルの特性である。

NetBIOS名前キャッシュの検査を行うMicrosoft Windows ユーティリティは、“nbtstat”である。Sambaにおける同等品は`nmblookup`である。

### LMHOSTSファイル

このファイルは通常Microsoft Windows NT 4.0かWindows 200x/XPのディレクトリ`%SystemRoot%\SYSTEM32\DRIVERS\ETC`にあり、IPアドレスとマシン名が対になったものを含む。`LMHOSTS`ファイルはNetBIOS名からIPアドレスへのマッピングを行う。

典型的なものは以下の通り:

    # Copyright (c) 1998 Microsoft Corp.## This is a sample LMHOSTS file used by the Microsoft Wins Client (NetBIOS# over TCP/IP) stack for Windows98## This file contains the mappings of IP addresses to NT computer names# (NetBIOS) names. Each entry should be kept on an individual line.# The IP address should be placed in the first column followed by the# corresponding computer name. The address and the computer name# should be separated by at least one space or tab. The "#" character# is generally used to denote the start of a comment (see the exceptions# below).## This file is compatible with Microsoft LAN Manager 2.x TCP/IP lmhosts# files and offers the following extensions:##      #PRE#      #DOM:#      #INCLUDE #      #BEGIN_ALTERNATE#      #END_ALTERNATE#      \0xnn (non-printing character support)## Following any entry in the file with the characters "#PRE" will cause# the entry to be preloaded into the name cache. By default, entries are# not preloaded, but are parsed only after dynamic name resolution fails.## Following an entry with the "#DOM:" tag will associate the# entry with the domain specified by . This effects how the# browser and logon services behave in TCP/IP environments. To preload# the host name associated with #DOM entry, it is necessary to also add a# #PRE to the line. The  is always pre-loaded although it will not# be shown when the name cache is viewed.## Specifying "#INCLUDE " will force the RFC NetBIOS (NBT)# software to seek the specified  and parse it as if it were# local.  is generally a UNC-based name, allowing a# centralized lmhosts file to be maintained on a server.# It is ALWAYS necessary to provide a mapping for the IP address of the# server prior to the #INCLUDE. This mapping must use the #PRE directive.# In addition the share "public" in the example below must be in the# LanMan Server list of "NullSessionShares" in order for client machines to# be able to read the lmhosts file successfully. This key is under# \machine\system\currentcontrolset\services\lanmanserver\# parameters\nullsessionshares# in the registry. Simply add "public" to the list found there.## The #BEGIN_ and #END_ALTERNATE keywords allow multiple #INCLUDE# statements to be grouped together. Any single successful include# will cause the group to succeed.## Finally, non-printing characters can be embedded in mappings by# first surrounding the NetBIOS name in quotations, then using the# \0xnn notation to specify a hex value for a non-printing character.## The following example illustrates all of these extensions:## 102.54.94.97     rhino     #PRE #DOM:networking  #net group's DC# 102.54.94.102    "appname  \0x14"       #special app server# 102.54.94.123    popular   #PRE         #source server# 102.54.94.117    localsrv  #PRE         #needed for the include## #BEGIN_ALTERNATE# #INCLUDE \\localsrv\public\lmhosts# #INCLUDE \\rhino\public\lmhosts# #END_ALTERNATE## In the above example, the "appname" server contains a special# character in its name, the "popular" and "localsrv" server names are# pre-loaded, and the "rhino" server name is specified so it can be used# to later #INCLUDE a centrally maintained lmhosts file if the "localsrv"# system is unavailable.## Note that the whole file is parsed including comments on each lookup,# so keeping the number of comments to a minimum will improve performance.# Therefore it is not advisable to simply add lmhosts file entries onto the# end of this file.

### HOSTSファイル

このファイルは、通常Microsoft Windows NT 4.0あるいはWindows 200x/XPのディレクトリ`%SystemRoot%\SYSTEM32\DRIVERS\ETC`中にあり、IPアドレスとIPホスト名が対になったものを含む。これは、名前解決機構として使うことが出来るが、どのようにTCP/IP環境が設定されたかに依存する。このファイルはUNIX/Linuxでの`/etc/hosts`ファイルと同じ使い方である。

### DNSによる検索

この機能は、ネットワーク設定機能中のTCP/IPに関する設定の中で設定できる。もしもこれが有効になると、どのようにNetBIOSノードタイプパラメータが設定されたかに正確に依存して決まる、選択された名前解決シーケンスが後に続く。ノードタイプ0は、NetBIOS名前キャッシュ中で名前検索をしても見つからなかった場合、NetBIOSブロードキャスト(UDP上のブロードキャスト)が使われる。もしも、失敗した場合、次にDNS、HOSTSとLMHOSTSが使われる。もしもノードタイプが8ならば、DNS,HOSTS,LMHOSTSの検索から結果を得る前に、NetBIOSユニキャスト(UDPユニキャストで)がWINSサーバに送られるか、ブロードキャスト検索が使われる。This capability is configured in the TCP/IP setup area in the network configuration facility. If enabled, an elaborate name resolution sequence is followed, the precise nature of which is dependent on how the NetBIOS Node Type parameter is configured. A Node Type of 0 means thatNetBIOS broadcast (over UDP broadcast) is used if the name that is the subject of a name lookup is not found in the NetBIOS name cache. If that fails, then DNS, HOSTS, and LMHOSTS are checked. If set to Node Type 8, then a NetBIOS Unicast (over UDP Unicast) is sent to the WINS server to obtain a lookup before DNS, HOSTS, LMHOSTS, or broadcast lookup is used.

### WINSによる検索

WINS(Windows Internet Name Server)サービスはrfc1001/1002で定義されたNBNS(NetBIOSネームサーバ)と同等のものである。WINSサーバは、もしもTCP/IP設定で、少なくとも1つのWINSサーバのIPアドレスを指定したとき、Windows クライアントによって登録される名前とIPアドレスを格納する。

SambaをWINSサーバサーバとして設定するには、以下のパラメータを`smb.conf`ファイルに追加する必要がある:

`wins support = Yes`

SambaをWINSサーバを使うように設定するためには、以下のパラメータを`smb.conf`ファイルに追加する必要がある:

`wins support = No`
`wins server = xxx.xxx.xxx.xxx`

ここで、`xxx.xxx.xxx.xxx`は、WINSサーバのIPアドレスである。

SambaをWINSサーバとして設定するための情報は、ネットワークブラウジングを参照のこと。

## よくあるエラー

TCP/IPネットワーク設定の問題は、すべてのネットワーク管理者が遅かれ早かれ直面する。原因は、キーボード入力の問題から、単純なケアレスミスまで多様である。もちろん、誰もが常時不注意であるというわけではない!

### 片方向しかpingが届かない

“WindowsからSambaサーバにpingが出来るが、SambaサーバからWindowsにpingが できない。”

WindowsマシンはIPアドレスが192.168.1.2で、ネットマスクが255.255.255.0であり、 Sambaサーバ(Linux)はIPアドレスが192.168.1.130で、ネットマスクが 255.255.255.128である。マシンはローカルネットワーク上にあり、その他の外部 接続はない。

整合していないネットマスクのため、Windowsマシンは、ネットワーク192.168.1.0/24上に いて、Sambaサーバはネットワーク192.168.1.128/25にいる。 これは論理的に異なったネットワークである。

### ネットワーク接続がとても遅い

遅いネットワークという共通の問題には以下がある:

- クライアントがDNSを使うように設定されていて、DNSサーバがダウンしている。

- クライアントがリモートのDNSサーバサーバを使うように設定されているが、 リモート接続がダウンしている。

- クライアントがWINSサーバを使うように設定されているが、 WINSサーバがない。

- クライアントがWINSサーバを使うように設定されていないが、 WINSサーバがある。

- ファイアウォールがDNSかWINSトラフィックを制限している。

### Sambaサーバ名前変更の問題

“Sambaサーバの名前が変わり、Sambaが再起動した後、Sambaサーバへ、新しい 名前で、Microsoft Windows NT4ワークステーションからpingが出来ない。しかし、 古い名前でのpingは引き続き出来るなぜ?”

この説明から、以下の3つが明白となる:

- WINSが使われていないブロードキャストベースの名前解決のみ使われている。

- Sambaサーバが改名されて再起動したのが10分か15分前以内である。

- 古いSambaサーバ名が、まだMicrosoft Windows NT4 ワークステーション 上のNetBIOS名前キャッシュ中にある。

Microsoft Windows NT4マシン上のNetBIOS名前キャッシュ中に、どの名前が存在して いるかを調べるには、`cmd`シェルを開き、以下を行う:

    C:\> nbtstat -n              NetBIOS Local Name Table   Name                 Type          Status------------------------------------------------FRODO            <03>  UNIQUE      RegisteredADMINISTRATOR     <03>  UNIQUE      RegisteredFRODO            <00>  UNIQUE      RegisteredSARDON           <00>  GROUP       RegisteredFRODO            <20>  UNIQUE      RegisteredFRODO            <1F>  UNIQUE      RegisteredC:\> nbtstat -c             NetBIOS Remote Cache Name Table   Name                 Type       Host Address     Life [sec]--------------------------------------------------------------GANDALF	<20>  UNIQUE      192.168.1.1          240C:\>

この例では、GANDALFがSambaサーバでFRODO が、Microsoft Windows NT4 ワークステーションである。 最初の行は、ローカル名前テーブルの内容を示していて(すなわち、Microsoft Windows ワークステーションとして識別される)、2行目はNetBIOS名前キャッシュ中に あるNetBIOS名を示している。 名前キャッシュ中にはこのワークステーションの名前として知られているリモートマシン を含んでいる。

Prev | Up | Next
Chapter 28. PAM ベースの分散型認証 | Home | Chapter 30. ユニコード/文字セット