学校是怎么知道你在翻墙的

本文仅作技术讨论，不包含有效的反监管办法，仅对校园网/企业网环境下使用 AAA / 上网行为管理进行简单科普。

原文：linux.do/t/topic/2900482（网络知识扫盲系列文档共建）

这是系列帖之一，同系列还有：

• 网络结构与 VPN / 代理服务区别
• 一批代理节点的两轮 TLS 测试与警惕让你安装证书的机场
• Telegram 是如何避免你留证的，企业又是如何留证的

在校园网和企业网中，一个非常常见的问题是：网络已经部署完成了，终端也能够正常接入交换机和无线网络，那么接下来如何确定

谁可以接入网络（Authentication 认证，用来识别访问网络的用户的身份，判断访问者是否为合法的用户）

接入以后能够访问什么（Authorization 授权，是指对不同用户赋予不同的权限，限制用户可以使用的服务）

用户在网络中做了什么（Accounting 计费，用来记录用户使用网络服务过程中的相关操作，简单说就是：什么人、什么时间、做了什么事）

这三个问题实际上对应了企业网络中三个不同的安全阶段：

身份认证 → 网络准入 → 上网行为管理

很多刚接触企业网络的同学容易把它们混在一起，例如认为部署了 Portal 认证就是完成了网络准入，或者部署了一台上网行为管理设备就可以解决终端身份认证问题。实际上，两者解决的问题完全不同。

一、先理解三个核心问题

假设某公司/园区/校园宿舍有 1000 名员工，同时还有访客、打印机、摄像头、会议终端以及员工个人手机接入网络。

网络管理员首先需要解决的是：

第一，这台设备是谁的

例如：

• 张三的办公电脑
• 李四的手机
• 财务部门打印机
• 会议室电视
• 外来访客笔记本
• 始皇的 5080Ti 台式机

这属于身份认证 Authentication。

第二，这个用户或者设备是否允许进入网络

例如：张三属于研发部门，可以进入研发 VLAN；李四属于财务部门，可以进入财务 VLAN；访客只能进入 Guest VLAN；未知终端只能进入隔离 VLAN。

这属于网络准入 NAC，Network Access Control。

第三，进入网络以后允许访问什么

例如：普通员工允许访问互联网，但禁止访问赌博、恶意网站、常见游戏域名；研发部门允许访问 GitHub、LinuxDo；访客只能访问互联网，不能访问企业内部服务器；办公终端不能使用 BT、P2P 等应用。

这部分通常属于上网行为管理、应用控制以及安全策略。

所以完整逻辑可以理解为：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

终端接入网络
    │
    ▼
身份认证
802.1X / Portal / MAC
    │
    ▼
AAA服务器
RADIUS / LDAP / AD
    │
    ▼
准入控制
VLAN / ACL / Role / Security Group
    │
    ▼
访问网络
    │
    ▼
防火墙 / 上网行为管理
URL / 应用 / 流量 / 审计
    │
    ▼
Internet / 企业业务系统

二、校园网为什么需要准入认证

校园网可能是准入认证应用最典型的场景之一。因为校园网络拥有几个明显特点：

• 用户数量非常大
• 终端类型复杂
• 用户流动性高
• 有线和无线网络同时存在
• 学生、教师、访客权限不同
• 经常需要进行实名审计

例如一所大学可能同时存在学生、教师、行政人员、实验室设备、宿舍电脑、学生手机、打印机、摄像头、IoT 设备、访客等大量终端。

如果完全依靠 VLAN 对这些终端进行管理，很快就会遇到问题：例如一个学生把电脑从宿舍楼搬到教学楼以后，交换机端口发生了变化，如果权限完全依赖交换机端口配置，那么管理员可能需要不断修改 VLAN。

而采用基于身份的准入控制以后，网络可以实现：

1
2
3
4
5

用户是谁
    ↓
决定用户属于什么角色
    ↓
根据角色动态下发网络权限

这样网络权限就从「端口决定权限」逐渐变成「身份决定权限」，这也是现代园区网非常重要的发展方向。

三、企业网准入认证的核心架构

典型企业准入架构通常包含四类组件。

其中最重要的几个角色分别是：

1. Supplicant

也就是认证客户端。例如 Windows 电脑本身就支持 802.1X，终端负责向网络设备提供身份认证信息。

2. Authenticator

通常是接入交换机、无线 AP、无线 AC。Authenticator 本身一般不会保存大量用户账号，它主要负责发现终端 → 发起认证 → 转发认证信息 → 根据认证结果控制端口权限。

3. Authentication Server

通常就是 RADIUS/NAC 服务器。例如华为环境中可能使用 iMaster NCE-Campus 等平台，H3C 环境可能使用 iMC，Cisco 环境中经常使用 Cisco ISE，Aruba 环境中常见 ClearPass。除此之外也可以使用 FreeRADIUS、Microsoft NPS 或其他第三方 RADIUS 服务器。

四、企业网最常见的三种认证方式

网络准入中最常见的认证方式主要有：802.1X、MAC 认证、Portal 认证。三种方式分别适用于不同场景。

