資料室PC / ネットワーク関連 / Windowsネットワーク

Microsoft ネットワーク anchor.png

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

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

Page Top

NetBEUIとNBT anchor.png

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

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

Page Top

NBTとLMHOSTS anchor.png

NBTはTCP/IPを使うのでセグメントを超えた通信が可能である。ただNetBIOSは内部的には名前で通信するので,セグメントを超えたブロードキャストが出来ないため,何らかの方法で名前の解決をする必要がある。そこで考えられたのがLMHOSTSファイルでの名前解決である。(NTドメインの頃に拡張された)

文法意味
x.x.x.x コンピュータ名 #PRENetBIOSキャッシュに強制的に登録する
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つの宛先があるということで,通信をするときに両方をチェックする必要があるから。

Page Top

コンピュータ名とホスト名 anchor.png

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

Page Top

NetBIOS名 anchor.png

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

XXXXXYYYYY<00>

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

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

種別内容
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台のマシンしか登録できない名前だが,グループ名は複数のマシンが登録することができる。グループ名を宛先に指定された通信フレームは,そのグループ名を登録した全てのマシンが受信することができる。つまり一種のマルチキャストのような事が出来るということ。

Page Top

NBTでの名前の登録と解決 anchor.png

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

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

> nbtstat -a コンピュータ名

とか,

> nbtstat -n

で確認できる。

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

NetBIOS名キャッシュの登録状態を調べるのは,

> nbtstat -c

で確認できる。なおキャッシュの有効時間は600秒。

なんらかの問題があってNetBIOS名キャッシュをクリヤーしたい場合は,

> nbtstat -R

でキャッシュを削除出来る。

Page Top

Common Internet File System anchor.png

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

Page Top

サブネットを超えた通信 anchor.png

Page Top

LMHOSTS anchor.png

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

LMHOSTSの拡張

文法意味
x.x.x.x コンピュータ名 #PRENetBIOSキャッシュに強制的に登録する
x.x.x.x コンピュータ名 #DOM:ドメイン名x.x.x.xのIPアドレスをドメイン名<1C>のインターネットグループに登録する
x.x.x.x コンピュータ名 #MH登録されたコンピュータ名のマシンは,複数のNICを持っているとみなす

普通は,#以降はコメントとして扱われるのが普通だが,過去のLAN Managerとの互換性を持たすためにこのような仕様になっている。*2

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度手間をしているからこのようなことが起こります。

Page Top

WINS拡張 anchor.png

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分のため,以下のような動作を行うことになる。

  1. クライアントがWINSサーバに接続
  2. プライマリWINSサーバに接続するが動いていないので接続できない。
  3. セカンダリWINSサーバに接続するが動いていないので接続できない。
  4. セカンダリWINSサーバに2分毎に8分間接続を試みるが失敗。
  5. プライマリWINSサーバに2分後とに8分間接続を試みるが失敗。
  6. 4,5を繰り返す。

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

Page Top

名前解決の順序とキャッシュ anchor.png

名前解決.png
ノードタイプ意味内容
BBroadcastノードブロードキャストのみを用いて名前を解決。普通ルーターはブロードキャストをフォワードしないので,ローカルネットワーク上のNetBIOS名だけしか変換できない。
PPoint-to-PointノードNetBIOSネームサーバ(WINS)のみを用いて名前を解決。Pノードはブロードキャストを使わない。
ネームサーバーが止まってしまったときは,ローカルのネットワークであっても通信できなくなってしまう。
MMixed modeノードBノード -> Pノードの順に名前を解決
HHybrid 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ノード)
Page Top

LLMR anchor.png

これまでは,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] 利便性を提供する目的でこんな仕様にしたんだろうが,副作用が出てしまっていますね。

Page Top

DNS・LLMNR・NBTの挙動 anchor.png

名前の指定方法と,試みる名前解決方法の順番を確認。

