連載
|
|
|
段階ごとに利用するコマンドが異なる理由
上の例で見たように、エクスプローラを利用すれば「ドメイン」→「コンピュータ」→「リソース(フォルダ)」というふうに、シームレスにアクセスすることができる。だがコマンド・プロンプト上でネットワーク・リソースを利用するためには、その段階に応じて「net view /domain:<ドメイン名>」「net view \\<サーバ名>」「dir \\<サーバ名>\<フォルダ名>」という3種類のコマンドを使い分けなければならない。「net view」で公開リソース(フォルダ)の内容を表示させることはできないし、逆に「dir」でサーバの持つ公開リソース名の一覧を表示させることもできないからだ。
このように、コマンドを区別して利用しなければならない理由は、実はWindowsネットワークの内部アーキテクチャに深く関係している。エクスプローラではシームレスに見えたそのアクセスは、実際には各段階で利用されるプロトコルなどが異なっているからだ。
最初にドメイン名を元にして、そこに属するコンピュータ名の一覧を表示させているが、ここで利用されているのは、「ブラウザ」と呼ばれるコンピュータとの通信である。ブラウザは、あるドメインやワークグループに属するコンピュータ名の一覧(「ブラウズ・リスト」という)を保持し、クライアントからの問い合わせに応じてそのリストを返す役割を担当している。一般的にはこの機能はドメイン・コントローラが担当するが、ワークグループ・ネットワークではドメイン・コントローラが存在しないため、別のコンピュータが担当する。ブラウズの機能や詳細については今後、回を改めて解説するので、ここでは詳しく触れない。ここでは、リソースを公開しているサーバとは別に、ブラウズ・リストを管理するコンピュータが存在しているということを理解しておいてほしい。Windowsネットワークでよく起こるトラブルに「コンピュータ名の一覧が見えるのに、ファイル・サーバにアクセスできない」や「サーバを直接指定するとアクセスできるが、一覧が表示されない」というものがあるが、それはこのような仕組みによっている。
ブラウズ・リストと公開リソース |
ドメインやワークグループに属するコンピュータの一覧(ブラウズ・リスト)は「ブラウザ」というコンピュータが保持している。これはリソースを公開しているサーバとは別のコンピュータになる可能性があるため(同じコンピュータの場合もある)、コンピュータ名の一覧が見えることと、サーバのリソースがアクセスできることは必ずしも一致しない。一覧が見えてもサーバにアクセスできなかったり、その逆が起こったりする。 |
このブラウザとの通信に使われるのが「net view /domain:<ドメイン名>」というコマンドである。このコマンドを実行すると、現在のネットワーク上でアクティブなブラウザを検索して接続し、コンピュータ名の一覧を返すように要求している。
ネットワーク・アクセスの第2段階では「net view \\<サーバ名>」というコマンドを実行しているが、内部的には、指定された<サーバ>へ接続してから、そのサーバの持つリソースの一覧リストを取得している。この場合、アクセス権が設定されていれば(通常は設定されているはずである)、ユーザー名とパスワードを渡して、そのサーバに対するアクセスの許可を得る。いったんアクセスが許可されれば、そのコンピュータに対する接続では、以後同じユーザー名とパスワードを利用してアクセスする。
ネットワーク・アクセスの第3段階では「dir \\<サーバ名>\<フォルダ名>」というふうに、dirコマンドを利用してフォルダやファイルへアクセスしている。「dir」はもともとローカルのファイルやフォルダへアクセスするときに利用されるコマンドであり、ネットワーク・アクセス専用というわけではない。これに対して「net view」や後述する「net use」などのコマンドは、ネットワーク機能を利用、管理するための専用コマンドであり、MS-Networksのために、(MS-DOSに)追加されたコマンド群である。
ではなぜdirコマンドでネットワーク・ファイルへアクセスできるのかというと、ネットワーク・ファイルがローカル・ファイルと同等に見えるようにOSが作られているから、というのがその理由である。
もしローカルのファイルとネットワークのファイルで異なるコマンド体系やAPIを利用しなければならないとすると、そのシステムは非常に使いにくいものになるだろう。アプリケーションを作るのも面倒だし、ユーザーもアクセスするファイルの置き場所に応じてコマンドを使い分けなければならない。このような不便をなくすため、ネットワーク・ファイルであってもローカル・ファイルと同等に利用できるようにOSが作られている。例えば「C:\USER\YAMADA\TEST.TXT」ならばローカルのディスク上のファイルへアクセスし、「\\WINSERVER-01\USER\YAMADA\TEST.TXT」ならばネットワーク上のファイル・サーバへアクセスを依頼する。パス名の先頭部分が若干異なるが、どちらも同じような形式のファイル名として扱われている。先頭部分を解析して、「\\<サーバ名>」となっていればリモートのサーバへ要求を振り向ければよいだろう。このように、アクセスする先に応じて適切なファイル・システム・ドライバやリモート・コンピュータへと要求を振り分けるメカニズムを、Windows OSでは「リダイレクタ(redirector)」と呼ぶ。詳細については、連載第2回の「Windowsネットワークのレイヤ・モデルとファイル共有―2.共有ファイルのアクセスを追跡してみる」を参照していただきたい。
これで分かるとおり、いったん「net view \\<サーバ名>」というコマンドを実行してファイル・サーバとの接続が確立してしまえば、あとはローカルのファイルをアクセスするのと同じである。よってネットワーク・アクセスの第3段階ではdirというコマンドが利用できるようになっているし、ネットワーク・アクセス用の特別なコマンドを使う必要もない。
これに対してエクスプローラでは、一見するとシームレスにアクセスしているように見えるが、内部ではこれら3種類のコマンドをそのコンテキストに応じて自動的に使い分けている。だから何らかのトラブル(ドメインやサーバ名、リソース名の一覧が表示されない、リソースへのアクセスが拒否されるなど)が生じた場合は、どの段階でエラーが起こっているのかをよく見極め、トラブルに対処する必要がある。そのためには、それぞれのnet viewやdirコマンドの機能をよく理解し、段階的に試行して、どの段階でどのようなエラーが生じているかを把握する必要がある。
UNC表記について
Windows OSでは、ローカルのファイルとリモートの(ネットワーク上の)ファイルを統一的に扱えるように、「UNC(Universal Naming Convention)」という、汎用的な名前付け規則を使っている。例えば「C:\TEST.TXT」ならばローカルのディスク(C:ドライブ)上にあるファイルを指すが、「\\WINSERVER-01\USER\YAMADA\TEST.TXT」ならばネットワーク上のファイル・サーバに置かれたファイルを指す。
このUNC表記は、ファイル名を指定するところなら、たいていの場所で利用できるので、覚えておくとよいだろう。例えばファイルの保存ダイアログにおいて、ファイル名の前に直接UNCでパスを記述し、サーバ上のフォルダへ直接保存させることができる。また、フォルダの場所をいちいちUNCで指定するのが面倒な場合や、[マイ ネットワーク]−[ネットワーク全体]−[Microsoft Windows Network]−……を順番にたどるのが面倒な場合は、ローカルのドライブにマップ(割り当て)しておくのもよいだろう。例えば\\WINSERVER-01\USERをX:ドライブにマップしておくと、X:\YAMADA\TEST.TXTのように、短い名前で表現することができる。ドライブにマップするには、エクスプローラでサーバ中のフォルダ名を右クリックして、ポップアップ・メニューか[ネットワーク ドライブの割り当て]を実行する。もしくは「net use x: \\winserver-01\user」というコマンドを利用すればよい。詳しくはWindows TIPS「アカウントを指定してIPC$共有リソースへ接続する」を参照していただきたい。
UNC中におけるサーバの指定方法
Windows 9xといった古いWindows OSの仕様では、UNC中におけるサーバ名は、NetBIOS名(最大15文字)で指定する必要があった。だが現在のCIFSが利用できるWindows OSではこの制限が緩和され、NetBIOS名だけでなく、IPアドレス表記やFQDN名で指定することも可能になっている。例えば「\\192.168.10.12\user」や「\\winserver.example.co.jp\user」といった表記が利用できる。NetBIOS名で表現できない場合は、CIFSのみが利用されることになっている。このような拡張された表記を利用することにより、例えばActive Directory環境やTCP/IPネットワークとの親和性が高くなっている。Active Directory環境では各コンピュータは長い名前やDNSドメイン名を持つが、無理に短い名前を付けたり、NetBIOSをルーティングしたり、NetBIOS名の名前解決をさせるために面倒でトラブルの元となりやすいネットワーク設定を行ったりしなくても済むからだ。
ファイル・サーバとのセッション・セットアップ
以上の例では、net viewコマンドのあと、すぐにdirコマンドを使ってファイル・サーバへアクセスしていた。だがサーバ側の共有アクセス権の設定によっては、net viewコマンドの実行が失敗する(アクセス拒否される)ことがある。
C:\>net view \\winserver-01 …公開リソースの一覧の表示 |
このエラーが発生する最も多い原因は、サーバ(ここではwinserver-01)へアクセスする場合のアクセス権がない、というものである。net viewコマンドで特定のサーバのリソース一覧を取得するためには、最初にそのサーバへネットワーク・ログオンする必要がある。ログオンして初めてリソースの一覧を取得できるのである。
この例のように単にnet viewコマンドを実行すると、ユーザーが現在ログオンしているときに使ったユーザー名とパスワードを使って、リモートのサーバへ接続しようとする。例えばクライアント・コンピュータへ「ユーザー名:suzuki」、「パスワード:password123」でログオンしているとすると、リモートのサーバへ接続するときにはこのユーザー名とパスワードの組を使ってネットワーク・ログオンしようとする。もしこのアカウント(ユーザー名)とパスワードの組がサーバ側に登録されていれば、ログオンは成功し、net viewコマンドの実行は成功する。だがログオンに失敗すると、net viewコマンドは以上のようにエラーとなる。もし同じアカウントがサーバ側に登録されていないのならば、別の有効なアカウントを指定しなければならない。
ファイル・サーバと最初に接続し、リソースの利用開始処理を行うことを「セッション・セットアップ」というが、net viewコマンドでは、セットアップに使用するアカウントを明示的に指定することはできない。これを行うには、まずnet useコマンドを使って、IPC$リソースへの接続を明示的に行えばよい。IPC$リソースとは、ネットワーク・ログオンの一番最初の段階で利用されるリソースの名前である。IPC$リソースへの接続が成功するとファイル・サーバとクライアント間で「セッション(通信路)」が確立され、一覧の取得やファイル入出力などといったファイル操作を行うことができる。このセッションが確立しない限り、サーバのリソースを利用することはできない。実は最初に「net view \\<サーバ名>」を実行したとき、内部ではこのIPC$への接続が行われているのである。
IPC$リソースへの接続を行うには、「net use \\<サーバ名>\ipc$」というコマンドを実行すればよい。net useでは接続に使用するユーザー名とパスワードを明示的に指定できるので、これを利用する。詳しくはWindows TIPS「アカウントを指定してIPC$共有リソースへ接続する」や「共有リソース・アクセス時にパスワード入力を求められる「IPC$」とは?」などを参照していただきたいが、例えば次のようにすればよい。
C:\>net use \\winserver-01\ipc$ /user:suzuki password123 |
これを実行してから、net viewを実行すれば、すでにセッションが確立しているのでエラーにはならずに処理を進めることができる。なお、現在確立しているセッションの内容を調べるには、単に「net use」というコマンドを実行すればよい。
C:\>net use …接続済みセッションの一覧の表示(クライアント側) |
これはクライアント側での確認方法であるが、サーバ側で現在確立しているセッションを確認するには、net sessionコマンドを利用する。
C:\>net session …接続済みセッションの一覧の表示(サーバ側) |
セッション情報ではなく、現在オープンされているファイルの情報を知りたい場合は、net fileコマンドを利用すればよい。ただしこれはサーバ上でのみ実行可能なコマンドであり、現在利用されているファイルをクライアント側で知る方法は用意されていない。
C:\>net file |
net fileコマンドの使い方については、Windows TIPS「共有ファイルを現在使用しているユーザーを特定する方法」も参照していただきたい。
なお、現在どのユーザー・アカウントでコンピュータにログオンしているかを調べるには、「net config workstation」もしくは「net config redirector」コマンドが利用できる(いずれでも同じ)。これは「Workstaion サービス」に関する現在の状態を表示させるコマンドである。
C:\>net config workstation |
これに対応する、Serverサービス側の状態を表示するコマンドは「net config server」である。
C:\>net config server |
いずれの出力にもある「アクティブなネットワーク」というインターフェイス名は、現在利用できるトランスポート層プロトコルを表している。「NetbiosSmb」は、CIFSで用いられる、TCPの445番を経由するインターフェイス、「NetBT_Tcpip …」はNBT(NetBIOS over TCP/IP)インターフェイスをそれぞれ表している。もしNetBEUIプロトコルも導入していると、「Nbf_ …」という名前も表示されるはずである。サーバ側とクライアント側の双方に、同じ種類のインターフェイスがないと通信することができない。
■
次回は、SMB/CIFSプロトコルの詳細なパケット構造の定義とその動作について解説する。
INDEX | ||
[連載]基礎から学ぶWindowsネットワーク | ||
第20回 ファイル共有プロトコルSMB/CIFS(その1) | ||
1.Windowsネットワークの基本アーキテクチャ | ||
2.Windowsネットワークの基本的な使い方(1) | ||
3.Windowsネットワークの基本的な使い方(2) | ||
連載 |
- Windows TIPS (2008/1/18)
− Adobe ReaderのMSIインストール・ファイルを入手する
− メールを暗号化するPOP3s/IMAP4s/SMTPsとは
− タスク・バーのボタンの幅を調整する - 緊急レベルを含む2件のセキュリティ修正が公開 (2008/1/16)
1月のセキュリティ修正は計2件。WindowsのTCP/IP処理に緊急レベルの危険な脆弱性が明らかに。そのほかWindows XP SP3 RCも登場 - 第107話 シャープな人々 (2008/1/15)
先輩、先輩の時計、進んでません? ああほら、1分も進んじゃってる。電波時計じゃないんですか。これならほら、秒までぴったりですよ - Windows TIPS (2008/1/11)
− Wordをセーフ・モードで起動する
− Adobe Readerのバージョンをリモートから確認する
− Active Directory移行ツールでドメイン情報を移行する
|
|
スポンサーからのお知らせ
- - PR -
お勧め求人情報
**先週の人気講座ランキング**
〜プロジェクトマネジメント編〜
◆ | New! 「わしは知らんかった」では済まされない 記録保管として電子メールが持つ意義とは |
◆ | New! データマイニングを武器に、C型肝炎 ウイルスと戦う医師。その治療の行方は? |
◆ | New! とにかく人が足りない「組み込み開発業界」 今こそ、キャリアチェンジのチャンス! |
◆ | ■ボトルネックバスターズ 2■ 連載 第3話 原因究明成功!だが、果たして改善方法は? |
◆ | 納得の開発環境「MyEclipse」で構築する Amazon Webサービスを利用したECサイト! |
◆ | “予防”と“発見”で強化する内部統制 ――@IT主催内部統制セミナー詳細 |
◆ | 「番次郎さん、WSSが使えそうです!」 “いぶき”がついに、難題突破口を発見! |
◆ | ORACLE MASTER取得者へ林優子氏が指南! 「次に身に付けるべきスキルとは……」 |
◆ | フロントシステムの4つの課題を解決! 企業システムでAjaxが実用化段階に |
◆ | サン&オラクル推奨のデータベース環境。 驚きのパフォーマンス性能に迫る! |
◆ |
2008年:これが成功するITエンジニア像だ! 〜エンジニア・キャリア進化論(第2回)〜 |
◆ | オープンソースのアプリケーションサーバ GlassFishのレシピを紹介します! |
◆ | 「地方のエンジニアも幸せにしたい」 その思いがニアショア開発へとつながった |
◆ | 「学ぶ」だけで「経験」が身に付く? ITエンジニアの私が大学に入学した理由 |
◆ | ■ メール管理者の悩みを軽減する! ■ 情報漏えい、スパム対策の最新アプローチ |
◆ | フリーエンジニアのための社会保険入門 万が一の時、リスクにどう備えるべきか? |
◆ | 障害の発生前に事前通知!!復旧時間を 早める切札で、サーバ管理がラクになる! |