802.1X 认证

802.1X 是企业办公网络中非常典型的认证方式，它本质上属于一种基于端口的网络访问控制技术，由 IEEE 802.1X-2010 标准定义。整套机制运行在数据链路层之上，依赖三个角色之间的交互：Supplicant（客户端）、Authenticator（认证者，即交换机/AP）、Authentication Server（认证服务器，即 RADIUS）。

三者之间的承载协议链路是：

1
2

Supplicant ──EAPOL──> Authenticator ──EAP over RADIUS──> Authentication Server
            (IEEE 802.1X)              (RFC 3579 / RFC 2865)

EAPOL（EAP over LAN，定义于 IEEE 802.1X）是终端到交换机这段链路的封装格式，它把 EAP 报文直接封装在以太网帧里（EtherType 0x888E），不经过 IP。而交换机到 RADIUS 服务器这段则把 EAP 报文再封装进 RADIUS 的 EAP-Message 属性（RFC 3579）里走 UDP/1812 或 UDP/1813。

典型的 EAP 方法包括：

现代企业办公网几乎清一色使用 PEAP-MSCHAPv2 或 EAP-TLS。两者的关键区别在于：EAP-TLS 要求终端也持有证书，私钥不可导出，安全性极高但 PKI 部署成本高；PEAP 只要服务器有证书，终端输入账号密码即可，部署方便但密码强度成关键弱点。

交换机端口在认证过程中存在一个明确的端口状态机，这是理解"为什么认证前上不了网"的核心：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

未认证状态（Unauthorized Force / Controlled Port 关闭）
        │
        │ 仅放行 EAPOL 报文到 Supplicant，其余业务流量丢弃
        │
        ▼
认证中（Authenticating）
        │ 交换机转发 EAP 报文到 RADIUS，等待 Access-Request/Challenge/Accept
        │
        ▼
认证成功（Authorized / Controlled Port 打开）
        │ 端口变为 Authorized，业务流量放行
        │ RADIUS 通过 Access-Accept 下发授权属性（VLAN/ACL/带宽等）
        │
        ▼
认证失败 / 超时
        │ 端口保持关闭，或转入 Guest / Quarantine VLAN（取决于策略）

这个 Controlled Port / Uncontrolled Port 的双端口模型是 802.1X 的精髓：Uncontrolled Port 只允许 EAPOL 流量通过，Controlled Port 在认证通过前对业务流量全部丢弃。这就是为什么拔掉网线重插后，在还没认证的几秒里你什么都访问不了——连 DHCP 都过不去。

典型流程为：

1
2
3
4
5
6
7
8

PC ──EAPOL-Start──> 交换机
交换机 ──EAP-Request/Identity──> PC
PC ──EAP-Response/Identity（账号）──> 交换机
交换机 ──Access-Request（EAP-Message）──> RADIUS
RADIUS ──EAP-Request（TLS 隧道 / MSCHAPv2 Challenge）──> 交换机 ──> PC
...（多轮交互建立 TLS 隧道并验证账号密码）...
RADIUS ──Access-Accept（含授权属性）──> 交换机
交换机 打开 Controlled Port，下发 VLAN/ACL

用户接入交换机以后，交换机端口最开始处于受限状态，只有认证成功以后，交换机才允许用户正常访问网络。认证成功以后还可以动态下发 VLAN、ACL、用户角色、带宽策略、安全策略——这些下发动作是通过 RADIUS 的 VSAs（厂商自定义属性） 实现的，例如：

例如：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

张三
部门：研发部

认证成功
↓
动态进入 VLAN 100
↓
下发研发访问ACL
↓
允许访问Git服务器

而财务部门用户可能进入 VLAN 200，并获得完全不同的访问权限。

MAC 认证

但是企业网络中并不是所有设备都支持 802.1X，例如打印机、IP 电话、摄像头、门禁、部分 IoT 设备、会议设备——这些设备通常无法输入用户名密码。于是就会使用 MAC Authentication Bypass，MAB，也就是根据终端 MAC 地址进行身份识别。

例如：

1
2
3
4
5
6
7

00-11-22-33-44-55
↓
RADIUS查询
↓
识别为财务打印机
↓
进入Printer VLAN

Cisco 环境中经常称为 MAB，华为、H3C 等厂商也存在类似 MAC 地址认证机制。MAC 认证部署简单，但是安全性低于证书型 802.1X，因为 MAC 地址本身可以伪造，因此 MAC 认证通常用于无法进行 802.1X 认证的特殊终端，而不是所有办公电脑。

Portal 认证

Portal 认证在校园网、访客网络以及公共 Wi-Fi 中非常常见。与 802.1X 在链路层拦端口不同，Portal 认证是在 IP 层（网络层） 做拦截的，核心机制是 HTTP 重定向 + 白名单放行。

工作原理是：终端关联 Wi-Fi 后，DHCP 给它分配 IP，但此时网关（通常是 AC 或防火墙）在该用户的 ACL 里只放行以下几类地址——DNS 服务器、Portal 服务器、少量必要的白名单域名。当终端尝试访问任意 HTTP 网站时：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

