上野家のホームページ - 資料室バックアップ : PC/ネットワーク関連/Windowsネットワークのソース

[ 差分 | バックアップ | リロード ]
差分を表示
PC/ネットワーク関連/Windowsネットワークへ行く。
#topicpath

#contents

*Microsoft ネットワーク [#n2219829]
MSのネットワークの仕組みは，度重なる仕様拡張の結果，複雑で難解なものになってしまっている。~
時々ネットワーク上にマシンがリストアップされないなど問題がよく起きます。

ネットワーク上のファイルサーバー機能等とWindowsでのブラウズ機能は，ネットワーク上で各マシンを使う上では同時に使うものではあるが，機能は別々の機能である。

**NetBEUIとNBT [#t05ba3f4]
初期のプロトコルのNetBEUIでは，NetBIOS名（つまり名前）で通信相手を識別している。TCP/IPではIPアドレスで通信相手を識別するが，それがNetBIOS名で行われている。NetBIOSでは，名前にはグループ名とユニーク名が使える。グループ名はマルチキャストのように使用できる。名前だけなので，セグメント超えの通信は出来ない。

NetBEUIでは，セグメントを超えての通信は出来ないので，これをTCP/IPのプロトコルを使うようにしたのが，NetBIOS over TCP/IPで通称NBTと言っている。

**NBTとLMHOSTS [#y7c31cb0]
NBTはTCP/IPを使うのでセグメントを超えた通信が可能である。ただNetBIOSは内部的には名前で通信するので，セグメントを超えたブロードキャストが出来ないため，何らかの方法で名前の解決をする必要がある。そこで考えられたのがLMHOSTSファイルでの名前解決である。（NTドメインの頃に拡張された）
|文法|意味|
|x.x.x.x コンピュータ名 #PRE|NetBIOSキャッシュに強制的に登録する|
|x.x.x.x コンピュータ名 #DOM:ドメイン名|x.x.x.xのIPアドレスをドメイン名<1C>のインターネットグループに登録する|
|x.x.x.x コンピュータ名 #MH|登録されたコンピュータ名のマシンは，マルチホーム（LANカードが複数ある）と見なす|
LMHOSTSの情報は，ローカルネットワークにブロードキャストを行った後で参照される。NT3.1頃は，サブネット越えの通信を行うのはあまり無かったのかもしれないので，まあ妥当だったのかな。

LMHOSTSで相手の名前(NetBIOS名)を正しく設定しておかないと，IP通信ではちゃんとパケットが届いているのに，NetBIOSの通信がうまくいかないといったことも起きる。単にNetBEUIをTCP/IPでカプセル化しただけなので，実際にはIPアドレスとNetBIOS名と2つの宛先があるということで，通信をするときに両方をチェックする必要があるから。

**コンピュータ名とホスト名 [#g51d8bff]

コンピュータ名はNetBIOSでの通信では相手を識別するものになり，かならずネットワーク上でユニーク名になっていなければならない。同じ名前が別のマシンに使っていると警告ダイアログが出てその名前が使えない事を時々経験する。((これがよく起きるんだよなぁ))~
一方TCP/IPでのホスト名ってのは単なるIPアドレスのエリアスで，実際の通信にはIPアドレスを使うため，別にユニークである必要はない。
***NetBIOS名 [#m209d889]

コンピュータ名とホスト名を表すNetBIOS名であるが，当初IBMが規格を定めた時点では16バイト以内という規定のみであった。~
しかしMicrosoftは，最終の16バイト目を機能を表すような識別子に利用する事にし，「名前」を15バイト以内に変更した。この時，名前が15バイトに満たない場合は，15バイト目までスペース（0x20）で埋められる。なお通常は，XXXXXYYYYY&lt;00&gt;のようにして名前と識別子を表示することが多い。

XXXXXYYYYY&lt;00&gt;

 ,X,X,X,X,X,Y,Y,Y,Y,Y, , , , , ,0x00, <-- 16バイト目が0x00

NetBIOS名の16バイト目識別子の主な種類

|>|種別|内容|h
|00|ユニーク|ワークステーションサービス名|
|03|ユニーク|メッセンジャーサービス名|
|06|ユニーク|RASサーバサービス名|
|1B|ユニーク|ドメインマスタブラウザ名|
|1D|ユニーク|マスタブラウザ名|
|20|ユニーク|ファイルサーバサービス名|
|21|ユニーク|RASクライアントサービス名|
|22|ユニーク|Microsoft Exchange Interchange (MSMailコネクタ)|
|23|ユニーク|Microsoft Exchangeストア|
|24|ユニーク|Microsoft Exchange Directory|
|30|ユニーク|モデム共有サーバサービス名|
|31|ユニーク|モデム共有クライアントサービス名|
|42|ユニーク|MccAffeeのウイルス対策プログラム|
|43|ユニーク|SMSクライアントのリモートコントロール|
|44|ユニーク|SMS管理者のリモートコントロールツール|
|45|ユニーク|SMSクライアントリモートチャット|
|46|ユニーク|SMSクライアントリモート間転送|
|4C|ユニーク|Windows NT上のDEC Pathworks TCP/IPサービス|
|52|ユニーク|Windows NT上のDEC Pathworks TCP/IPサービス|
|6A|ユニーク|Microsoft Exchange IMC|
|87|ユニーク|Microsoft Exchange MTA|
|BE|ユニーク|ネットワークモニタエージェント|
|BF|ユニーク|ネットワークモニタアプリケーション|
|00|グループ|ドメイン/ワークグループ名|
|01|グループ|マスタブラウザ|
|1C|グループ|ドメインコントローラ|
|1E|グループ|セグメント内のポテンシャルブラウザ|

名前には，ユニーク名とグループ名という区別がある。ユニーク名は1台のマシンしか登録できない名前だが，グループ名は複数のマシンが登録することができる。グループ名を宛先に指定された通信フレームは，そのグループ名を登録した全てのマシンが受信することができる。つまり一種のマルチキャストのような事が出来るということ。

**NBTでの名前の登録と解決 [#g4be5913]

NBTの場合，NetBIOS名の登録や解放といった動作は，UDP/137 を用いたローカルサブネットへのブロードキャストで行う。NetBEUIとやっていることは同じ事である。

同一物理ネットワーク内に通信相手がいる場合の名前解決はNetBEUIとほとんど同様で，ローカルサブネットへのIPブロードキャストパケットで，例えばXXXXXYYYYY&lt;20&gt;という名前の問い合わせが行われ，それに対して名前を登録しているXXXXXYYYYYがユニキャストで聞いた相手に対して，Successというステータスで応答する。~
あるマシンが，NBTレベルで登録した名前は

 > nbtstat -a コンピュータ名
とか，
 > nbtstat -n
で確認できる。

マシン停止時には，ローカルサブネットへのIPブロードキャストパケットで，エントリが無効になったことを通知する。これにより，各マシンは，キャッシュしているNetBIOS名を削除する。~

NetBIOS名キャッシュの登録状態を調べるのは，
 > nbtstat -c
で確認できる。なおキャッシュの有効時間は600秒。

なんらかの問題があってNetBIOS名キャッシュをクリヤーしたい場合は，
 > nbtstat -R
でキャッシュを削除出来る。

**Common Internet File System [#f39226e9]
Windows NT4.0以上，Windows 98以降の場合は，ファイル共有などを行う際に\\x.x.x.x\共有名のように，通信先のコンピュータ名の代わりにIPアドレスを直接指定することも可能になっている。これもMicrosoft流の拡張機能なわけだが，パケットを受け取ったマシン側は，自分が登録してあるNBT情報を参照してコンピュータ名を指定して通信する仕組み。ただ，この時にはNetBIOS名の識別子情報を送れないので，識別子0x20のファイル，プリンタ共有サービスのみ使える仕様になっている。（紛らわしいなぁ）

**サブネットを超えた通信 [#ncc0e436]

***LMHOSTS [#o3cf5e62]
同じセグメントのネットワークの場合は，NBTでもNetBEUIも基本的に同様の方式で通信を行なっている。単にNBTでは下位層がTCP/IP 通信を使う為，論理ネットワークを越えた通信が可能である。~
しかし，他のセグメントのネットワークに存在マシンに対しては，名前でのブロードキャスト通信を行うことが出来ないため，何らかの方法で相手の名前解決する必要がある。（通信する相手のIPアドレスを調べる。）　解決策として考え出されたのが，''LMHOSTS''ファイルである。~
元々は，''LMHOSTS''はTCP/IPでのhostsファイルとほぼ同様に，コンピュータ名とIPアドレスを対応づけるだけの役割しかなかったが，Windows NT3.1でNTドメインが実装された時に，''LMHOSTS''も明示的にNetBIOS名を扱えるように拡張された。~

LMHOSTSの拡張
|文法|意味|h
|x.x.x.x コンピュータ名 #PRE|NetBIOSキャッシュに強制的に登録する|
|x.x.x.x コンピュータ名 #DOM:ドメイン名|x.x.x.xのIPアドレスをドメイン名<1C>のインターネットグループに登録する|
|x.x.x.x コンピュータ名 #MH|登録されたコンピュータ名のマシンは，複数のNICを持っているとみなす|
普通は，#以降はコメントとして扱われるのが普通だが，過去のLAN Managerとの互換性を持たすためにこのような仕様になっている。((それにしてもいびつな仕様ですよ，Microsoft))

LMHOSTSを置く場所は，通常は，「C:\Windows\System32\Drivers\etc」のようである。~
LMHOSTSで，＃PREを使って登録した名前は，
 > netstat -c
で調べると，Lifeが-1になっていて静的に登録されていることが解る。~

LMHOSTSを見に行くタイミングだが，最初にローカルサブネットにブロードキャストを行った後に名前解決できなかった場合に参照される。おそらく，当時はサブネット越えの通信を行うのはあまりない状況だったと思わる。
 
LMHOSTSでサブネットを超えた名前解決をする場合，各マシンごとにLMHOSTSを用意しなければならないため，小規模ネットワークでの対応になる。ただWINS拡張を使っていて何らかの理由により名前解決に時間がかかるようなときに，LMHOSTSを使うとすこし速くアクセスできるようにすることが出来ます。

注意することとして，LMHOSTSを使用している場合，相手の名前(NetBIOS名)をちゃんと正しく指定しておかないと，TCP/IPでは問題なく相手のマシンにパケットが届いているにもかかわらず，NetBIOSレベルでは通信が上手くいかないということが起こる。~
NBTとは，NetBIOSインタフェースを実装するためにデータリンク層以下のNetBEUIの部分を無理やりTCP/IP上にカプセル化して実装したものなので，せっかくTCP/IPの機能を使ってユニキャストで送付したパケットについても，宛先のホストは自分の登録したNetBIOS 名と一致するかどうかを確認するという2度手間をしているからこのようなことが起こります。 

***WINS拡張 [#y2d4ad33]
LMHOSTSで，何とかサブネットを越えるNetBIOS通信が可能になったわけだが，マシンごとにLMHOSTSを用意するなど管理が面倒なのに加え，名前の登録などはあいかわらずブロードキャストに頼っていたりして，あまり効率的ではない。~
これらをさらに解決するために考え出されたのが，Windows NT3.5で実装したWINSである。WINSの仕様はNBNS(NetBIOS Name Service)として，RFC1001，RFC1002で規定されているNBT仕様に含まれているようだ。Linuxで普及しているSambaは，この規程を元にWINSサーバーを実装しているみたい。~
これで，さらにMicrosoftのネットワーク仕様は，複雑になってしまった。

WINSでは，名前解決にブロードキャストではなく，直接プライマリWINSサーバに対して名前の登録を行なっている。~
うまくWINSサーバーに接続できている場合は，登録した名前の有効期限（TTL）があるんで，マシン側は時々更新を行う必要がある。~
マシン停止時には，前もってWINSサーバーに対して名前の開放をリクエストする。ようするにブロードキャストは使わない為，ネットワーク効率が高くなると思う。

もしWINSサーバに接続できない場合は，レジストリで設定された時間の1/8の時間毎にWINSサーバへの接続を試み，4回試みても接続できない場合(つまり設定された時間の半分を過ぎても接続できない場合)は，通信先のWINSサーバを切り替えて，4回同様の登録の試みるという動作を繰り返します。このレジストリのデフォルトの値は16分のため，以下のような動作を行うことになる。
+クライアントがWINSサーバに接続
+プライマリWINSサーバに接続するが動いていないので接続できない。
+セカンダリWINSサーバに接続するが動いていないので接続できない。
+セカンダリWINSサーバに2分毎に8分間接続を試みるが失敗。
+プライマリWINSサーバに2分後とに8分間接続を試みるが失敗。
+4，5を繰り返す。  

問題は，WINSを使っているマシンと使っていないマシンが混在した場合である。WINSに登録したコンピュータ名と同じ名前をWINSを使わないマシンが使った場合，通信が正常には行えないようになってしまう。（WINSプロキシを使うという技もあるが，レジストリをいじる必要があるんで実質使えない。）~
このようなことから，WINSサーバーを作った場合は，そのネットワークを使うマシンはWINSを使うようにすべきである。

**名前解決の順序とキャッシュ [#vc7037d2]
#ref(名前解決.png)

|ノードタイプ|意味|内容|h
|B|Broadcastノード|ブロードキャストのみを用いて名前を解決。普通ルーターはブロードキャストをフォワードしないので，ローカルネットワーク上のNetBIOS名だけしか変換できない。|
|P|Point-to-Pointノード|NetBIOSネームサーバ(WINS)のみを用いて名前を解決。Pノードはブロードキャストを使わない。&br;ネームサーバーが止まってしまったときは，ローカルのネットワークであっても通信できなくなってしまう。|
|M|Mixed modeノード|Bノード -> Pノードの順に名前を解決|
|H|Hybrid modeノード|Pノード -> Bノードの順に名前を解決|
LAN Manager時代に，Bノード失敗後にLMHOSTSファイルを参照する実装を「拡張Bノード」と称していたんだけど，現在は，上記4つすべてのノードにおいて名前解決に失敗した場合，LMHOSTSを参照するように変更されている。 

どのノードでも，最初にNetBIOS名キャッシュ，最後にLMHOSTファイルを参照する。Windowsのネットワークでは，BノードとHノードがよく使用される。~
デフォルトでは，WINSを使用するように設定されているコンピュータでは，''Hノード''が，それ以外では''Bノード''が採用される。

自分のPCのノードタイプを調べるには，コマンドプロンプトからipconfig /allを使用する。
 D:\home\ueno>ipconfig /all
 
 Windows IP Configuration
 
         Host Name . . . . . . . . . . . . : y7
         Primary Dns Suffix  . . . . . . . : yueno.homeip.net
         Node Type . . . . . . . . . . . . : Hybrid
         IP Routing Enabled. . . . . . . . : No
         WINS Proxy Enabled. . . . . . . . : No
         DNS Suffix Search List. . . . . . : yueno.homeip.net
                                             yueno.homeip.net
      :
      :
この例では，Node TypeがHybridになっているので，最初はPノード（WINS）で名前解決しようとし，解決できなかった場合はブロードキャストを使用することになる。

DHCPを使用している場合には，どのノードタイプを使用するかをDHCPサーバー側から指定することができる。DHCPを使用していない場合でも，レジストリを変更することによりノードタイプを自由に設定することが可能である。
 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetBT\Parameters
 NodeType
 値の種類 : REG_DWORD - 数値
 有効な範囲 : 1，2，4，8（Bノード，Pノード，Mノード，Hノード）

**LLMR [#v6011313]
これまでは，NetBIOSでの名前解決を説明してきたが，インターネットワーキング技術を用いたWinsock（Windows Socket）と関係があるので，その部分について確認してみる。

どうもMSでは，DNSやWINSでの名前解決方法として，LLMR（Link-local Multicast Name Resolution）をWindows Vista以降に搭載しているようだ。 LLMRは，IPv6とIPv4ホストの両方が，DNSサーバーまたはDNS クライアントの構成を必要とせずに，近隣のコンピュータの名前解決をすることが出来るシステム。 Vistaでは，LLMNRメッセージはDNSメッセージとは異なるポートのUDPポート5355を使っているようだ。Note

IPv6の場合は，クエリを行っているホスト (リクエスタ) はLLMNR名前クエリ要求メッセージをFF02::1:3のリンクローカルスコープIPv6マルチキャストアドレスに送信する。 IPv4の場合は，クエリを行っているホストは，LLMNR名前クエリ要求メッセージを224.0.0.252のIPv4マルチキャストアドレスに送信する。 両方とも，マルチキャストアドレスがスコープされていて，マルチキャスト対応のルータがクエリメッセージを最初に送信されたサブネットを越えて転送することを防ぐようにできている。

IPv6ベースのLLMNRホストは，IPv6マルチキャストアドレスFF02::1:3をリッスンしていて，そのネットワークアダプタが宛先マルチキャストアドレス33-33-00-01-00-03を持つイーサネットフレームを，リッスンするよう指示している。 IPv4ベースのLLMNRホストは，IPv4マルチキャスト アドレス224.0.0.252をリッスンしていて，そのイーサネットネットワークアダプタに宛先マルチキャストアドレス01-00-5E-00-00-FCを持つイーサネット フレームを，リッスンするよう指示している。

注意すべきは，

 Windows Vistaでは，xxxxx.localの名前を問い合わせしようとする場合，xxxxx.localという名前をxxxxxに変換し，LLMNRを使用して単一ラベルの名前を解決しようとすること。~
.localの取り扱いは，あきらかに特別扱いしている。~
つまり，「ping yyyyyyyyyy.xxxxx.local」を実行すると，LLMNRを使い「yyyyyyyyyy.xxxxx」を問い合わせするということ。しかしここでNetBIOS名は15バイト以内という制限があるので，結果名前の問い合わせをしなくなってしまう。&oh;
利便性を提供する目的でこんな仕様にしたんだろうが，副作用が出てしまっていますね。

***DNS・LLMNR・NBTの挙動 [#def3cb9d]
名前の指定方法と，試みる名前解決方法の順番を確認。
|コマンド＼DNSサフィックス|なし|local|dom.local|
|ping host1|LLMNR>NBT|DNS>LLMNR>NBT|DNS>LLMNR>NBT|
|ping hsot1.local|DNS>LLMNR>NBT|DNS>LLMNR>NBT|DNS>LLMNR>NBT|
|ping host1.dummy|DNS>NBT|DNS>NBT|DNS>NBT|
|ping host1.dom.local|DNS>NBT|DNS>NBT|DNS>NBT|

*ブラウジング機能 [#rf7dbe1d]
ブラウジング機能とは，ネットワークに存在するWindowsネットワーク上のコンピュータの一覧のブラウズリストを作成して，クライアントからのリクエストに対してその内容を提供する機能である。~
「ネットワークコンピュータ」アイコンをクリックすると一覧表示するときに行われる。

ブラウズリストは，マスタ(バックアップ)ブラウザと呼ばれるマシンが保持して，クライアントマシンは，ブラウザに対して自分の存在を示す情報を登録/更新する。Windows NT/2000以降では「Computer Browserサービス」，Windows 9x/Meでは「Microsoftネットワーク共有サービス」と呼ばれている。~

一覧のコンピューター名をダブルクリックして表示される共有リソースは，ブラウジング機能とは関係なく，提供するサーバーと通信して得られたリソース情報を表示している。

使ってみると機能的にはネットワーク上にいるマシンをリストアップして表示するだけのことだが，実際には非常に複雑な手順を使って実現しており，しばしば動作がおかしくなることも珍しくはない。 
 
**ブラウジングとマスターブラウザ [#p6794b8e]
物理セグメントが1つしかない場合のブラウジング機能を考えてみる。まず最初にネットワークで接続されたマシンが電源ONされると，
+ワークグループ名にブロードキャスト通信を開始して，他に起動しているマシンを確認する。（NBTの場合，UDP/137）
+なければ，自分がマスターブラウザになる。
+次に電源ONされたマシンがあれば，すでにネットワーク上にはマスターブラウザがいるので，自分の情報をマスタブラウザに登録する。
+もしマスターブラウザが電源OFFされた場合，自分が居なくなることを他のマシンに通知して，別のマスターブラウザを選出出来るようにする。
+この時，どのマシンがマスターブラウザになるかは，優先順位の決め事がある。

同一のネットワーク上に所属するワークグループのマスターブラウザが存在しない場合は，ブラウズリストは取得出来ないことになる。~
登録した情報は，12分ごとに更新される。（Windows95/98/Meの場合はいい加減な時間で更新。）

**ブラウザマシンの種類 [#fbd83196]
|名前|説明|
|ドメインマスタブラウザ|特殊な役割を持ったマスタブラウザである(ローカル)マスタブラウザ, セグメントのブラウズリストのマスタを保持して，クライアントにブラウズリストを提供するマシン|
|バックアップブラウザ|セグメントのブラウズリストの複製を保持し，クライアントにブラウズリストを提供するマシン|
|ポテンシャルブラウザ|ブラウザになる能力はあるが，現在はブラウザでないマシン|
|ノンブラウザ|ブラウザになれないマシン|
Windowsマシンの場合は，レジストリによって変更することが可能で，
Windows 95/98の場合は，
 HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\Vnetsetup 
Windows NT/2000の場合は，
 HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Browser\ParametersのMaintainServerListを0
にすると，マシンが非ブラウザになる。 
Sambaの場合は，
 local master = no
で非ブラウザ動作となる。
またドメインマスタブラウザになれるのは，Windowsの場合はPDCだけであるが，Sambaでは，domain master = yesと設定すると，ドメインマスタブラウザになることが出来る。

**単一セグメント内に複数のワークグループがある場合 [#rc229dce]
マスタブラウザは，各ワークグループ毎に存在する。~
各ワークグループのマスターブラウザーは，自分のグループのリストと他のグループのマスターブラウザを保持している。クライアントにはそれを返すが，受け取ったクライアントはそれから他のワークグループのマスターブラウザーが分かるので，そのマスターブラウザーに直接通信をして，ブラウズリストを取得する。~

また注意することとして，コンピュータ名は開放されるが，ワークグループ名は解放されないことです。これはおそらく，電源OFFされていった時に最後のマシンがOFF時に自分が最後ということを知る手段がないためと思われる。

**複数セグメントに複数のワークグループがある場合 [#g64ba88e]
DMB（ドメインマスタブラウザ）が存在すれば，別セグメントにいるLMB（ローカルマスタブラウザ）とブラウザ情報をやり取りしてブラウザリストを統合できる。また結果的には，クライアントマシンがブラウズリストを取得する事ができるはず。~
Windowsマシンだけのネットワークだと，DMBになれるのはドメインのPDCしかなれないこともあってNTドメイン構成が必要になるわけだが，sambaだとNTドメイン構成でなくともDMBになることが可能なため。かならずしもNTドメインを構築する必要はない。~
紛らわしいが，NTドメインとDMB（ドメインマスタブラウザ）のドメインとは意味が全く違うことになる。~

複数セグメントでは，WINSもしくはLMHOSTSでの名前解決は必ず必要である。セグメントを超えたブロードキャストは出来ないことが理由です。

*このファイルサーバーでの問題 [#q603b13b]

**ブラウジング出来ない [#z5ff047d]
このファイルサーバーはLANカードが2枚刺さっているが，TCP/IPでのパケットは相互には通信できない。（IPマスカレードを使って単方向は可能になっている。）~
また，各々のネットワークに繋がっているマシンからは，Sambaの共有リソースにアクセスはできる。しかしLMBをこのサーバーにやらせると，ネットワーク全体のブラウジング速度が遅くなってしまう症状が出たんで，LMBにしないようにしている。しかしこの設定にすると，測定マシンが接続されるネットワーク側でブラウジングが出来なくなってしまう。（他のネットワークにはマスタブラウザが存在するんで大丈夫。）~

**ブラウジング出来るようにするには [#w82c9b73]
ブラウジングされるようにするには，接続するWindowsマシンにLMBになってもらう必要がある。WindowsNT系なら「ComputerBrowserサービス」を，Windows9x/Meなら「Microsoft ネットワーク共有サービス」をインストールして，また参加するワークグループをこのサーバーと同じ「XXXXX」にします。~
~こうすると接続されたWindowsマシンがLMBになります。これでそのセグメントに接続されたマシンがブラウジングされるようになります。接続するマシンは，ワークグループ名をサーバー設定と同じ「XXXXX」にして下さい。~
~ただし，この場合でもセグメントを超えたブラウジングは出来ません。セグメントを超えたブラウジングを可能にするためには，各セグメントにDMBがいなければなりません。Windowsネットワークをワークグループ構成の場合はDMBが存在しないので，結果セグメントを越えるブラウジングは出来ないことになります。
« Prev