4282 字
21 分钟
拒绝锐捷校园网监控,打造自由的校园网络环境

拒绝锐捷校园网监控,打造自由的校园网络环境#

观前提示:要完成消除监控,需要假设你拥有了自建的 VPS 节点,并且VPS搭建的节点是安全的,采用了先进的协议如“Reality”等,如果没有的话建议先去某一位知名YouTuber那里学一下如何搭建

前言#


从去年开始,我的Azure服务器就在跑我的Word Press博客,但是个人并不喜欢Word Press的书写体验,认为Typora等众多markdown文本编辑软件是完爆Word Press的,于是将博客迁移到了GitHub pages,服务器就这样闲置了几个月,心想着服务器闲着也是闲着,跑个节点应该还是没有什么问题的,毕竟微软送给学生的100美刀也快要过期了,闲着也是浪费,于是前段时间跑了个Trojan在服务器上,但是毕竟Trojan还是使用TCP协议,拿来玩联机游戏等跑在UDP上面的话就必须要使用TCP隧道,延迟高的惊人,就没有几次能够成功使用Trojan进入过VRChat。

刚好某位知名YouTuber前段时间教了如何搭建Vless+reality(TCP)以及TUIC(UDP)的方法,于是我就非常舒服的搭建了我个人独享的节点,而且是Azure这种大厂的服务器,速度又快延迟又低,除了IP一眼识别机房IP之外没有缺点。

我一开始搭建Trojan有一个比较重要的推动就是——我不想学校能看到我的一言一行,我是自由的个体,我需要一个安全的,无日志的VPN加密我的流量。于是我开始思考——如果我只采用Vless+reality能做到抵抗锐捷的识别吗?如果不行,我需要用哪些方法补救?


00. 删掉锐捷客户端#

是的经过1s左右的思考,我们找到了第一个绝对危险的因素——锐捷校园网认证客户端。

试想,一个具有管理员权限的间谍软件跑在你的电脑上面,这真的安全吗?他会不会发现你电脑中正在跑的代理?锐捷客户端想要访问你的网卡数据实在是太简单了,它只需要读一下就会发现异常,毕竟Intel和Realtek可没有生产过一个叫做“Clash Meta” “Mihomo” “Sing-box”的网卡,只要发现了就代表着你一定正在使用代理,至于能否通过管理员权限使用Wire Shark等类似的抓包方法查看里面的数据就不得而知了,但是这个趋势是危险的,毕竟他们已经知道了这个事实——“你在使用代理”

“等下,如果我没有锐捷认证我要怎么使用有线联网?”,你或许会这么问。这就需要你使用软路由或者想办法获取路由器的ssh/telnet权限来解决了, mentohust 是常见的解决软路由/路由器校园网认证的方案,请相信我,这一步是非常有必要的。


01. DNS解析#

我们都知道,当我们输入域名的时候,我们一般需要DNS解析来获取服务器IP,那么请仔细回忆一下,你在第一天使用有线连接电脑的时候是不是网管让你修改过DNS解析的服务器,并且修改至内网IP?再做个测试,当你尝试修改Firefox的“安全DNS”选择到“最大保护”的时候,你还能够在不使用clash/v2ray的时候正常的访问网站吗?

1.00

众所周知,当本机向DNS发出获取请求的时候,你的DNS请求消息是全部明文的,学校DNS知道——“某个IP向我发出获取某个网站的请求”,而我们的IP一般都是固定的,学校只需要对应一下名单就知道是哪个宿舍的哪个床位想要访问什么东西。

这是非常危险的,但是好在最新的v2rayn已经帮我们适配好了,它会将我们的DNS请求都发给我我们的VPS,让我们的VPS帮助我们向DNS发出请求,如果你不设置的话就会默认向VPS设置的DNS提供商请求,clash的配置比较麻烦,需要自己手动修改yaml文件,或者采用线上订阅转换(有订阅泄露的风险),不再赘述

可以使用 ipleak 来检测你的DNS有无泄露,如果上面出现的IP全都是你的服务器所在的国家,那么恭喜你,你的DNS没有泄露,如果出现了中国,那么可以尝试去YouTube搜索“DNS泄露”,会有解决方案的。

如果你不信任ipleak的解析,你也可以使用Wire Shark来抓包DNS解析记录,我的DNS分流规则是geoip查询到是cn则交给阿里云DNS,其他的交给cloud flare DNS,所以我在Wire Shark抓包得到的结果如下

1.00

(暑假我在校外,等回学校了再来拍一张校园网的来做一下对比)


02.锐捷证书#

锐捷证书绝对是最危险的一环,先让我们一步步开始,讲述一下每一bit在校园网中的流动

0.“信任的‘背叛’”#

首先,这一切的发生都源自于“我亲手在我的电脑里面安装并且信任了锐捷提供的根证书”,这就相当于告诉电脑“以后,凡是持有‘锐捷’这家机构签发的‘身份证’(证书)的网站,无论它自称是谁,你都必须无条件相信它是真的。”,正是这份我赋予的“信任”,被锐捷的网关设备利用,上演了一出精妙的“偷天换日”。