终端 ──HTTP GET http://example.com/──> 网关
                                        │
                                        │ 网关查 ACL：该用户未认证
                                        │
                                        ▼
终端 <──HTTP 302 重定向── 网关
            Location: http://portal.school.edu.cn/?redirect=原URL&userip=10.10.20.35
                                        │
                                        ▼
终端 ──GET portal 页面──> Portal 服务器（白名单已放行）
终端 填写账号密码提交
Portal ──RADIUS Access-Request──> AAA
AAA ──Access-Accept（下发授权）──> Portal
Portal ──通知网关──> 该用户/IP 解除拦截，放行全网
终端 <──认证成功页 + 原页面自动跳转

这里有个细节：为什么 Portal 几乎只能拦 HTTP，拦不了 HTTPS？因为重定向需要网关改写 HTTP 响应，而 HTTPS 流量经过 TLS 加密，网关在没有解密能力的情况下根本看不到 http:// 这样的明文 URL，也就无法插入 302 跳转。这就是为什么很多校园网你访问 HTTPS 网站时页面直接转圈打不开、而不是弹出认证页——它不是在"重定向"，而是在"静默丢包"。

典型体验就是：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

连接Wi-Fi
↓
打开任意 HTTP 网页（触发重定向）
↓
跳转到认证页面
↓
输入账号密码
↓
认证成功
↓
网关解除拦截，放行互联网

例如大学校园网经常要求学生输入学号、密码，认证以后才允许访问互联网；企业 Guest Wi-Fi 也可能要求手机号、短信验证码、访客邀请码。

Portal 最大的优点是终端不需要安装专用客户端，因此非常适合 BYOD、访客、学生、临时终端。但是对于严格的企业办公准入来说，802.1X 通常拥有更好的安全性和身份绑定能力。

三种认证方式如何组合

实际网络很少只使用一种认证方式。更常见的设计是：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

办公PC
    ↓
802.1X

打印机 / 摄像头 / IP Phone
    ↓
MAC认证

访客 / BYOD
    ↓
Portal认证

例如某企业园区可以采用：

这样就形成了一套完整的准入认证体系。

五、认证成功以后发生了什么（Authorization 授权）

很多人学习准入认证时只关注「认证成功」，但实际上认证成功只是第一步，真正重要的是认证以后如何授权。

RADIUS 服务器可以根据用户身份返回不同属性。例如：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

研发用户
↓
VLAN 100

财务用户
↓
VLAN 200

访客
↓
VLAN 300

非法终端
↓
Quarantine VLAN

除此之外还可以动态下发 ACL。例如：

1
2
3
4
5
6
7
8
9

研发用户
允许：
Internet
Git
开发服务器

禁止：
财务系统
核心数据库

这样就实现了：同一台交换机、同一个接入网络，不同身份获得不同权限。

六、Accounting 计费：它到底"记录"什么

前面我们介绍 AAA 时提到了三个核心概念：

1
2
3

Authentication  认证：你是谁
Authorization    授权：你能做什么
Accounting       计费：你做了多久、用了多少、什么时候开始和结束

这里的 Accounting 中文通常翻译为"计费"，但是在校园网和企业网络中，它的作用并不只是计算你上网的网费（再说现在都是包月或者绑定套餐了），更主要的作用是：

1
2
3
4
5
6

记录用户会话
记录上线时间
记录下线时间
记录在线时长
记录流量使用情况
为日志审计提供身份与时间依据

以经典 RADIUS Accounting 为例，RFC 2866 定义了 Start、Stop、Interim-Update 三类 Accounting 报文（统称 Accounting-Request，Code=4），它们都是终端用户态发生变化时由 NAS（网络接入设备，即交换机/AC）主动发给 RADIUS 服务器的。每条报文都带一个 Acct-Status-Type 属性表明这是 Start（1）、Stop（2）还是 Interim-Update（3）。

一条真实的 Accounting-Request（Start）报文通常携带的关键属性如下：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

User-Name              = "zhangsan"
NAS-IP-Address         = 10.10.0.1          # 接入交换机的管理 IP
NAS-Port               = 50123              # 物理端口号
Acct-Status-Type       = Start (1)
Acct-Session-Id        = "8D10F23C-00001A2B" # 会话唯一标识，Start/Interim/Stop 必须一致
Framed-IP-Address      = 10.10.20.35        # 给终端分配的 IP
Calling-Station-Id     = "AA-BB-CC-DD-EE-FF" # 终端 MAC
Called-Station-Id      = "00-11-22-33-44-55:WIFI-SSID"
NAS-Identifier         = "Access-SW-01"
Acct-Authentic         = RADIUS (1)         # 表明是 RADIUS 认证而非本地认证

当会话中途，交换机按 Acct-Interim-Interval（秒）周期性发 Interim-Update，追加：

1
2
3
4
5
6

