通过 VPN 找不到 PLC？把 Ethernet 留在机器旁

发现按钮一直转，什么也找不到，工单却说机器离线。机器本身没问题。工具在该网段上定位设备所依赖的东西，无法穿过它被指定的路径，于是本能反应就是把客户的以太网沿站点链路延伸过去，好让按钮重新工作。先弄清依赖关系。多数维护工具需要的是一条路由；当某个工具确实需要那根线时，持久的答案是放在机器旁的一台受管理主机，而不是两栋楼之间的桥接网络。

为什么发现功能会在路由隧道的边缘失效

路由隧道在子网之间传送单播报文。广播和组播帧留在一个广播域内，而 VPN 端点正是那个广播域结束的地方。靠向网段里喊来发现设备的工具只会得到沉默，因为那声喊从未被转发出去。

同样的情况也适用于根本不是 IP 的协议，以及直接跑在以太网上的厂商帧。这些无法用任何配置路由，所以给发现类问题添加路由和防火墙规则，往往一点变化也没有。

注意那种状态下还有什么能用。对已知地址的 ping 和对已知端口的单播连接通常能成功，因为隧道本来就是为这些部分建的。能用地址到达、却对发现不可见，这种组合正是缺少广播域的特征，而不是网络坏了。

选择传输方式之前，先说出依赖关系

阅读工具文档，弄清它如何发现设备、如何与设备通话，再对照这张表。

如果你这个场景里的每项要求都落在第一行，那就停在这里修路由。相比任何拓扑工作，这是更便宜、也更容易审查的改动，而且能把维护会话保持在客户已经批准的访问路径之内。

组播发现处在一个尴尬的中间地带。反射器或中继器可以把其中一部分转发过子网，于是按钮好用了，远端能到达的范围也悄悄扩大了。要把它当作有负责人的有意设计，而不是一个顺手勾选的选项。

在网段上放一台受管理主机，然后远程连进去

经得起审计的做法并不花哨。在机器维护网段上接一台客户批准的工程工作站，技术员通过已批准的远程访问通道连到那台工作站。工具在网线所在的地方运行，人在自己所在的地方工作。

这样，技术员家里的网络没有任何部分变成机器以太网的一部分，两个从未同意共享故障域的站点之间也不会架起网桥。

把本地域保持在作业允许的最小范围。一个维护 VLAN 加一台受管理主机，广播范围有限、环路域有限，故障留在厂内，而不是凌晨三点顺着 WAN 链路扩散。

给那台主机一个职责、一个负责人和一条审计线索

写明负责人，列出允许的软件，规定如何打补丁，并记录哪些用户可以访问它。作业文件和凭据要与正确的客户绑定，因为一台跑过六个站点的共用工程笔记本，就是一处等着被发现的数据边界问题。

接着看看人们容易忘记的通道。剪贴板同步、文件传输、映射驱动器和适配器共享都会把数据带过边界，而远程显示会话对这些一件都不免费。针对这项作业逐项明确决定，而不是继承客户端的默认值。客户的变更窗口也属于这个决定，因为能连上并不等于获准动手。

在政策框架方面，NIST 的SP 800-82r3把远程维护视为对运行系统的受控访问，其中连通性与设备后果要一并审查。

把 L2 延伸当作一项独立设计来审查

如果仍有人想把以太网延伸过去，就把它当作有自身风险的独立项目来审查。要问：合并后的广播域和生成树域是什么形态，两家机构之间如何管理地址，一侧出现环路时会发生什么，两端各由谁批准变更。一次成功的实验室测试回答不了这些问题中的任何一个，更不会验证设备兼容性、吞吐量或链路故障后的恢复。

接受本地主机模式，需要证明三件事：工具能执行它存在的目的操作，远程用户获准从事这项作业，被拒绝的系统从那台主机仍然不可达。然后在约定的作业结束时撤销临时访问，并确认它确实消失了。

这样留给客户的，是一个受控的本地维护场所；这个承诺比合并网络更小，也远比它容易兑现。