VPN越しのNetBIOS：名前・データグラム・セッションは別々のサービス
ルーターに関する決まり文句は広すぎます。アプリケーションが三つのサービスのどれを使うのか、名前をブロードキャストで解決するのかサーバーで解決するのかを確認してください。
「NetBIOSはルーターを越えない」という言葉は、設計を決着させたかのように繰り返されます。決着していません。ブロードキャストによる名前検索は通常、自分のブロードキャストドメインの内側にとどまりますが、NetBIOSのサービスは、問題なくルーティングされる指向性のあるIPトラフィックも使えます。有用な問いは、NetBIOSがルーターを越えるかどうかではなく、アプリケーションが三つのサービスのどれを使っているかです。
ソフトウェアのインターフェースであり、一本のワイヤープロトコルではない
RFC 1001は、NetBIOSをアプリケーションが向かってプログラムするインターフェースとして記述しており、その下には複数のトランスポートがあります。TCP/UDPモデルは名前サービス、データグラム配布、セッションサービスを分離し、IPブロードキャストありでもなしでも動作することを明示的にサポートしています。
| Service | What it does | Transport dependence |
|---|---|---|
| Name | Registers and resolves names | Broadcast, point-to-point, or a name server |
| Datagram | Connectionless messages, including broadcast | Broadcast domain or directed delivery |
| Session | Connection-oriented exchange | TCP connection to a named endpoint |
この表こそが、あの決まり文句が失敗する理由です。名前を持つ二つのホスト間のセッションサービスはIPの会話ですが、ブロードキャストのデータグラムはそうではありません。一つのVPN設計が前者を満たして後者を満たさないことがあり、前者を証明するテストは後者について何も語りません。
ノード種別がクライアントの要求を決める
RFC 1001のブロードキャスト、ポイントツーポイント、混在のノードモデルは、ホストが名前をどう解決するか——ローカルネットワークに問い合わせる、名前サーバーに直接問い合わせる、一方を試してからもう一方を試す——を説明します。モデルが影響するのはどのトラフィックを許可すべきかであり、アプリケーションが動くかどうかではありません。
管理された名前サーバーの仕組みは、クライアントにポイントツーポイントの経路を与えますが、それを使うよう設定されたクライアントだけに限られます。ネットワークのどこかにサーバーを置いても、アプリケーションがそれを参照するようにはなりませんし、ブロードキャストモードのままにされたクライアントはローカルセグメントに問い合わせ続けてタイムアウトします。サーバーのアドレスは、そのクライアントが従う管理経路を通じて、クライアントの設定に届かなければなりません。
したがって、対象のアプリケーションについては、サーバー名をアドレスにどう変えるのか、探索やメッセージ送信がブロードキャストと指向性エンドポイントのどちらを使うのか、実際のセッションがどのアドレスとトランスポートを使うのか、という三つの観察を記録してください。これらは独立した事実であり、それぞれに独自の対処があります。名前解決が一度成功しても、それは最初の一つについての証拠にすぎません。
TCP/IP上のNetBIOSはNetBEUIではない
両者は、どちらも「レガシー」と呼ばれるために混同されます。TCP/IP上のNetBIOSはサービスをIPパケットの中に載せており、ルーティングされたトンネルはそれをもう運んでいます。NetBEUIはルーティングできないレイヤー2のプロトコルであり、IPトンネルはIPを運ぶというだけの理由で任意のイーサネットフレームを運ぶわけではありません。
IPルートを追加しても、非IPのフレームをIPアプリケーションに変えることはできません。アプリケーションが本当にレイヤー2の振る舞いに依存しているなら、選択肢は明示的に区切られたレイヤー2のサービスか、アプリケーションの置き換えであり、どちらに代わるルーティング変更もありません。
課題を満たす最小の変更を選ぶ
承認されたDNS名と明示的なUNCパスで到達する既存のSMB共有に、イーサネット拡張は要りません。ファイルサービスの課題とブラウジングの体験は別の要件であり、後者だけが近隣一覧に依存します。共有に名前で到達すれば、ブロードキャストドメインをトンネル越しに引き伸ばさずに課題は解決します。
ブラウジングこそが、たいてい失敗する部分であり、しかも静かに失敗します。パスで共有を開ける一方で、近くのコンピューターの一覧が空のままになるのは、一覧がブロードキャストの探索で埋まり、パスがDNSを使うからです。一覧が必要だという判断は、ファイルが必要だという判断とは別の要件です。何かを設計する前に、利用者が実際にどちらを求めたのかを書き留めてください。
古いアプリケーションが本当にブロードキャストや非IPのフレームを必要とするなら、名前のある所有者を持つ区切られたレイヤー2のサービスを検討するか、アプリケーションを置き換えてください。ブリッジは共有される障害ドメインとポリシーの境界を広げますが、これはアーキテクチャの決定であり、NetBIOSと書かれたチェックボックスではありません。トンネルが運ぶべき具体的な操作を文書にすれば、管理者は「Windowsネットワーク全体」を推測する代わりに要求を評価できます。