Acct-Status-Type       = Interim-Update (3)
Acct-Session-Time      = 14400              # 已上线秒数
Acct-Input-Octets      = 1200000000         # 上行字节数（约 1.2GB）
Acct-Output-Octets     = 8700000000         # 下行字节数（约 8.7GB）
Acct-Input-Packets     = 9500000
Acct-Output-Packets    = 12000000

会话结束时发 Stop 报文，额外带上：

1
2
3
4
5

Acct-Status-Type       = Stop (2)
Acct-Terminate-Cause   = User-Request (1)   # 下线原因：用户主动 / 超时 / 管理员踢 / 端口 down 等
Acct-Session-Time      = 28800
Acct-Input-Octets      = ...                # 全程累计
Acct-Output-Octets     = ...

典型流程可以表示为：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

用户认证成功
    │
Accounting Start
开始记录会话
    │
用户正常访问网络
    ├── Interim-Update
    │   周期性更新会话信息
Accounting Stop
结束会话

最终 AAA 系统可能得到类似这样的数据：

1
2
3
4
5
6
7
8
9

用户名：zhangsan
终端IP：10.10.20.35
NAS：Access-SW-01
Session-ID：XXXXXXXX
上线时间：08:31
在线时长：28800 秒
上传流量：1.2 GB
下载流量：8.7 GB
下线原因：正常断开

这时候管理员已经能够知道：谁、在什么时候、通过什么网络设备、使用了多长时间、产生了多少流量。

但是这里需要注意一个非常重要的概念：RADIUS Accounting 本身并不会天然告诉管理员"用户访问了哪个网页、看了什么视频、使用了什么应用"。 例如 Accounting 可以告诉管理员「zhangsan 今天在线 8 小时，产生 10GB 流量」，但是并不能直接得到「zhangsan 访问了 GitHub、观看了视频网站、使用了某个 IM 软件」。

这些更细粒度的信息，需要继续由上网行为管理、防火墙、DNS 日志、代理日志、应用识别、流量分析、安全审计系统进行记录。

因此可以把二者理解为：

1
2
3
4
5

AAA Accounting
        │ 提供身份、会话、时间、流量基础
上网行为管理
        │ 继续识别具体网络行为
完整审计记录

七、准入认证和上网行为管理有什么区别

这是实际项目中非常容易混淆的问题，可以简单理解为：

准入认证主要解决：你是谁，你能不能进入网络

上网行为管理主要解决：进入网络以后，你可以干什么

假设某企业用户张三使用公司电脑接入网络：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

张三的PC
   │ 802.1X
接入交换机
   │ RADIUS
AAA服务器
   ├── Authentication
   │   确认：这是张三
   ├── Authorization
   │   确认：张三属于研发部门
   └── Accounting
       记录：张三什么时候上线、在线多久、产生多少流量

认证完成后：

1
2
3
4
5
6
7

张三
 │
核心交换机
 │
上网行为管理AC
 │
Internet

准入设备通常负责：身份、设备、角色、VLAN、ACL。

上网行为管理设备则可能负责：URL 分类、应用识别、带宽管理、日志审计、文件传输控制、P2P 限制、IM 应用控制、视频流量控制、恶意网站过滤。

上网行为管理系统继续看到：源 IP、目的 IP、协议、应用、域名、URL 分类、连接时间、上传流量、下载流量。随后系统再把这些信息和用户身份、IP 地址、MAC 地址、部门、用户组进行关联。

最终管理员看到的就不再只是 10.10.20.35，而可能是：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

用户：zhangsan
部门：研发部
IP：10.10.20.35
终端：Windows PC

08:31 用户上线
08:45 访问技术网站
09:10 使用GitHub
10:20 使用企业微信
11:30 产生大量文件下载流量

所以上网行为管理或者说现代企业/园区网络一个非常重要的能力就是：把"流量"变成"带身份的流量"。

图为深信服 AC 上网行为管理设备（旧款）。

八、以深信服 AC 为例理解行为管理

前面我们把准入和上网行为管理拆开讲，是为了帮助理解不同功能解决的问题。但真实产品并不一定严格按照「一台 NAC 只负责认证、一台 AC 只负责行为管理」这样的方式部署。

深信服当前的全网行为管理 AC 本身就提供用户认证、上网管控、终端安全管控等能力，同时官方文档中也包含 Portal 接入认证、访问权限策略、应用控制、上网审计、流量与上网时长分析等功能。

因此实际项目中更适合按照功能层而不是简单按照设备名称理解整个体系。例如从逻辑上可以拆成：

1
2
3
4
5
6
7
8
9

深信服 AC
                   │
       ┌───────────┼───────────┐
       │           │           │
    用户认证     行为控制      行为审计
       │           │           │
   Portal等      应用控制      日志记录
   用户识别      URL控制      流量分析
   身份关联      流量控制      用户分析

这说明现代上网行为管理已经逐渐从单纯的「禁止访问某个网站」发展成「身份+终端+应用+流量+数据+行为」的综合管理体系。

九、行为审计究竟能够记录什么

以行为管理设备为例，可以把审计信息粗略分为几个层次。

第一层：身份信息

1
2
3

