第5回 NetBIOSでルーティングを可能にするNBT：Windowsネットワークの基礎
初期のWindowsネットワークでよく使われていたNetBEUIプロトコルにはルーティング機能がないため、大規模なネットワークでは利用しづらかった。現在ではNetBIOSとTCP/IPを組み合わせたNBTが普及している。
前回は、Windowsネットワークと深い関係があるNetBIOSについて解説した。今回はNetBIOSをベースにして発達したNBTプロトコルについて見ていく。
NetBIOSでルーティングを可能にするNBTプロトコル
前回はNetBIOSについて解説したが、もともとNetBIOSは小規模な単一ネットワークセグメント向けのネットワークAPIとして開発されたため、大規模なネットワーク環境で運用するにはかなり機能が不足している。最も大きな問題点は、ネットワークパケットのルーティング機能を持っていない、ということである。
TCP/IPを使ったネットワークでは、複数のイーサネット（無線LANも含む）のセグメント（イーサネットのブロードキャストが届く範囲が1つのセグメントになる）をルーターで相互に接続することにより、大規模なネットワーク（社内ネットワークやインターネットなど）を構築している。
これに対してNetBIOSでは、基本的にはNetBIOS名をブロードキャストすることによって通信相手を認識・特定している。そのため、ブロードキャストが届かないネットワーク（ルーターによって中継されている他のネットワークセグメント）同士のノードでは、お互いに通信することができない。その結果、NetBIOSを使った通信は単一のブロードキャストセグメント内に限定されることになる。これでは大規模なネットワークは構築できない。
そこで、このような制約を避け、別のネットワークセグメント上にあるノード同士で通信させる方法として考案されたのが「NBT（NetBios over TCP/IP）」である。NetBIOSの通信パケットをTCP/IP上に実装することにより、TCP/IPの持つルーティング機能やネットワーク基盤を生かしたまま、アプリケーションレベルではNetBIOS APIをそのまま使えるようにしている。これにより、NetBIOSを利用するアプリケーションはそのままで、複数のセグメントが存在するような大規模ネットワークでも利用できるようになった。NBTプロトコルは、以下のRFCなどで標準として定義されている。
- RFC1001 -- PROTOCOL STANDARD FOR A NetBIOS SERVICE ON A TCP/UDP TRANSPORT: CONCEPTS AND METHODS［英語］（IETF）
- RFC1002 -- PROTOCOL STANDARD FOR A NetBIOS SERVICE ON A TCP/UDP TRANSPORT: DETAILED SPECIFICATIONS［英語］（IETF）
- [MS-NBTE]: NetBIOS over TCP (NBT) Extensions［英語］（MSDNサイト）
NetBIOSとNBT／NetBEUI／IPX/SPX
NetBIOSは単なるネットワーク用のAPIセットであり、実際にネットワークケーブル上でやりとりされるパケットの構造やプロトコルについては特に規定はされていなかった。使用するハードウェアに応じてイーサネットやTokenRing、HDLC（いずれもメインフレームコンピューターなどでよく使われていた通信技術）、シリアル回線など、いくつかの通信メディアがサポートされている。
その後NBTなどを導入するときに正式な仕様や下位のプロトコル（トランスポート層プロトコル）の扱いなどが整理された。図にすると次のようになる。
NetBIOSインターフェースとトランスポート層プロトコル
Windowsファイル共有サービス（SMB／CIFSプロトコル）は、他のコンピューターと通信するためにNetBIOSインターフェースを呼び出すが、NetBIOSは下位のトランスポート層プロトコルとしてNetBEUIやTCP/IP、IPX/SPX（NWLink）などを利用している。ただしNetBIOSインターフェースを利用せずに、TCP/IPを直接使うこともある（一番左側の矢印。これについては次回解説予定）。
ここではNetBIOSと共に使われる3種類のトランスポート層プロトコルについてまとめておく。
■オリジナルのNetBIOSべースのNetBEUI
NetBIOSが開発された当初に使われていたプロトコルとして「NetBEUI（NetBIOS Extended User Interface）」がある。NetBEUIは小規模な単一ネットワークセグメント向けのプロトコルだ。面倒な事前設定などが不要であり（各PCに重複しないようにIPアドレスを割り当てるといった面倒はない）、コンピューター名さえ付けておけば簡単に相互通信が可能である。DOS時代のMS-NetworksやWindows 9x、Windows NTなどでよく使われていた。
■TCP/IPをベースにしたNBT
TCP/IP上でNetBIOSを利用できるようにしたのがNBTである。TCP/IPの持つルーティング機能や名前解決機能と組み合わせることにより、ルーティングや大規模なネットワーク構成を可能にしている。
■IPX/SPXをベースにしたNBIPX
「IPX/SPX（Internetwork Packet Exchange/Sequenced Packet Exchange）」は、1980年代中頃から1990年代にかけてよく使われた、ノベルのNetWareというネットワークOSで使われていたトランスポート層プロトコルである。このIPX/SPX（もしくは、これと互換な機能を持つように、マイクロソフトによって開発された「NWLINK」）上にNetBIOSサービスを実装した「NBIPX（NetBIOS over IPX/SPX）」は、NetWareを導入していた企業でよく使われていた。
以上のように、さまざまなトランスポート層プロトコル上でNetBIOSが実装されていた。ただし実際にファイル共有サービスなどを受けるためには1つ重要な条件がある。それは、「サーバー側もクライアント側も、同じトランスポート層プロトコルを実装（利用）している必要がある」ということである。ファイルサーバー側にNBTしかインストールしておらず、クライアント側にはNetBEUIしかインストールしていないと（非常に古いWindows OSやMS-DOSシステムではNetBEUIしかインストールされていないことがある）、お互い通信することはできない。
もっとも現在ではTCP/IPが広く普及しているため、NBT以外のプロトコルが使われていることはないだろう。
ファイル共有サービスで利用されているプロトコルを確認する
ファイル共有サービスがどのプロトコルを利用しているかは、ネットワークプロトコルの「バインド（結合状態）」状態を確認すれば分かる。
ネットワークインターフェースとプロトコルのバインド（Windows XP）
ファイル共有サービスやそこへ接続するクライアントサービスにおいて、どのトランスポート層プロトコルを利用するかは、ネットワークインターフェースごとに「バインド」を設定することによって行う。これはWindows XPでIPX/SPXとNetBEUIプロトコルを追加した場合のプロトコルのバインド画面の例。コントロールパネルの「ネットワーク接続」画面で［詳細設定］メニューを開くと設定できる。
（1）ネットワークインターフェースを選択すると、これにバインドされているプロトコルが下側に表示される。
（2）このチェックボックスをオンにすると、このインターフェース上でファイル共有（公開）サービスが利用可能になる。インターフェースごとに有効／無効を設定できる。
（3）ファイル共有サービスでNetBEUIを利用したい場合はこれをオンにする。
（4）NBIPXを利用したい場合はこれをオンにする。
（5）NBTを利用したい場合はこれをオンにする。
（6）このチェックボックスをオンにすると、このインターフェース上でファイル共有のクライアント接続が有効になり、ファイルサーバーにアクセスできるようになる。
この画面の例ではNBTだけでなく、NetBEUIやIPX/SPX（NWLink）も使われている。1つのサービス（ファイル共有サービスやクライアントサービス）に複数のプロトコルがバインドされている場合は、それらを指定された優先度に基づいて順番に試し、最初に接続が確立されたプロトコルを使って通信が行われる。
現在のWindows OSではNetBEUIやNWLinkプロトコルは廃止されていて、ファイル共有サービスではNBTか（NetBIOSインターフェースを使わない）TCP/IPの直接接続でのみアクセスするようになっている。例えばWindows XPでは以下のTIPSの方法でNetBEUIプロトコルを追加できたが、現在のWindows 7やWindows 8などではTCP/IPのIPv4かIPv6へのバインドのみが制御可能である。
次の画面はWindows 8.1における同じ詳細設定画面の例である。
ネットワークインターフェースとプロトコルのバインド（Windows 8.1）
現在使われてWindows OSではNetBEUIやIPX/SPXはサポート対象外となり（手動で追加することもできない）、NBTのみが利用されている。これはWindows 8.1におけるネットワークプロトコルのバインドの例。IPv4とIPv6しかバインドできない。
（1）イーサネットのインターフェースを選択してみる。
（2）このインターフェースにバインドされているファイル共有サービス。
（3）Windows VistaやWindows Server 2008以降では、ここにTCP/IP以外のプロトコルを追加することはできない。
NetBIOSの名前解決
もともとのNetBIOSではブロードキャストでのみ名前解決を行っていたため、その動作は単純であった。通信したい相手の名前をNetBIOSでローカルのネットワーク上でブロードキャスト送信すると、その名前を持つノードが応答する、というように動作している。
だがNBTが利用されている環境では名前解決の方法が少し複雑になる。通信したい相手がローカルのネットワーク上だけでなく、ルーターで接続された別のネットワーク上にも存在するからだ。またTCP/IP環境では、通信相手はNetBIOS名ではなく、IPアドレスで指定しなければならない。そのため、NetBIOS名とIPアドレスを関連付ける何らかの仕組みやサービスを用意する必要がある。
この名前解決のためにWindows OSでは、「LMHOSTSファイル」や「WINS」というサービスを用意している。
LMHOSTSファイル
「LMHOSTS（LAN Manager hosts file）」とは、NetBIOS名とIPアドレスの対応付けを記述したテキストファイルである。UNIXやLinuxでは、/etc/hostsというテキストファイルでIPアドレスとホスト名の対応付けを行っていたが、それをNBT向けに拡張したのがLMHOSTSファイルである。Windows OSではLMHOSTSファイルを「%windir%\System32\drivers\etc」というフォルダーに保存することになっている。NBTで名前を検索させると、このファイルからNetBIOS名に対応するIPアドレスを見つけ、そのTCP/IPノードと通信が行われる。
※lmhostsファイルの例
C:\>cd C:\Windows\System32\Drivers\etc ……etcフォルダーへ移動する。UNIXやLinuxの/etcに相当するフォルダー
C:\Windows\System32\Drivers\etc>dir ……ファイルを確認する
ドライブ C のボリューム ラベルがありません。
ボリューム シリアル番号は 2631-970C です
C:\Windows\System32\Drivers\etc のディレクトリ
2013/08/22 17:17 <DIR> .
2013/08/22 17:17 <DIR> ..
2013/08/22 15:13 824 hosts ……サンプルのhostsファイル。必要なホストを自分で追加してもよい
2015/01/07 11:03 291 lmhosts ……lmhosts.samファイルをコピーして自分で作成したlmhostsファイル
2013/08/22 17:16 3,683 lmhosts.sam ……サンプルのlmhostsファイル。これを参考にlmhostsファイルを作成すること
2013/08/22 15:13 407 networks
2013/08/22 15:13 1,358 protocol ……プロトコル一覧
2013/08/22 15:13 17,463 services ……TCPやUDPのサービスポート一覧
5 個のファイル 24,026 バイト
2 個のディレクトリ 126,765,182,976 バイトの空き領域
C:\Windows\System32\Drivers\etc>type lmhosts ……内容を確認してみる
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
※この例は、元のlmhosts.samファイル中で定義されていたもの。
・lmhostsファイル中には、IPアドレスとNetBIOS名、その用途などを定義する
・固定IPアドレスを持つWindowsのサーバーOSなどを登録しておくのが一般
・「#PRE」を付けるとNetBIOSキャッシュにプリロードされ、素早く検索できる
・「#DOM」はNTドメインで使われるドメインコントローラーを指定するために使われる
WINSサーバー
LMHOSTSファイルでは、NetBIOS名とTCP/IPアドレスの「静的な」関連付けを定義しているが、一般的にTCP/IPではDHCPなどを使って動的なIPアドレス割り当てを行うのが普通である。そこでNetBIOS名とIPアドレスの関連付けを動的に管理する「NBNS（NetBIOS Name Server）」というサービスが開発された。これはコンピューター名（FQDN名）とIPアドレスの動的な管理を行うDNSサービスと同じような機能を持つ。
サーバー系のWindows OSには、このNBNSを実装したものとして「WINS（Windows Internet Name Service）」というサービスが用意されている。NBTを利用するクライアントは起動時にWINSサーバーに自分自身のNetBIOS名とIPアドレスを登録しておく。そして他のNetBIOSノードを検索する場合には、まずWINSサーバーに問い合わせを行うと、そのIPアドレスが分かるという仕組みだ。WINSサーバーのアドレスは、通常はDHCPサービスでクライアントに配布・設定する。
なおNetBIOS名には階層構造はないため、重複したNetBIOS名（コンピューター名）を付けないように注意する。1台のWINSサーバーで社内の全てのネットワーク（上のコンピューター）の名前解決を行おうとすると、同じ名前のコンピューターがあった場合に名前解決に失敗することがある。
NetBIOSの名前解決順序とNetBIOSノードタイプ
以上で述べたように、NetBIOSの名前解決には「ブロードキャスト」「LMHOSTSファイル」「WINSサーバー」という3つの方法がある。またTCP/IPにおける標準的な名前解決手段である「DNSサーバー」と「hostsファイル」も合わせると、さらに多くの方法が利用できる（実際にはこれ以外にもIPv6でのみ有効な名前解決手段もある。関連記事参照）。
これら複数の名前解決手段をどのように組み合わせて、どの順番で利用するかはシステムの構成によって変わる。Windows OSではこれを「NetBIOSノードタイプ」といい、「b（broadcast）ノード」「p（point-to-point）ノード」「m（mix）ノード」「h（hybrid）ノード」の4種類がある。具体的には次のようになっている。
NBT環境における名前解決の順序
NBTにおける名前解決の順序はノードタイプによって変わる。最初はキャッシュを検索し、見つからなければローカルでブロードキャストしたりWINSサーバーに問い合わせたりする、という順序で動作する。
（1）名前解決の結果は一定時間キャッシュしておき、その時間内ならそのキャッシュから応答を返す。これにより名前解決の高速化が図れる。
（2）ノードタイプ別にブロードキャストとWINSサーバーを使う順序などが変わる。「ブロードキャスト」はローカルのイーサネットセグメントに対するブロードキャスト、「WINSサーバー」はWINSサーバーへの問い合わせを表す。
（3）LMHOSTSファイルを参照する。
（4）HOSTSファイルを参照する。
（5）DNSサーバーに問い合わせる。これでも見つからなければ、名前解決は失敗となる。
4種類あるノードタイプのうち、どれを使うかはシステムの構成によって変わる。デフォルトは「bタイプ」か「hタイプ」だが（WINSサーバーの指定があればhタイプ、なければbタイプとなる）、DHCPなどで、IPアドレスやWINSサーバーアドレスなどと共にクライアントPCに設定することもできる。現在のノードタイプはコマンドプロンプト上で「ipconfig /all」コマンドを実行すれば確認できる。
- TIPS「Windows OSで有効なDHCPオプション」
C:\>ipconfig /all ……TCP/IPの構成情報を表示させる
Windows IP 構成
ホスト名. . . . . . . . . . .: PCWIN81UPROX1
プライマリ DNS サフィックス .:
ノード タイプ . . . . . . . .: ハイブリッド ……NetBIOSノードタイプ
IP ルーティング有効 . . . . .: いいえ
WINS プロキシ有効 . . . . . .: いいえ
DNS サフィックス検索一覧. . .: example.jp
イーサネット アダプター Ethernet0:
接続固有の DNS サフィックス . . .: example.jp
……（以下省略）……
今回はNetBIOSの下位プロトコル、特にNBTについて解説した。現在ではNBT以外のプロトコルを使うことはほとんどないだろうが、その仕組みをよく理解していないと、特に古いWindowsクライアントとの接続などで問題になることがある。次回はより上位のプロトコルであるSMBについて解説する予定である。
Copyright© Digital Advantage Corp. All Rights Reserved.