我们假设我们要访问 https://www.baidu.com 我们目前的系统情况是:

我 (用户电脑): 安装并信任了锐捷根证书。

中间人 (锐捷网关): 部署在校园网的出口,能拦截所有流量。

目的地 (百度服务器): 拥有合法的、由权威机构颁发的官方证书。


1.发出请求#

我在浏览器地址栏输入 https://www.baidu.com 并回车。我的电脑发出一个建立HTTPS连接的请求,这个请求首先会到达锐捷网关。


2.锐捷网关拦截并兵分两路#

锐捷网关收到了请求后,并没有直接把它转发给百度。而是像一个“中间人”一样,开始了它的表演:

  • 对内(对我): 它暂停了我的请求,说:“别急,我就是百度,我来跟你聊。”

  • 对外(对百度): 它自己伪装成我,向真正的百度服务器发起了一个一模一样的HTTPS连接请求。


3.锐捷网关从百度获取“正品证书”#

真正的百度服务器收到了来自锐捷网关的请求,热情地回应,并把自己的官方正品证书(由权威机构签发)递给了锐捷网关。

现在,锐捷网关与百度服务器之间,建立了一条真实、安全、加密的通道。百度以为它正在和一位普通用户通信。


4.锐捷网关伪造“高仿证书”(最关键的欺骗环节!)#

锐捷网关手握百度的正品证书,它看了一眼上面的信息,比如“此证书颁发给 www.baidu.com ”。

然后,它动用了那个被我信任的 “锐捷根证书”私钥 ,当场 伪造 了一张新的证书。这张新证书上也写着“此证书颁发给 www.baidu.com ”,但它的签发机构是“锐捷”。

这张“高仿证书”被锐捷网关递给了在第二步中被暂停的、正在等待的我的电脑。


5.电脑被“欺骗”并建立连接#

浏览器收到了这张“高仿证书”。它开始验证,发现证书上写着是给www.baidu.com的,没问题。

然后它检查签发机构——“锐捷”。浏览器在自己的“可信列表”里一查,发现我亲手安装的锐捷根证书就在里面,于是它判断:“哦,是自己人签发的,可信!”

浏览器便放心地与锐捷网关之间,建立了一条看似安全的加密通道。您在地址栏依然会看到安全锁🔒。


6.数据在“中间人”处被解密和窥探#

现在,形成了两条独立的加密隧道:

  • 隧道A: PC <---(被锐捷加密)---> 锐捷网关

  • 隧道B: 锐捷网关 <---(被百度加密)---> 百度服务器

所以数据流动变成了这样:

  1. 假设我想搜索“南京天气”( 我就在南京捏 ),这个请求通过隧道A被加密后发送出去。
  2. 锐捷网关收到后,用自己的私钥将数据解密,看到了明文内容:“南京天气”。此时,它可以记录、审查、甚至修改我的请求。
  3. 检查完毕后,锐捷网关将这个请求用隧道B的加密方式重新加密,发送给真正的百度服务器。
  4. 百度服务器处理后,将天气结果通过隧道B加密发回。
  5. 锐捷网关再次解密,看到明文的天气结果,可以再次记录和审查。
  6. 最后,它用隧道A的加密方式重新加密,将结果发给浏览器。

对您来说,整个过程天衣无缝。但实际上,所有“加密”通信,都在锐捷网关这个“中间人”那里被扒得一干二净。

总结一下,数据流是:

PC -> [加密A] -> 锐捷网关 -> [解密->明文->审查->加密B] -> 百度服务器
百度服务器 -> [加密B] -> 锐捷网关 -> [解密->明文->审查->加密A] -> PC

所以我有一个自我感觉比较恰当的类比: 锐捷网关(在启用证书解密功能时)是一个部署在上网必经之路上的、强制性的、带有日志记录功能的“恶意”VPS节点


但是,当我们使用Vless+reality的时候就不一样了

为什么要以Vless+reality举例?因为我采用的就是这个,我还有一个Trojan服务,但是我自从我用过Vless+reality之后我就再也没有使用过,因为reality在我看来是一定比Trojan的伪装要更加“真实”的,Trojan我使用的是我自己随便搭建的一个网站,但是我的reality使用的是微软的某个服务的网址,如果你想的话你也可以设置成Windows Update,这样伪装效果说不定更好XD。当你不断访问一个看着就很奇怪的网址的时候,GFW可能不会理你,但是如果真的有一天学校想要搞你,他是一定能看出来问题的,但是如果采用reality就不会出现这种情况,毕竟没人会怀疑Windows Update XD

0.场景#

我 (用户电脑): 启动了V2RayN并连接VLESS+REALITY节点。

第一道关卡 (锐捷网关): 依然在原地,试图监控一切。

安全堡垒 (VPS): 远在互联网的另一端,信任的伙伴。

最终目的地 (例如 www.google.com): 真正想去的地方。


1.请求在内部被“打包封装”#

