Mac 共享出现在 VPN 上：停掉还是藏起来？

浏览列表由宣告构成，而宣告并不等于授权。有人在远端列表里看到你的笔记本名称，是因为一次组播查询越过了通常会在路由器处拦住它的边界。这一越界同时解释了条目为何出现，以及为何删掉条目不等于关闭服务。动手之前，先弄清你真正反对的是哪一件事。

浏览条目究竟是什么

Mac 上的 mDNS 应答器会回答它所托管服务类型的查询，应答里带着名称、端口和几条文本记录。发问的客户端随后把这个名字显示在列表里。整个交换过程没有任何一环能证明连接会成功，也没有任何一环授予权限：列表只是关于一个名字的声明，与访问无关。正是这个区别决定了你该关掉某个东西，还是停止发布它。

不同服务分别注册，所以一个条目消失并不代表所有宣告都停了。文件共享注册一种类型，屏幕共享注册另一种，打印机、媒体库和开发者工具也各自注册自己的类型。在把某一个开关当作总控之前，先列出都注册了什么、由哪个进程持有：

dns-sd -B _smb._tcp
lsof -nP -iUDP:5353

组播默认留在本地，除非有东西把它桥接过去

组播 DNS 会发送到 UDP 5353 上的链路本地组，而路由器默认不转发这个组。因此只路由单播流量的隧道会把发现留在原地，这也是路由型 VPN 上的 Mac 通常对远端站点不可见的原因。做了桥接的隧道，或刻意配置的中继，会把两端放进同一个广播域，从而改变这一点。你用的是哪种设计，是隧道本身的属性，而不是印在上面的协议名。

检查服务器配置，看它是桥接某个接口，还是路由某个子网，因为对每一种依赖广播的协议来说，这两者的行为并不相同。若隧道是桥接的，就要预期不止一种宣告泄漏出去，包括没人打算发布的东西。若是路由的，远端列表里的条目很可能来自中继或基于单播 DNS 的发现，而不是组播组。这两条路径的修法不同，只封组播端口只能堵住其中一条。

停掉服务是最干净的边界

如果这台 Mac 没有对外提供文件的必要，就用受支持的控制把共享关掉，而不是去藏它的宣告。停掉的服务连不上、猜不到，记着名字的老客户端也找不到它。正是这个性质让它成为更强的控制，而且完全不需要网络配合。

Apple 的 文件共享指南 描述了共享文件夹、允许的用户和访客访问的权限模型，共享面板会显示当前状态。真正需要这项服务时，把这三项过一遍，因为必须存在的共享，就是必须划定范围的共享。访客访问值得单独看一眼，因为它可能允许完全无凭据的连接。然后确认服务在哪些接口上监听，因为在每个接口上提供的共享，在隧道上同样提供。

当你需要服务，但不需要观众

有时共享是正当的，观众不是。把服务限制在获批来源，把发现留作独立的次要控制，才是诚实的安排。防火墙规则、按用户的权限，以及只在正确的接口上监听，都能以隐藏宣告做不到的方式收窄访问。

压制发现严格说来只是表面功夫：服务仍然会回答任何知道名字的人。如果问题出在发布本身，那就在承载它的那一层去限制。在你管理的网络上，这意味着决定哪些服务类型可以跨越边界，并据此配置桥接、中继或过滤。从论坛抄来的桥接过滤命令，只有在你服务器跑的正是一模一样的栈和隧道模式时才有效；而在你不管理的网络上，诚实的答案是：你控制不了远端客户端记住了什么。

从远端一侧去看

要从远端一侧测试，而不是从 Mac 自己的网络；要测一次全新的浏览，而不是缓存里的列表。然后再按名称和按地址各试一次直连，因为两个结果回答的是不同的问题。条目消失但连接成功，说明你藏的是标签；连接失败，才说明你关的是服务。跳过刷新会让缓存把两个测试都变成假象，所以客户端要重新启动。

把改动记下来，并注明它属于三种控制里的哪一种：停服务、限访问，还是限发现。当有人报告 Mac 仍然出现时，这份记录会告诉你：是报告过期了，还是另一个服务在自我宣告。这里大多数意外都是没人记得开过的第二个注册，而不是坏掉的开关。

在断定改动失败之前，再过一遍剩下的注册。一份短清单，胜过又一轮猜测。