长沙理工大学校园网共享观察与方案
前言
时隔几个月，CSUST的网络系统又经过了几次更新。由于情况愈发离谱，因此以后只提供情况观察和记录，不再尝试给出解决方案。如果实在需要的话，本文结尾会有一个简单方法，但显然不会是免费的。
现在的校园网现状
其实没啥大变化，以前用的portal认证、IP-MAC-账号的绑定规则等等都是一样的。不同之处在这里：
图：学校防火墙主动屏蔽了我的网络长达30分钟
没错，新增了一个完善的共享锁定页面，让你知道自己为什么用不了网络了。
最初事件经过
10月23日晚上约10点50，我正在用手机看视频，忽然手机提示我网络不可用。
开始排查问题：
1.用路由器长时间联网本身不稳定，偶尔掉线是正常现象；但在重连、重启路由器后仍然失效。
2.虽然做了80端口加密代理，但在偶然情况下也会触发检测；于是用手机登录校园网、路由器再重新登录，仍然无法解决。
3.手机重新连接校园网时弹出上图，告知检测到共享行为。
一些细节：
1.今晚8点半左右我临时关闭了加密代理，不过在10点左右重新启用。
2.在检测发生时，我正在使用SS机场看YouTube视频；理论上来说这里流量不仅不是80端口、不是http流量，其数据包更是完整地被SS加密过，那这个检测事件就十分可疑了。
3.这个检测的跳转网页是校内未知服务器的页面，而不是认证服务器页面。
事后：我做了一些更改，并且持续监控网络情况至11点50以后。
1.我将加密代理的端口从80改为全部，并且启用了UDP转发，以便所有流量均经加密穿透。
2.按以前校友博客文章的方法加入防火墙规则，屏蔽侵入式检测。
3.关闭路由器在8080端口上允许外网访问的功能，取消路由器响应ping的能力。
直到目前，即使我换用2部手机持续使用也没有被再次检测。
一些猜想：
1.由于最可疑的地方是检测发生时我的网络行为，此时我的流量仅有2个：一是服务器正在使用百度网盘（大概率没有在下载文件，而仅是被百度割韭菜当PCDN在上传），二是手机通过SS机场看油管视频。我的第一反应就是学校防火墙（School FireWall，以下简称SFW）能够检测到SS流量并进行屏蔽。这不是什么新鲜技术，SS是最早一批绕过GFW的协议，其包特征很明显，利用被动的熵检测和主动重放攻击就能快速检测出SS流量和服务器。但是当我将全部流量均通过SS加密穿透SFW时，至少50分钟内没有受到第二次屏蔽。
2.随后考虑，使用443端口的https流量虽然经过了TLS加密，但其初次握手过程通常是明文，且TLS数据包本身包含有明文信息。因此，如果SFW今晚额外部署了针对https流量的检测规则，那么我的方案显然是完全无法应付。
3.由于我同时做了很多激进的防御措施，其他检测方法也可能出现。例如任何连接到校园网的人都可以访问我的IP、8080端口，然后就是一个登录页面，几乎可以立即判断这是一台路由器而非普通设备。
4.最后想想，还有一种可能是DNS探测。这几天chrome一直在某个网站上弹窗提醒我网址可能被篡改，网上搜出来的信息大多指向DNS污染；但我用的是公共DNS，同时路由器上的SS也自带了dnsproxy防止污染，所以这事有点奇怪。但是现在想来，我并没有使用任何DoH和DoT，所有DNS请求都是明文发送，这样只要抓个包就能快速分析出源设备的类型是否单一。我也是在配置的时候考虑到这一点的可能性，因此为SS启用了UDP转发和DNS重定向。
（补充：刚才想起来，SS里的UDP转发默认不转发53端口以避免DNS失效，其实也就意味着我的DNS目前仍然是原状态；但这么久了都没有发生检测事件，说明这种方法要么不可行要么没有配置）
后续观察和更新
最近几天，又遇到多次屏蔽问题，并在过程中总结了一些经验和应对措施。
以下内容完全由个人经验总结而成，不保证准确性。
可以确定的是，检测的方式不止80端口的http报文UA字段一种了。目前我认为存在的检测规则包括：80端口报文UA，443端口https报文，UDP检测（webRTC是首要怀疑目标），TTL检测。
- 在80端口的检测已经是老生常谈了，不多说；用个修改UA的路由器插件就能解决。
- 在443端口传输的https报文都是加密的，我猜测可能是通过目标服务器判断的；我不知道UA在不在明文内容里，但https流量本身不会完全加密整个数据包，至少目标服务器地址不在https加密内容中；因此假如说一台设备同时连接了Windows和vivo的保活服务器，则可以证明共享行为。
- UDP检测，这个源于我两次使用永劫无间的语音通话功能时被屏蔽的经验。同样的，我不确定这个游戏是否使用webRTC传输语音数据，但UDP检测应该是存在的。不过应该与DNS无关。
- TTL检测，这个是最近几天新（重新）增加的。由于安卓和Windows设备的默认TTL值不同，因此检测这个可以肯定地判断共享行为。之前一直没有这个问题的，是最近几天经过多次尝试后发现新增的。
我自己的解决方法
前三个没啥好办法解决，我的做法是使用一台位于深圳的公网服务器来做代理，将内网流量加密后经代理上网。由于我的电脑是需要首先保证网络性能的设备，因此路由器中设置电脑的MAC绕过代理。
具体步骤如下：
- 参考https://www.librehat.com/three-minutes-to-set-up-shadowsocks-server-on-windows/搭建好SS服务器。
- 按图配置好路由器上的SS：
按照服务端配置来设置SS，加密方式建议使用chacha20，这个是我测试下来在稳定性和速度之间完美平衡的方式。
转发端口建议全部设置，UDP转发里手动填写所有53流量的原因是提高性能。由于国内很多网站会有CDN，并且根据查询DNS的位置返回最近的CDN地址，可能会导致流量从湖南流向深圳再转发回湖南，进而大幅影响性能。这样转发DNS流量后，网络速度会有部分提升。
（tips：米家游戏是非常毒瘤的存在，如果要下载原神，那么无论怎么设置总有大概率是只能跑到3M/s的速度，这个没办法解决，只能暂时关闭SS或者配置绕过规则，只需要确保这段时间内其他设备不联网即可；）
在下面的LAN转发中填写需要绕过SS（不经过代理）的MAC地址。使用IP也可行，但需要绑定好静态IP，并且IP控制的性能似乎比MAC差一点。
全部完成后应用，启用SS即可。
问题
这个方法目前唯一的问题是，路由器每次重启后会先联网再启动SS，这两个动作之间间隔时间较长，在这个2-3分钟的窗口期内容易被检测和封禁（尤其是晚高峰时段，我的路由器可能固件有点不兼容经常自己重启，如果正好是晚上那么大概率立刻被封）
结尾
没有结尾，这个对抗会一直持续下去，直到我离开学校。