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 网络」。