コマンド\DNSサフィックスなしlocaldom.local
ping host1LLMNR>NBTDNS>LLMNR>NBTDNS>LLMNR>NBT
ping hsot1.localDNS>LLMNR>NBTDNS>LLMNR>NBTDNS>LLMNR>NBT
ping host1.dummyDNS>NBTDNS>NBTDNS>NBT
ping host1.dom.localDNS>NBTDNS>NBTDNS>NBT
Page Top

ブラウジング機能 anchor.png

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

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

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

使ってみると機能的にはネットワーク上にいるマシンをリストアップして表示するだけのことだが,実際には非常に複雑な手順を使って実現しており,しばしば動作がおかしくなることも珍しくはない。

Page Top

ブラウジングとマスターブラウザ anchor.png

物理セグメントが1つしかない場合のブラウジング機能を考えてみる。まず最初にネットワークで接続されたマシンが電源ONされると,

  1. ワークグループ名にブロードキャスト通信を開始して,他に起動しているマシンを確認する。(NBTの場合,UDP/137)
  2. なければ,自分がマスターブラウザになる。
  3. 次に電源ONされたマシンがあれば,すでにネットワーク上にはマスターブラウザがいるので,自分の情報をマスタブラウザに登録する。
  4. もしマスターブラウザが電源OFFされた場合,自分が居なくなることを他のマシンに通知して,別のマスターブラウザを選出出来るようにする。
  5. この時,どのマシンがマスターブラウザになるかは,優先順位の決め事がある。

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

Page Top

ブラウザマシンの種類 anchor.png

名前説明
ドメインマスタブラウザ特殊な役割を持ったマスタブラウザである(ローカル)マスタブラウザ, セグメントのブラウズリストのマスタを保持して,クライアントにブラウズリストを提供するマシン
バックアップブラウザセグメントのブラウズリストの複製を保持し,クライアントにブラウズリストを提供するマシン
ポテンシャルブラウザブラウザになる能力はあるが,現在はブラウザでないマシン
ノンブラウザブラウザになれないマシン

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と設定すると,ドメインマスタブラウザになることが出来る。

Page Top

単一セグメント内に複数のワークグループがある場合 anchor.png

マスタブラウザは,各ワークグループ毎に存在する。
各ワークグループのマスターブラウザーは,自分のグループのリストと他のグループのマスターブラウザを保持している。クライアントにはそれを返すが,受け取ったクライアントはそれから他のワークグループのマスターブラウザーが分かるので,そのマスターブラウザーに直接通信をして,ブラウズリストを取得する。

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

Page Top

複数セグメントに複数のワークグループがある場合 anchor.png

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

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

Page Top

このファイルサーバーでの問題 anchor.png

Page Top

ブラウジング出来ない anchor.png

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

Page Top

ブラウジング出来るようにするには anchor.png

ブラウジングされるようにするには,接続するWindowsマシンにLMBになってもらう必要がある。WindowsNT系なら「ComputerBrowserサービス」を,Windows9x/Meなら「Microsoft ネットワーク共有サービス」をインストールして,また参加するワークグループをこのサーバーと同じ「XXXXX」にします。

こうすると接続されたWindowsマシンがLMBになります。これでそのセグメントに接続されたマシンがブラウジングされるようになります。接続するマシンは,ワークグループ名をサーバー設定と同じ「XXXXX」にして下さい。

ただし,この場合でもセグメントを超えたブラウジングは出来ません。セグメントを超えたブラウジングを可能にするためには,各セグメントにDMBがいなければなりません。Windowsネットワークをワークグループ構成の場合はDMBが存在しないので,結果セグメントを越えるブラウジングは出来ないことになります。


*1 これがよく起きるんだよなぁ
*2 それにしてもいびつな仕様ですよ,Microsoft

新しくコメントをつける

題名
ゲスト名
投稿本文
より詳細なコメント入力フォームへ

トップ   凍結 差分 バックアップ 複製 名前変更 リロード   ページ新規作成 全ページ一覧 単語検索 最新ページの一覧   ヘルプ   最新ページのRSS 1.0 最新ページのRSS 2.0 最新ページのRSS Atom
Counter: 1315, today: 1, yesterday: 0
最終更新: 2020-12-26 (土) 16:07:33 (JST) (1188d) by yuji