用户名 / 用户组 / 部门
IP地址 / MAC地址 / 终端信息
认证时间

回答的是：谁在使用网络。

第二层：连接信息

1
2
3

源IP / 目的IP / 源端口 / 目的端口
协议 / 开始时间 / 持续时间
上传流量 / 下载流量

回答的是：这个用户与谁建立了网络连接。

第三层：应用信息

通过应用识别能力进一步判断：网页浏览、即时通信、在线视频、网络游戏、P2P、远程访问、云盘、代码托管、办公应用。

回答的是：这个连接大概是在干什么。深信服 AC 当前产品文档中仍然提供独立的应用控制能力，同时日志中心提供用户行为分析、流量时长分析和终端接入分析等功能。

第四层：内容与行为信息

在协议、加密状态以及设备能力允许的情况下，还可能进一步获得：访问域名、URL 分类、文件传输行为、搜索行为、部分应用操作、上传下载行为。这就进入了真正意义上的上网行为审计。

所以完整链路可以理解成：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

AAA
确认"你是谁"
    │
Accounting
记录"你什么时候用了网络、用了多少"
    │
行为管理
分析"你在使用什么网络服务"
    │
行为审计
形成可查询的网络活动日志

十、用了代理或者 VPN 还能被看到吗

在校园网和企业网络论坛中，经常可以看到类似的问题：

使用代理以后，学校还能看到我访问什么吗？ 使用 VPN 能不能避开校园网的上网行为管理？ HTTPS 都加密了，管理员是不是就什么都看不到了？

这里首先需要明确一个非常重要的原则：加密通信并不等于网络连接不可见。

正常情况下，一个数据包想通过校园网发送到 Internet，校园网中的路由器、防火墙等设备至少需要知道「这个数据包从哪里来、要到哪里去」，否则网络本身就无法完成路由转发。即使 HTTPS 已经对应用数据进行了加密，网络设备仍然可能观察到：

1
2
3
4
5
6
7
8

源IP：10.10.20.35
目的IP：203.x.x.x
目的端口：443
协议：TCP
连接建立时间
持续时间
上传字节数
下载字节数

因此通信内容加密 ≠ 网络通信不可见。

HTTPS 到底隐藏了什么

HTTPS 主要保护的是网络分层中的应用层通信内容，例如账号密码、网页正文、Cookie、表单数据、聊天正文、具体 HTTP 请求内容。在正常 TLS 加密并且不存在额外解密机制的情况下，中间网络设备通常不能像分析明文 HTTP 那样直接读取这些内容。

但是 TLS 握手本身在大部分情况下是明文传输的，而握手过程泄露的元数据远比想象中多。一个标准的 TLS 1.2 ClientHello 报文，即便后续所有应用数据都加密了，中间设备依然能从握手的明文部分提取出：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

TLS ClientHello（明文可见部分）
├── Client Version / Supported Versions      → TLS 版本（1.2 / 1.3）
├── Cipher Suites（密码套件列表）             → 客户端支持的加密算法组合，顺序与组合因软件而异
├── Extensions                               → 扩展字段
│   ├── Server Name Indication (SNI)         → 【明文】访问的域名，例如 server_name=github.com
│   ├── Supported Groups (椭圆曲线)           → x25519 / secp256r1 ...
│   ├── Signature Algorithms                 → 支持的签名算法
│   └── ALPN                                 → h2 / http/1.1
├── Compression Methods
└── 随机数 / Session ID / Session Ticket

其中 SNI（Server Name Indication）是最关键的泄露点：它在 TLS 握手第一阶段就以明文形式告诉服务器"我要访问哪个域名"，因为服务器需要据此选择对应的证书（一台 IP 上可能托管几百个域名）。只要校园网抓一下 SNI，就知道你在访问 github.com 还是 pornhub.com，哪怕后续内容完全加密。这也是所有 DNS/内容分级过滤的基础观测点之一。

加密 SNI（ECH，Encrypted Client Hello） 是对 SNI 明文泄露的直接对策：用 DNS 里的 HTTPS 记录（SVCB/HTTPS RR，RFC 9460）预先公告服务器的公钥，客户端用它加密整个 ClientHello，从而让中间设备连域名都看不到。ECH 在 Firefox/Chrome 已可启用，但截至 2026 年部署率仍很低，且部分网络会直接阻断携带 ECH 扩展的握手。

除了 SNI，行为管理设备还能从 ClientHello 的其余特征推断客户端身份——这就是 JA3 / JA4 指纹 技术。JA3（Salesforce 2017 年提出）把 ClientHello 里的版本、密码套件、扩展、椭圆曲线、签名算法按固定顺序拼接后做 MD5，得到一个 32 位指纹。不同软件（Chrome / Firefox / curl / 一个代理客户端）生成的 ClientHello 组合几乎不可能完全相同，因此指纹就成了客户端的"指纹"：

1
2
3
4
5

# 一个典型 JA3 串（拼接后的明文，再算 MD5 得到指纹）
771,4865-4866-4867-49195-49199-...,0-23-65281-10-11-35-16-5-34-51-43-13-45-28-...,
   29-23-24,0

