在公司 Wi-Fi 上，为什么仍被要求连接 VPN？

笔记本电脑已经连上公司 SSID，也接受了证书提示，可某个 Web 应用仍然要求使用 VPN。这看起来像是重复劳动，有时也确实如此。这两次登录通常执行的是不同的判断，要知道第二次登录是否值得，唯一的办法就是问清它改变了什么。

加入网络是一项准入决定

802.1X 部署只回答一个问题：这台设备或这个用户能否接入本网络？接入点把凭据传给 RADIUS 服务器，而返回的结果可以携带属性，把该会话放进特定的 VLAN 或施加某种过滤。这属于准入与分段，而不是对任何具体应用的授权。

会话一旦被准入，无线链路就在客户端与接入点之间加密。保护到此为止，止于有线网络的边缘。

这一点之后的一切，都是楼内普通的路由转发，能到达哪些内部资源取决于该网段允许的范围。

EAP-TTLS 究竟保护了什么

EAP-TTLS 在认证过程中建立一条 TLS 隧道，并在其中运行内部方法。内部方法常常是 PAP，它出现在设计里并不意味着密码以明文穿过空口，因为承载密码的是那条 TLS 隧道。客户端仍然必须验证服务器的身份并信任正确的 CA，而一个熟悉的 SSID 并不构成这种验证。请把内部方法的选择理解为一种凭据格式，而不是关于外层加密的声明。

这是一次认证交换，而不是为笔记本后续流量建立的数据隧道。

认证结束时，TLS 隧道随之消失，客户端的报文在被准入的网段上传输。把这两者混为一谈，正是“Wi-Fi 加密已经做了 VPN 的活”这一想法的根源。

VPN 是第二个、范围更窄的决定

VPN 回答的是另一个问题：这个身份可以访问哪些私有资源，以及在什么条件下访问？它在网关处终止，该网关有自己的策略、自己的身份校验，往往还有自己的设备状态要求。隧道建立后可达的范围通常小于楼内的内部网络，并且因角色而异。

正因如此，一个维护角色可以像其他人一样被准入 Wi-Fi，却仍然需要隧道才能到达管理子网。Wi-Fi 的决定在接入点做出；这一个则在网关做出。

两个阶段都可以是加密的，却仍在执行互不相关的策略。

基于位置的信任在哪里失效

把办公网络视为天然可信，其失败原因很简单：网络位置是连接的属性，而不是人的属性。NIST 的零信任指南直接指出了这一点，这也是为什么资源访问要按请求决定，而不是按楼宇决定。任何加入同一个 SSID 的人都继承了同一个位置。同样，员工网络中一台已被入侵的笔记本，理应和访客网络中的设备受到同样的怀疑。

实际后果是，应用层的授权仍然必须存在。一个授予整个子网访问权的 VPN，加上一个信任该子网任何请求的应用，距离糟糕的一天只差一份凭据。

两者都不能取代对方，因为它们回答的是不同范围上的问题。

如何判断第二次登录是否值得保留

向网络负责人提两个问题：VPN 连上之后，哪些资源变得可达；允许连接时，检查了哪些身份或设备条件？然后通过实际测试哪些服务会响应来验证这些答案。如果隧道既没有改变可达范围，也没有提高保证程度，那它可能只是运维习惯而非一项控制措施，这该由负责人决定，而不是用户应当绕过的东西。

还要留意意外的直连路径，因为一个不经隧道就能到达的资源，会让隧道变成摆设。

把每条边界及其目的记录下来，下一个人就不必去猜为什么会有两次登录。