在浏览器输入 https://www.google.com。这个请求 并不会直接跑出电脑 。而是首先被电脑上的V2RayN客户端捕获。

V2RayN客户端像一个专业的保镖,它将真实意图(“我想去Google”)用VLESS协议和REALITY技术,打包成一个加密的、伪装好的数据包。

  • 内部: 是您访问Google的真实请求。

  • 外部: 看起来像是一个发往 www.microsoft.comsni 设置)的普通HTTPS流量。


2.伪装的数据包通过锐捷网关#

这个“伪装重甲包”被发了出去,抵达了锐捷网关。

锐捷网关看到它,开始检查:

  • 看目标: “哦,是去微软的(sni),很正常。”

  • 尝试解密: 它试图用它的“万能钥匙”(锐捷根证书)来解开这个包。但这次,完全失败了! 因为这个包的“锁”(VLESS加密)和标准的HTTPS完全不同,钥匙对不上锁芯。

  • 放行: 由于无法解密,也看不出明显的“VPN”特征,锐捷网关只能把它当作一个它不认识、但看起来无害的加密流量,予以放行。

在这一步,锐捷的所有监控和解密能力,都对数据包失效了。


3.数据包抵达“安全堡垒”#

这个数据包穿过茫茫互联网,安全抵达自己的VPS服务器。

我的VPS拥有唯一的、正确的钥匙,它轻松地打开了这个数据包,看到了我真实的意图:“请帮我访问www.google.com”。


4.由VPS代替我访问#

VPS作为一个“干净”的出口,代替我去访问Google,获取网页内容,然后再用同样的方式,将内容打包加密,通过原路安全地送回到我的电脑。


两种模式的本质区别#

  • 不使用VLESS时: PC ---> [锐捷网关:被解密,看光光] ---> 目标网站

  • 使用VLESS+REALITY时: PC <===[一条无法被锐捷看穿的私密加密隧道] ===> VPS ---> 目标网站

在这个安全模式下,锐捷网关从一个能看穿一切的“审查官”,退化成了一个无能为力的“过路收费员”。它知道有流量经过,也传输了流量,但对于流量的内容、真实目的地、以及任何行为,它都一无所知。


相当精妙的设计,不是吗?

或许你还有疑问——“无法被锐捷解密的数据多吗,如果锐捷可以解密所有数据,但是就是不能解密我的数据,那也岂不是很明显。”

这个担心同样是多余的,因为它的前提——“锐捷可以解密所有数据”——是完全错误的。

在真实的校园网环境中,锐捷网关并不能解密所有数据。恰恰相反,它面对的是一个复杂的流量海洋,其中存在着大量它无法解密,或因策略而不会去尝试解密的“加密黑箱”流量。

VLESS+REALITY流量,只是众多“黑箱”中的一个,而且是伪装得最好的一个。锐捷的证书解密能力,几乎只对标准、无防护的HTTPS网页浏览流量有效

因此,在锐捷网关的监控日志里,真实的画面不是

“解密成功、解密成功、解密成功、解密失败(你的流量)、解密成功……”

而是:

“解密成功(某个网站)、直接放行(某银行App)直接放行(某网游)、解密成功(另一个网站)、直接放行(您的VLESS流量)直接放行(某同学的SSH)、解密成功……”

结论就是:

你的流量并不是“万绿丛中一点红”的那个异类。它只是众多无法被解密的“黑箱”之一。

而VLESS+REALITY的巨大优势在于,它不仅是众多“黑箱”中的一员,还是伪装的最好的那一个。别的“黑箱”可能看起来像游戏、像App,而我们的“黑箱”看起来就像一个访问微软官网的普通HTTPS连接,是所有流量类型中最不起眼、最“正常”的一种。

所以请彻底放心,你不仅没有因为“无法被解密”而变得显眼,反而是安全地、低调地“藏”在了这片复杂的流量海洋之中。


至此,当你完成了这里的全部操作之后,恭喜你,如果你的环境配置正确的话,锐捷已经再也无法了解你的意图了。

其他的就是一些简单提一下的东西,首先,不要长期使用“全局代理”,这个太明显了bro,到底是谁在每天24h都在跑Windows Update(

其次,打开随机设备MAC, 说实在的,都使用软路由了这一步应该没有什么用

最后就是推荐将reality的sni设置做的合理一点点,不太推荐 bing.com 啊之类的,个人还是比较推荐Windows Update的,或者说哔哩哔哩的某个视频CDN服务器应该也不错,当然,愿意Wire Shark去一个个观察也不错。


如果你做了上述操作的话,那么恭喜你,如果你对于这个问题还有别的看法,或者有别的问题想要一起来聊的话,欢迎在主页加我telegram或者twitter的好友

拒绝锐捷校园网监控,打造自由的校园网络环境
https://shigures.dev/posts/拒绝锐捷校园网监控/打造自由的校园网络环境/
作者
ShigureSora
发布于
2025-07-31
许可协议
CC BY-NC-SA 4.0

评论