JA3 指纹 = e7d705a3286e19ea42f587b344ee6865

意义在于：如果一个学生终端宣称自己用的是浏览器，但抓到的 JA3 指纹却匹配某个已知代理客户端（Shadowsocks/V2ray 的某些实现有独特指纹），行为管理设备就能在 TLS 内容完全不可见的情况下，仅凭握手特征标记"这个连接高度可疑"。这也是为什么现代代理工具（如 XTLS-Reality、utls 库）会刻意伪装 ClientHello 来模拟真实浏览器的 JA3——这就是一场围绕 TLS 握手指纹的攻防。

但是网络侧仍然可以获得大量 Metadata（元数据）：哪个终端建立了连接、连接到了哪个 IP、什么时候连接、连接持续多久、上传多少数据、下载多少数据。另外，根据实际协议版本、DNS 方式、TLS 握手信息以及设备识别能力的不同，还可能推断或识别部分服务信息。

所以准确的说法不是「HTTPS 以后管理员什么都看不到」，而应该是「HTTPS 保护了通信内容，但握手元数据仍可能暴露你要访问的目标和所用工具」。

代理服务器改变了什么

普通网络访问通常是「用户 → 网站A / 网站B / 网站C」，当用户使用代理服务器以后，可能变成「用户 → 代理服务器 → 网站A / 网站B / 网站C」。

从校园网或者企业网络的角度来看，原来可能观察到的是「用户 → 网站A / 网站B / 网站C」，现在可能更多表现为「用户 → 代理服务器」。因此代理能够改变网络管理设备直接观察到的目标。

但是它并不会让以下信息自动消失：

1
2
3
4
5
6
7
8
9

用户是谁
终端IP是什么
MAC地址是什么
什么时候上线
连接到了哪个代理节点
什么时候建立连接
连接持续多久
产生多少上传流量
产生多少下载流量

如果前面还有 Portal、802.1X、RADIUS、DHCP、NAC，那么网络管理员还可能继续把账号、MAC、IP、时间、网络连接关联起来，最终可能形成：

1
2
3
4
5
6
7

Student001
     │
     ├── MAC：AA-BB-CC-DD-EE-FF
     │
     ├── IP：10.10.20.35
     │
     └── 长时间连接203.x.x.x

因此：代理 ≠ 网络隐身。代理是改变了流量的中间路径以及网络管理设备能够直接观察到的信息范围。

VPN 也是同样的道理

VPN 的结构通常更加明显：用户终端 → 加密隧道 → VPN Server → 网站A / 网站B / 网站C。对于校园网来说，原来的多条「用户 → 网站」可能变成「用户 → VPN 服务器」。

如果 VPN 隧道使用可靠加密，校园网络通常无法直接读取隧道内部已经加密的应用层数据，但是网络侧仍然可能看到：哪个账号在线、哪个终端发起连接、终端 IP、VPN 服务器 IP、连接协议、开始时间、持续时间、上传流量、下载流量。

因此：VPN ≠ 隐身。VPN 更准确的作用之一是「改变不同网络参与方能够直接看到哪些信息」。原本校园网络看到的是多个目的 IP，使用 VPN 后可能变成只有一个 VPN Server，但是与此同时 VPN 服务提供者 成为了新的网络中间参与方。所以从隐私模型来看，这实际上还涉及「信任从谁转移给了谁」，而不是所有观察者全部消失。

不解密内容也能识别：流量分析与统计指纹

前面讲的 SNI、JA3 都还在"看得到明文字段"的范畴。但即使一个流量完全加密、连 SNI 都藏住了（比如走代理 + 加密 DNS），行为管理设备仍然有一条路子识别它——流量分析（Traffic Analysis）/ 统计指纹。

核心思想是：不同应用产生的**流量形状（flow shape）**有显著差异，加密只掩盖内容，掩盖不了时序、包长分布、连接模式这些统计特征。常用特征包括：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

单个流（flow）维度：
├── 包长分布（packet size distribution）
│     网页浏览：大量小下行包 + 少量上行 ACK
│     视频流：稳定的大块下行包（MTU 大小，1500B 左右密集）
│     SSH/RDP：交互式，小包双向频繁
│     文件下载：持续大流量单向
├── 包间隔时间（IAT, Inter-Arrival Time）
│     交互式应用 IAT 抖动大；流媒体 IAT 周期性
├── 流持续时间 / 总字节数 / 包数
└── 上下行字节比（aspect ratio）
     视频下载 ≈ 1:20，网页 ≈ 1:3，VPN 全局代理 ≈ 1:1（因为所有流量都打包走）

多流（cross-flow）维度：
├── 同时活跃的连接数
├── 连接的目的 IP / 端口分布
└── 与已知协议行为库的匹配度（机器学习分类器）

