企业防火墙在 VPN 里能看到什么、看不到什么

同一台笔记本在家能连上 VPN，到办公室却连不上，那就一定有人在读流量。封锁和读取是两种不同的权限，只有后者既需要在路径上占位，又需要客户端信任的证书。丢弃你握手的中间盒，对你原本要发送的内容一无所知。判断面对的是哪一种，才是全部工作。

封锁与读取是两种不同的权限

拒绝成本低，也很响：套接字打开了却没人应答，或者立刻回一个重置。这些都不意味着检查，因为没有任何载荷跨过线路。

读取需要一个终止保护、用证书自证身份、再向前另开连接的端点。这个端点必须位于路径上，并被客户端信任。只转发数据包的防火墙，既没有位置，也没有凭据。

外壳免费奉送的东西

每个隧道包都有外侧，而外侧必须可路由。这意味着两个地址、一个协议、一个端口和长度，再加上时间与流量。任何路由器本来就在处理这些字段，NAT 会改写地址和端口，以保持映射表一致。载荷仍然封闭，所以观察只能止步于「两台主机之间存在一条隧道」这个事实。

主机名并不在其中。网站会从别的门泄漏，最宽的那扇是 DNS：如果笔记本仍在询问本地解析器，名字就明摆着出现。

时间与流量值得重视，但不必夸大。每分钟字节数能显示一次大传输从 14:20 开始，却不能显示哪个文件被搬动。这是对行为的一次真实暴露，与读取内容属于不同类别。

TLS 拦截需要你本就信任的根

检查设备并不破解 TLS，而是终结它。客户端收到的是由组织自有的根签发的证书，第二条连接则通往真正的目的地。客户端之所以接受，是因为那个根就在它的信任库里，这正是一台受管笔记本不弹警告的原因。密码学从未被攻破，被挪动的是端点。

这也正是这套安排会留下证据的原因。所出示证书链上的签发者属于组织，而不是公共 CA，客户端无需特殊工具就能看到。终止于内部根的证书链，是拦截的签名，而不是故障。

为什么 VPN 通道不是 HTTPS 会话

VPN 数据通道不给检查者这样的立足点。IKEv2 与 WireGuard 各自运行握手和密钥调度，没有可终结的 TLS，而OpenVPN则以改动的形式为控制通道借用 TLS，再用自己的方式保护数据。为 HTTPS 打造的代理，认不出那个会话是它能解析的东西。

解析不了会话的设备，仍然可以把它扔掉。这正是 VPN 封锁通常看起来像超时、而不是证书警告的原因，也是加例外无济于事的原因。

从自己的机器上核对

先看网站出示的证书链。浏览器的站点详情会显示签发者，命令行则在没有摘要的情况下报告同一件事：

openssl s_client -connect example.com:443 -servername example.com

再用计数器把被拒绝的握手与被过滤的内部流量分开。在任何丢弃规则之前记录传输端口，然后重试之后读它们：

iptables -I OUTPUT 1 -p udp --dport 1194 -j LOG --log-prefix ovpn-out
iptables -vnL OUTPUT --line-numbers

外层套接字没有日志行，说明握手从未发出，路径在拒绝隧道。握手完成、只有部分目的地失败，说明隧道通而内部策略不通。两种结果都不需要读哪怕一个字节的载荷。

真正发生的读取在边缘：拆分隧道把内部 HTTPS 交给企业代理，雇主自有的集中器则把出口的一切摊开。无论你发现什么，都不要为了强行连接而关掉证书校验，因为那道检查是唯一把检查与攻击者分开的东西。