未经授权的 VPN 路由器：先管准入，再谈解密

一台陌生路由器出现在内部交换机端口上并立即向外建立 VPN 时，它早已越过了最关键的那道控制。准入决定设备究竟能否拿到可用的网络访问，而解密只能告诉你它之后做了什么。把这个次序摆正，一场无从下手的检查就会变成日常的端口策略问题。这也是可回退操作与服务中断之间的差别。

准入在端口上决定

先问设备怎么拿到可用连通性，再问它的隧道里跑什么。插在在用墙面端口上的路由器，或接入了开放 SSID 的无线客户端，是被该端口或该 SSID 所执行的策略放进来的。如果那条策略是"插上就发一个能用的 VLAN"，那么 VPN 只是症状，而不是漏洞本身。

DHCP 租约不是授权记录。能否拿到地址描述的是地址分配服务，而不是端口的状态，许多设计允许未认证设备只能到达辅助服务，却拒绝其余一切。把租约表当作关于编址的证据，而不是关于信任的证据。

这类调查里常被混为一谈的有三种证据：获准的人、获准的受管设备，以及资产清单上的一行记录。端口策略应当明确接受哪一种，因为被盗的凭据和被克隆的 MAC 地址满足的是不同的条件。

已认证的端口究竟决定了什么

在 IEEE 802.1X 中，交换机或接入点是认证方，它作为 RADIUS 客户端把申请者的凭据转交给中央服务。这些 RADIUS 802.1X 属性 让该结果能够授权端口，并按设计把会话放进特定 VLAN 或特定的计费上下文。只有当端口被配置为强制执行时，交换机才会执行策略服务器返回的结果。

部署真正悄悄失效的地方，正是最后这一条。留在监控或记录模式下的端口会记下本该做出的决定，却照样放行流量，于是在每份报告里都像一次正常运行的部署，直到有人插上一台不受管的路由器。

switch# show authentication sessions interface Gi1/0/12
Interface  MAC Address      Method  Status
Gi1/0/12   a4bb.6d12.3f09   dot1x   Authz Success
switch# show dot1x interface Gi1/0/12 details
  Oper control mode: auto
  PAE state: Authenticated

跑不了认证客户端的设备需要单独的决定，而不是一刀切的豁免。MAC 认证旁路、注册门户或专用设备 VLAN 都是正当答案，但每一种都必须刻意选定并写入文档。写清楚哪些设备类别可以使用兜底路径，以及由谁批准。没有文档的兜底路径，正是不受管路由器在无人批准的情况下拿到可用 VLAN 的方式。

不解密也能看到什么

加密隐藏的是载荷，而不是行为。源地址与目的地址、端口、报文时序、流量体积和会话时长，在采集它们的边界上依然可见，而这些元数据往往足以把一台陌生设备与某个端口和某个外出目的地联系起来。读不到的是隧道里的应用，没有密钥，再怎么抓包也改变不了这一点。

长期存在的隧道并不自动等于恶意。站点间链路、备份代理和远程管理工具都按设计持续运行，所以一条持续整夜的流本身什么也证明不了。要拿它与该资产被赋予的角色、以及该网段获批的基线作比较。

有意识地限定出口。允许一个目的端口，不等于批准使用它的应用；分类器的猜测也不是授权决定。按调查需要采集元数据，指定负责人和保存期限，而不是默认对每个用户的全部流量做完整抓取。

在你能控制的边界上做遏制

隔离任何设备之前，先确认它归谁所有、接在哪里。然后用事件流程限制端口或吊销会话，趁证据还新鲜时保全相关日志。交换机端口可以关掉再打开；而一条承载四十个工位的生产上联，没那么容易撤回。

不要对终端发起反击，也不要仅凭一次扫描提示了某种 VPN 协议就关掉共享端口。这两种做法都会打断正常工作，却没有改善当初让设备进来的那个准入决定。

验收标准很具体：已批准的终端仍然拿到其角色所需的访问，未批准的设备拿不到等效路径。监控支撑的正是这条边界，而它不需要破解任何人的加密就值得一做。