从 SSL VPN 到零信任：校园网远程访问的技术演进，并横向对比 Tailscale
起因：一套校园网同时挂着四套"远程访问"系统——两套要装客户端的 SSL VPN、一套网页版 WebVPN，外加一个正在试用、并被官方标注"其余三套即将停用"的新客户端。新客户端的启动页写着一句话："欢迎使用零信任，重塑安全边界"。这句话信息量很大。本文不谈任何具体机构，只把这四套东西从技术上拆开，讲清楚它们分别是什么范式、为什么旧的要被淘汰，再拿它和我自己异地组网在用的 Tailscale 做一次正交对比。全文脱敏，不出现机构名、域名、邮箱。
卷首：一个被严重重载的词——"VPN"
用户侧看到的都是"输入账号 → 连上 → 访问内网"，所以容易以为这四套是同一种东西的不同皮肤。其实它们的技术内核完全不同，分属三种范式：
| 系统（脱敏） | 客户端形态 | 技术范式 | 工作层 | 信任模型 |
|---|---|---|---|---|
| 教师 SSL VPN（即将停用） | 桌面客户端，虚拟网卡（VNIC） | 隧道型 L3 SSL VPN（Array AG/NetGate 一类） | 网络层（IP 全隧道） | 网络级信任 |
| 学生 SSL VPN（即将停用） | 桌面客户端，虚拟网卡 | 隧道型 L3 SSL VPN（EasyConnect 一类） | 网络层（IP 全隧道） | 网络级信任 |
| WebVPN（即将停用） | 无客户端，浏览器门户 | 反向代理 / URL 重写 | 应用层（仅 HTTP） | 会话级（登录即门户） |
| 新版 VPN（试用中） | 统一客户端 + 浏览器 SSO + 二次验证 | 零信任 ZTNA / SDP（aTrust 一类） | 应用层（按资源授权） | 零信任（持续校验） |
下面逐一拆。
一、隧道型 L3 SSL VPN（两套要装客户端的）
1.1 它在技术上做了什么
客户端装一块虚拟网卡（驱动名各家不同，本质是 TUN/TAP 一类内核态/准内核态设备），和网关之间建一条 TLS 加密隧道。连上之后，操作系统多出一条路由，把"内网网段"的流量丢进这块虚拟网卡 → 封进 TLS → 发给网关 → 网关解封后在内网替你转发。
关键词："连上即入网"。你的设备在网络拓扑上被逻辑地"搬进"了内网，能 ping、能 ssh、能连数据库——只要网关侧 ACL 没拦，一条隧道打通的是一个 IP 段，而不是一个应用。
1.2 技术硬伤
- 信任模型太粗（城堡-护城河）：单次认证 → 大面积 L3 可达。一旦终端被攻陷，攻击者顺着隧道做横向移动，攻击面 = 整个可达网段。这是"边界安全"模型的根本缺陷，不是配置问题。
- TCP-over-TCP meltdown：SSL VPN 多数把隧道跑在 TLS/TCP 上。当承载的也是 TCP（绝大多数业务）时，内外两层各自重传、各自拥塞控制，丢包时叠加退避，吞吐塌方、延迟抖动。这是隧道跑在可靠传输之上的协议级痼疾。
- 内核态虚拟网卡 = 兼容性地狱：驱动要签名、要适配每次 OS 大版本、要处理 ARM / Apple Silicon / 国产化（信创）系统 / 新移动 OS。"客户端装不上 / 起不来 / 和杀软冲突 / 蓝屏"绝大多数源于这块网卡。
- 高权限客户端 = 终端风险：这类客户端为了装驱动、改路由，普遍要管理员/内核权限，历史上多次被披露提权与远程代码执行问题（此处只做技术陈述）。一个跑在你机器上的高权限常驻进程，本身就是攻击面。
二、无客户端 WebVPN（反向代理 / URL 重写）
2.1 它在技术上做了什么
没有客户端，没有虚拟网卡。你在浏览器登录门户（走统一身份认证），门户做的是反向代理 + URL 重写：把内网页面抓回来，把里面所有指向内网的链接（href/src/AJAX 地址）改写成"经过门户中转"的形式再吐给你。你的浏览器始终只和门户这一个公网入口对话。
2.2 技术硬伤
- URL 重写天生脆弱：现代前端大量使用 SPA 路由、
fetch/WebSocket、JS 动态拼 URL、绝对路径、严格 CSP、跨域资源。重写引擎几乎不可能把这些全部正确改写——每接入一个复杂系统就要单独调一次，且系统一升级就可能再坏。 - 只能承载 HTTP(S)：SSH、RDP、数据库客户端、各种胖客户端协议，反向代理门户原则上搬不动（即便有 web 化封装也极受限）。覆盖面天花板很低。
- 本质仍是"登录即开门"：颗粒度停留在"会话级"，不是"按应用按身份的最小授权"。
三、零信任 ZTNA / SDP（试用中、用来取代前三套的）
3.1 它在技术上做了什么
口号"重塑安全边界"对应的是 Zero Trust 模型：never trust, always verify。落地形态通常是 SDP（软件定义边界）/ ZTNA（零信任网络访问）：
- 以身份为中心：统一身份认证（SSO/CAS）+ 二次验证（MFA），首登或久未登录强制二次校验——对应截图里的"二次验证界面"。
- 应用级最小权限：不再"把你搬进内网"。策略引擎按"这个身份 + 这台设备 + 当前风险"逐应用授权，你只拿到被显式放行的那几个资源，拿不到一个网段。横向移动空间被压到接近零。
- 隐身 / 鉴权前不可见：SDP 常用 SPA（单包授权）一类机制，鉴权通过前网关与内部资源对扫描不可见。对比之下，传统 SSL VPN 网关是常年挂在公网、可被指纹识别和持续扫描的高价值靶子。
- 持续评估：会话不是"连上就一直信任"，而是持续带着设备态势/风险信号复核。
- 单一用户态 agent + 全平台：一个客户端覆盖 Windows/macOS/Linux/iOS/Android，并明确支持国产化系统与新移动 OS；不再依赖脆弱的内核态虚拟网卡。
四、为什么"弃旧用新"——纯技术动因
把上面拆解收敛成六条，全是技术账，不掺管理因素：
- 信任模型升级：网络级信任（连上 = 一个网段）→ 应用级最小权限（连上 = 被放行的几个应用）。直接削掉横向移动与大面积攻击面。
- 攻击面收缩：公网常驻、可扫描、且历史上有 RCE 记录的 VPN 网关与高权限客户端 → 鉴权前隐身的 SDP 网关 + 现代用户态 agent。
- 信创与多端兼容：内核态虚拟网卡驱动碎片化（签名/OS 升级/ARM/国产系统全是坑）→ 统一用户态 agent，原生覆盖国产化与新移动 OS。
- 运维成本坍缩：教师 / 学生 / Web 三套异构系统 = 3 个客户端 + 3 个网关 + 3 套策略 + 3 份补丁 → 收敛成 1 套统一策略面。
- 协议与体验：TLS-over-TCP 全隧道（meltdown 风险）与 URL 重写（脆弱、仅 HTTP）→ 应用级精细路由，只有目标流量进隧道。
- 鉴权强度：单因子"入网"→ SSO + MFA + 设备态势 + 持续校验。
一句话：从"城堡-护城河"迁移到"以身份为中心、按应用最小授权的零信任"。
五、横向对比：这套零信任 vs 我在用的 Tailscale
我个人异地组网用的是 Tailscale（基于 WireGuard 的 mesh）。两者用户侧都叫"VPN"，但优化目标和架构是正交的，不是同类竞品。
| 维度 | 企业级 ZTNA（aTrust 一类） | Tailscale（WireGuard mesh） |
|---|---|---|
| 架构 | 集中式网关，hub-and-spoke，流量必经网关 | 控制面集中（协调/身份/ACL），数据面 P2P mesh |
| 协议/加密 | 私有栈，TLS-over-TCP（DTLS 可选），握手重 | WireGuard：UDP，Curve25519 / ChaCha20-Poly1305，极轻、可审计 |
| 信任模型 | ZTNA 应用代理 + 设备态势/风控引擎 | 身份（SSO/OIDC）+ tailnet ACL，每节点 deny-by-default |
| 数据路径 | 必经网关：瓶颈 + 绕行延迟 + 单一高价值靶点 | P2P 直连（近 LAN 延迟），DERP 仅做兜底中继 |
| NAT 穿透 | 客户端主动出站拨号，无需穿透 | 自动打洞 + 中继兜底，用户零配置 |
| 控制面 / 数据面归属 | 自托管设备：机构掌握鉴权 + 审计 + 数据面 | SaaS 控制面（或自托管 Headscale），数据面 P2P，不经第三方 |
| 适用场景 | 组织对自有受控资源做身份+态势+最小权限+集中审计 | 个人/小团队把自有设备组一张扁平加密网 |
5.1 它们其实在解决两个不同问题
- ZTNA 解决的是："一个组织，如何让大量身份在不可信网络下，安全、可审计、最小权限地访问它自己拥有并受监管的内部资源。" 重点在集中策略 + 审计 + 合规 + 信创覆盖。它必须把数据面攥在自己手里。
- Tailscale 解决的是："我自己这些设备，如何零配置地组成一张哪儿都能直连的扁平网络。" 重点在性能（P2P 直连）+ 现代加密 + 零运维。
5.2 一个常被忽略的点：零信任不是产品，是模型
值得强调：Tailscale 同样是零信任的一种实现——它默认 deny，靠身份 + tailnet ACL 在每个节点上逐连接放行，而不是"连上某网关就进内网"。也就是说：
- "城堡-护城河" vs "零信任" 是安全模型这根轴；
- "集中式网关" vs "去中心化 mesh" 是数据面架构这根轴；
校园网那次 old→new 的迁移，本质是在安全模型轴上从边界模型挪到零信任——方向和 Tailscale 用 ACL+身份的理念一致；区别只在数据面架构轴上：机构选了集中式自托管应用网关（因为要掌握数据面 + 审计 + 合规 + 信创），而 Tailscale 选了 P2P mesh（因为要零配置 + 性能）。两者不可互相替代。
5.3 也别用个人 mesh 去顶机构内网
技术上 Tailscale 当然能打通家里到任何地方；但用个人 mesh 去访问一个组织的受控内网，会绕过它的鉴权与审计——这正是零信任要消灭的东西。公私分离不是合规口号，是这套技术模型自洽的前提：审计在谁手里、数据面归谁，决定了该用哪一套。
六、个人反思
- "VPN" 这个词应该被拆掉。传输级隧道（SSL VPN）、反向代理门户（WebVPN）、零信任应用代理（ZTNA）、P2P 加密 mesh（Tailscale）——用户侧体验相似，技术内核四套完全不同的东西。讨论前先问"它工作在哪一层、信任模型是什么"。
- 隧道型 SSL VPN 的淘汰是范式淘汰，不是产品换代。内核态虚拟网卡 + 网络级信任 + TLS-over-TCP，这三条在信创化、零信任、移动化的趋势下没有补丁可打，只能换范式。
- 选型先定两根正交轴：安全模型（边界 / 零信任）、数据面架构（集中网关 / 去中心化 mesh）。把这两根轴分开看，"公司该上 ZTNA 还是 Tailscale""个人该用哪个"这类问题会瞬间清晰——答案取决于谁拥有控制面与数据面、审计在谁手里、要的是"受控资源访问"还是"自有设备组网"。
- 对个人而言，结论很简单：机构资源走机构的零信任客户端（受审计、合规），自有设备异地组网走 Tailscale（零配置、P2P、现代加密），两条线物理隔离。 这不是妥协，是这套技术模型本来就该有的样子。
本文协议：CC BY-NC-SA 4.0，转载请保留出处。全文已脱敏，不指向任何具体机构、域名或个人。
💬 评论