研究界早在 2000 年代就证明，仅凭包长序列和时序就能用机器学习把不同应用（Web / VoIP / P2P / 流媒体）分到 90% 以上准确率。商业行为管理设备的"应用识别"很大一部分就是这类统计分类器，配合规则库做组合判断。这意味着：即使你用了代理把所有流量伪装成"连到一个 IP 的 TLS 流"，只要这个流的形状长得像视频、像 P2P、像长链接隧道，设备照样能打上"可疑代理/VPN"的标签，哪怕它不知道你具体在看什么。

这也是为什么现代混淆协议（如 Trojan、XTLS-Reality、shadowtls）不只加密内容，还要在包大小和时序上刻意模仿真实 HTTPS 网页流量——这是一场针对统计特征的对抗，不只是加密强度的对抗。

上网行为管理设备能不能识别代理和 VPN

这需要根据具体协议、加密方式、设备版本、特征库以及网络策略判断，不能简单说「一定可以」也不能简单说「一定不可以」。行为管理设备进行应用识别时，通常不会只依赖端口号，现代应用识别还可能综合目的地址、协议特征、连接行为、流量特征、应用特征库、TLS 相关信息、已知服务地址进行判断。

深信服 AC 本身提供应用控制、访问权限策略等功能，因此在具体部署和策略允许的情况下，可以针对被识别出的应用类别执行允许、拒绝或其他管理动作。但是随着 TLS、QUIC、VPN、代理、加密 DNS、各种加密隧道不断普及，网络设备能够直接看到的应用层信息也会发生变化。这也是为什么现代行为管理越来越依赖「身份信息 + 流量元数据 + 应用识别 + 终端信息 + 日志关联」，而不是简单依靠抓取明文 HTTP。且现代设备最重要的特性就是联网、算法、规则库以及现在各个厂商在尝试接入的安全大模型。

十一、AAA 之外，校园/企业网怎么发现你

DNS 信息

用户访问一个网站之前，通常需要进行 DNS 查询。传统 DNS 基于 UDP/53（RFC 1035），整个查询报文（包括你问的域名 www.example.com）都是明文的，而且明文程度比 HTTPS 的 SNI 还彻底——网络侧只需抓一条 UDP 包就能直接看到你查询的域名，连 TLS 握手都不用分析。这是校园网/企业网最早、最便宜、也最常用的网站监控手段之一。

现代系统中出现了多种 DNS 加密方案，它们的区别在于"加密套了一层什么协议"：

注意一个关键区别：DoT 用独立的 853 端口，管理员只要把 853 一封，就逼你回落到明文 DNS；DoH 走的是 443，和普通网页流量混在一起，很难在不误伤正常 HTTPS 的前提下单独拦截。这也是为什么浏览器（Chrome/Firefox）默认启用的是 DoH 而不是 DoT——隐蔽性更好。但即便如此，DoH 只解决了"DNS 查询内容被偷看"的问题，解决不了后续 TLS 握手里 SNI 明文泄露的问题（那是另一条独立路径，要靠前面说的 ECH）。

但是同样需要注意：DNS 加密解决的是「DNS 查询内容的保密」，而不是让用户身份、设备、IP 地址、外部连接、流量全部消失。而且很多校园网/企业网会强制把所有出网的 53 端口流量重定向到内部 DNS 服务器（DNS 劫持/透明代理），此时你即便配了加密 DNS，也可能因为出口被劫持而失败，被迫回落明文。

SSL/TLS 解密

在某些受组织统一管理的企业终端环境中，还可能部署 SSL Inspection / TLS Inspection / HTTPS Decryption。它本质上是一个中间人攻击（MITM）的合法化版本：安全网关在客户端和真实服务器之间插入自己，拆成两条独立的 TLS 连接。

工作原理是这样——正常情况下，客户端验证服务器证书有一条信任链：服务器证书 → 中间 CA → 根 CA → 系统信任的根证书库。而 SSL 解密的关键在于，安全网关持有一张由企业内部根 CA签发的签发能力，于是它对每个被解密的站点实时签发一张"看起来合法"的证书：

1
2
3
4
5
6
7
8

【正常情况】
客户端 ──────TLS（服务器真证书，由 Let's Encrypt 签发）──────> github.com

【SSL 解密情况】
                                                          ┌─ TLS #1（网关冒充 github.com，
客户端 ──TLS（网关实时伪造的证书，由企业根 CA 签发）──> 安全网关 │  用企业根 CA 实时签发证书）
                                                          └─ TLS #2（网关作为客户端，连真实 github.com）
                                                                  安全网关 ──TLS──> github.com

要让这套机制生效，前提是客户端必须预先信任企业根 CA——也就是管理员通过 MDM/组策略把企业根证书推到终端的系统证书库里。一旦终端信任了这个根 CA，网关签出来的"假证书"在浏览器眼里就和真证书一样合法，不会有任何证书警告。这就是为什么所有讨论 SSL 解密的文档都强调"必须在受管终端上部署根证书"——这是它生效的唯一前提，同时也是它只能用于企业受管终端、不能用在 BYOD 或访客身上的根本原因（你不能逼访客装你的根证书）。

深信服 AC 官方文档中同样提供 SSL 解密策略相关配置，官方支持案例中也提到了终端根证书部署与中间人解密场景。这通常服务于恶意软件检测、内容安全、URL 控制、数据泄露防护、安全审计。

证书透明度（Certificate Transparency, CT） 是对抗这类伪造证书的机制之一：所有公网可信 CA 签发的证书都必须提交到公开的 CT 日志，任何人都可以查到"某域名在何时被谁签发了证书"。但企业内部 CA 签发的证书（用于 SSL 解密的）不在公网 CT 日志里，所以如果你的浏览器启用了 CT 强制策略（Expect-CT）访问的是公网服务，理论上能发现证书来源异常——但这属于深度防御细节，多数部署不会触发。

因此在企业受管终端环境中，HTTPS 也不能绝对理解成「任何安全设备都无法分析」。当然，这类能力涉及组织制度、隐私、安全、合规、性能、证书管理等多方面问题，不能简单理解为"网络管理员可以任意读取所有 HTTPS 内容"。

十二、校园网真正强大的地方其实是"身份关联"

讨论校园网监控时，很多人把注意力全部放在能不能破解 HTTPS 或者能不能识别 VPN，但实际上校园网非常重要的一项能力并不是破解加密，而是身份关联：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

学号
 │
Portal / 802.1X认证
 │
RADIUS
 │
MAC地址
 │
IP地址
 │
接入交换机 / AP
 │
网络连接日志

最终可能形成：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

账号：Student001
         │
MAC：AA-BB-CC-DD-EE-FF
         │
IP：10.10.20.35
         │
接入位置：Dormitory-AP03（备注：宿舍楼X号X楼XXX室）
         │
上线时间：20:31
         │
网络连接日志

这个时候即使应用数据本身已经加密，但是"身份、设备、位置、时间、流量、连接"之间仍然可以形成关联。这也正好解释了为什么 Authentication、Authorization、Accounting 在校园网和企业网中如此重要。

NAT 也不等于校园网无法区分用户

大型校园网络通常会有大量用户共享少量公网地址：

1
2
3

Student A ─┐
Student B ─┼── NAT Device or Service ── Public IP ── Internet
Student C ─┘

从互联网服务器的角度，Student A、B、C 可能看起来都来自同一个公网 IP。但是校园网络内部仍然可能掌握内网 IP、内网端口、公网 IP、公网端口、时间，再结合 AAA 日志、DHCP 日志、认证日志、交换机信息、无线控制器日志，就可能继续进行用户关联。这部分以前丢给设备进行长时间算法用户画像关联就好，现在只要部署单位愿意联网，丢给大模型只会更快。

所以「多人共享公网 IP」并不意味着「校园网络内部无法区分用户」。

十三、那么管理员究竟能看到多少

这个问题没有一个适用于所有校园网和企业网的统一答案，因为不同网络部署的安全能力可能完全不同——万一你的学校/单位愿意花钱部署顶级设备（比如研究院、军工、强保密单位），审计相关的功能只会更多。

一个简单网络可能只有：Portal、NAT、防火墙、基础日志。 而一个大型校园网可能部署：802.1X、Portal、RADIUS、NAC、AC、防火墙、IDS/IPS、DNS 日志、NetFlow、上网行为管理、集中日志平台。 企业环境还可能进一步加入：EDR、MDM、DLP、SIEM、零信任、终端 Agent。

因此真正专业的问题并不是「校园网能不能看到我的上网行为」，而是「当前网络中有哪些设备，分别位于什么位置，各自能够获得哪些信息」：

1
2
3
4
5
6
7

802.1X / Portal       → "你是谁"
DHCP                  → "这个时间哪个IP分配给了哪个终端"
交换机 / WLAN         → "你从哪里接入"
AAA Accounting        → "什么时候上线、什么时候下线、用了多少资源"
防火墙 / NAT          → "建立了哪些网络连接"
行为管理AC            → "这些连接对应什么应用和网络行为"
日志平台              → "如何把所有日志关联起来"

十四、为什么不应该把隐私保护和绕过网络安全策略混为一谈

个人保护自己的网络通信当然是合理的安全需求，例如使用 HTTPS、避免公共 Wi-Fi 明文窃听、保护账号密码、使用可信加密通信、保持操作系统及时更新、启用多因素认证，这些都属于正常的网络安全实践。

但问题是：保护自己的通信内容，与故意规避组织部署的准入控制或安全审计，这是两个问题。在校园、园区、企业单位中，校园网和企业网络通常属于组织管理的基础设施，网络管理策略可能同时承担账号安全、终端安全、恶意流量检测、数据泄露防护、带宽管理、故障排查、安全事件溯源、合规要求。

因此从网络工程师的角度，更值得研究的是：

• 这个系统在哪一层工作
• 它能够看到什么信息
• 它依赖什么信息进行识别
• 哪些信息经过了加密
• 哪些信息仍然属于明文元数据
• 身份是如何关联到 IP 的
• 行为日志又是如何关联到身份的

毕竟说难听点，你也不希望隔壁计算机系/云计算系或者任何系都可能会有的脚本小子，天天通过无隔离、无准入、无审计的校园网视奸你刷 L 站吧。