感謝國家教育部和相關部門的大力支持下,校園網的發展從一人一號,已經發展成了一號一終端的情況
本文件有較大更新,此文件按照銳捷官方說明編寫,感謝 SunBK 和 Rusyneir 大佬幫助
前言#
雖然說我們這邊的情況是百兆年費 180,不過有一說一,一號一終端的設備情況下實在是過於麻煩,如果通過電腦開熱點的方式來解決此問題,就會出現被封禁 15 分鐘黑名單的情況,屬實是過於難受了。不知道哪個沒🐴的人想出來的
不過根據校內的情況來說,貌似除了某寶購買校園網版路由器的使用情況外 (又貴又麻煩,質量還低),貌似沒有對付校園網對於共享熱點封禁的較好解決方案。道高一尺魔高一丈,上有政策下有對策,於是根據我的實戰經驗,分析了本校可行的共享實驗方案
首先呢,我先掛上我們學校的校園網認證驗證頁面:
如果你們校園網的認證界面和我們這邊界面一致,恭喜你,這是他媽的銳捷校園網認證服務
如果按照正常的方式去利用電腦熱點來躲開校園網的限制:
原理#
校園網檢測,無非也就是判斷基於 NAT 子網共享的情況,檢測一個 IP 下對於多個設備的識別特徵能力
根據伺服器算力的情況,校園網的檢測應該是根據心跳事件進行隨機抽取檢查數據包的,並非即時反饋:
有目前兩種反饋情況:
一種是基於 UA
UA 中帶有操作系統名,如果同時出現多個,那麼就能判斷出一個設備聯網共享給多個設備使用。
校園網是隨機抽查部分用戶檢測,只要檢測到一次,那麼後面就會專門盯著你的帳號。
分析上網特徵也是要消耗伺服器資源的,對全部上網用戶同時檢測伺服器負載嚴重。校園網經常炸的原因
一些人在使用模擬器時也可能會被檢測到代理上網,原理很簡單。你登錄的電腦把網絡共享給安卓模擬器使用,兩邊的網絡服務通信時,UA 可能不一樣,特徵和使用路由器很像,校園網可能會被識別到。
另一種是不明顯但已經被用於技術上實現的技術
DPI (Deep Packet Inspection) 深度包檢測技術
目前做的比較好的有 --> 深信服
根據一部分高校對於校園網共享的實戰,已經總結出下列的情況:
- 基於 IPv4 數據包包頭內的 TTL 字段的檢測
- 基於 HTTP 數據包請求頭內的 User-Agent 字段的檢測
- DPI (Deep Packet Inspection) 的深度包檢測技術
- 基於 IPv4 數據包包頭內的 Identification 字段的檢測
- 基於網絡協議棧時鐘偏移的檢測技術
- Flash Cookie 檢測技術
根據官方文檔證實,已經確定使用 DPI 技術 + UA 檢測手段
基於 IPv4 數據包包頭內的 TTL 字段的檢測#
存活時間(Time To Live,TTL),指一個數據包在經過一個路由器時,可傳遞的最長距離(躍點數)。
每當數據包經過一個路由器時,其存活次數就會被減一。當其存活次數為 0 時,路由器便會取消該數據包轉發,IP 網絡的話,會向原數據包的發出者發送一個 ICMP
TTL 數據包以告知躍點數超限。其設計目的是防止數據包因不正確的路由表等原因造成的無限循環而無法送達及耗盡網絡資源。
這是一個比較有效且合理的檢測技術,IPv4 數據包下存在 TTL(Time To Live)這一字段,數據包每經過一個路由器(即經過一個網段),該 TTL 值就會減一。
不同的操作系統的默認 TTL 值是不同的,Windows 是 128,macOS/iOS、Linux 是 64。
因此如果我們自己接入路由器到校園網,我們的通過路由器的數據包會變為 127 或 63,一旦校園網抓包檢測到這種數據包 TTL 不是 128 或 64,就會判定為用戶接入了路由器。
基於 HTTP 數據包請求頭內的 User-Agent 字段的檢測#
HTTP 數據包請求頭存在一個叫做 User-Agent 的字段,該字段通常能夠標識出操作系統類型,例如:
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML,
like Gecko) Chrome/89.0.4389.72 Safari/537.36 Edg/89.0.774.45Mozilla/5.0 (iPad; U; CPU OS 3_2_1 like Mac OS X; en-us)
AppleWebKit/531.21.10 (KHTML, like Gecko) Mobile/7B405
校園網會通過多次抓包檢測此字段,若發現同時出現例如 Windows NT 10.0 iPad 的字段,則判定存在多設備上網。
DPI (Deep Packet Inspection) 深度包檢測技術#
這個檢測方案比較先進,檢測系統會抓包分析應用層的流量,根據不同應用程序的數據包的特徵值來判斷出是否存在多設備上網。
具體可參考:基於 dpi 技術的網絡共享設備檢測方法及系統
此種方式已確認在銳捷相關設備上應用,當由於此項功能極耗費性能,因此有些學校可能不會開啟此項功能。
基於 IPv4 數據包包頭內的 Identification 字段的檢測#
IP 報文首部存在一個叫做 Identification 的字段,此字段用來唯一標示一個 IP 報文,在實際的應用中通常把它當做一個計數器,一台主機依次發送的 IP 數據包內的 Identification 字段會對應的依次遞增,同一時間段內,而不同設備的 Identification 字段的遞增區間一般是不同的,因此校園網可以根據一段時間內遞增區間的不同判斷出是否存在多設備共享上網。
具體可以參考此專利:基於 ipid 和概率統計模型的 nat 主機個數檢測方法
不過經過我的抓包分析,Windows 的 TCP/IP 協議棧對 Identification 字段的實現是遞增,而 iOS 的實現是保持全 0,因此校園網是否使用了該檢測機制有待商榷。
基於網絡協議棧時鐘偏移的檢測技術#
不同主機物理時鐘偏移不同,網絡協議棧時鐘與物理時鐘存在對應關係,不同主機發送報文頻率與時鐘存在統計對應關係,通過特定的頻譜分析算法,發現不同的網絡時鐘偏移來確定不同主機。
具體可以參考此專利:一種基於時鐘偏移的加密流量共享檢測方法與裝置
此種方式具有一定的實驗性,因此我不認為此種方式投入了商用。
Flash Cookie 檢測技術#
Flash Cookie 會記錄用戶在訪問 Flash 網頁的時候保留的信息,只要當用戶打開瀏覽器去上網,那麼就能被 AC 記錄到 Flash Cookie 的特徵值,由於 Flash Cookie 不容易被清除,而且具有針對每個用戶具有唯一,並且支持跨瀏覽器,所以被用於做防共享檢測。
(經證實,本校使用了此類技術)
根據判斷來說,銳捷校園網會使用掃描全局端口 (重點 80 和 8080 非加密流量) + UA 審查 + DPI Wechat UnionID 加密方案
個人認為對 80 和 8080 端口進行加密是較好的選擇方案
根據銳捷的文檔,確定了此項目會使用 UA 檢測手段 + 微信 UnionID 方式掃描,對症下藥
方案#
臨時解決方案 (ADB Revese)#
很抱歉,此類方法僅適合安卓 | 鴻蒙平台的設備,不支持 Apple 下的 ipad & iphone 設備
這類方法是使用了Gnirehtet項目,可以通過 adb 的方式以隧道網絡溝通的方式實現和電腦的連接
因為這種連接是自帶加密屬性的,所以可以用作於臨時方案
這邊我們使用晨鐘醬的 GUI 版本 (有線上網器) https://jamcz.com/wirenet/
貌似不需要多介紹的,只需要有數據線連接電腦,從開發者工具打開 adb 調試即可使用
不過值得注意的是,在一層 NAT 環境下,仍然會有一定幾率抓到
路由器配置方案 (OpenWRT + Clash)#
這是目前解決校園網不允許共享的路由器解決方案,不過這個方案僅可使用同號微信終端 (不同的號會被 DPI 抓到)
首先,你需要一台合適的路由器來安裝我們所需的配置,這邊使用的網件 WNDR 4300v2,在某魚上只需要 50r 就可以收到一個成色不錯的樣式。如果預算較低可以選擇 k2p,k2p 在固件上折騰的人數較多,有較多的教程可以參考。
同時,你需要一個可以用於加密的伺服器,來幫助你加密未加密的方案,這邊需要自備 x 自己摸索
[collapse status="false" title="Hide"] 找一下國內的免流機場一般便宜且流量大 [/collapse]
↑ ↑ ↑
請在此處查找適合你路由器的框架,部分路由器不支持直接安裝,如果必要,請按照 “xxx 安裝 Openwrt” 的方式搜索安裝
[scode type="yellow"] 請注意,麻煩試著查找您的路由器的不死固件 (Breed),這能保護你的路由器不會因為一些誤操作立刻變成一塊磚頭 | 雖然不是必選,不過為了安全建議優先刷入[/scode]
部分路由器可能需要進行 Factory+Sysupgrade 的方式安裝
Openwrt 上的調試#
解決檢測 TTL 問題#
方法很簡單:修改 TTL 為固定值
通過 SSH 的方式連入後台,輸入
# 在OpenWrt路由器上安裝必要的軟件包
opkg update && opkg install iptables-mod-ipopt kmod-ipt-ipopt
同時,在防火牆的自定義設置中,配置
iptables -t mangle -A POSTROUTING -j TTL --ttl-set 64
這一步保存後即可完成
UA 檢測 (Clash 加密手段)#
這一步就是需要使用 Clash 的方法來處理
https://github.com/juewuy/ShellClash/blob/master/README_CN.md
配置好後,通過 sftp 的方式進入文件後台或者事先配置好 (或者按照你喜歡的方式只要能摸到後台文件就行)
在已經配置好的 config 文件裡面在 Rule 第一條上加入如下規則
- DST-PORT,80,Proxy
- DST-PORT,8080,Proxy
# WeChat & QQ
- DST-PORT,80,Proxy
- DST-PORT,5222,Proxy
- DST-PORT,5223,Proxy
- DST-PORT,5228,Proxy
- DST-PORT,8000,Proxy # UDP
- DST-PORT,8001,Proxy # UDP
- DST-PORT,8080,Proxy
- DST-PORT,14000,Proxy
這邊的 Proxy 是你的加密伺服器,也就是你的 clash 服務,請按照情況進行配置
[scode type="yellow"] 如果配置成功的話,你的非加密接口應該是走的內核網絡,實現了加密 [/scode]
基於網絡協議棧時鐘偏移的檢測技術#
此步驟需要在局域網中建立 NTP 伺服器統一時間戳
進入 OpenWRT 系統設置
勾選 Enable NTP client(啟用 NTP 客戶端)和 Provide NTP server(作為 NTP 伺服器提供服務)
NTP server candidates(候選 NTP 伺服器)填寫:
ntp.tuna.tsinghua.edu.cn | ntp1.aliyun.com | ntp.tencent.com | time.windows.com
其實這四個源都是可用的看你心情 x
進入 OpenWrt 防火牆設置,在自定義設置中填入以下內容
# 防時鐘偏移檢測
iptables -t nat -N ntp_force_local
iptables -t nat -I PREROUTING -p udp --dport 123 -j ntp_force_local
iptables -t nat -A ntp_force_local -d 0.0.0.0/8 -j RETURN
iptables -t nat -A ntp_force_local -d 127.0.0.0/8 -j RETURN
iptables -t nat -A ntp_force_local -d 192.168.0.0/16 -j RETURN
iptables -t nat -A ntp_force_local -s 192.168.0.0/16 -j DNAT --to-destination 192.168.1.1
# 最後的192.168.1.1需要修改為路由器網關地址
確認效果:
在 Windows 電腦上,打開控制面板,在右上角查看方式處選擇小圖標,然後點擊 “日期和時間”。點擊 Internet 時間 -> 更改設置,點幾次 “立即更新”,直到提示 “時鐘在 xxx 與 xxx 同步成功”。
這時,暫時地拔掉牆上接口與路由器之間的網線(斷開了外網的連接),再點一次 “立即更新”,應該仍然提示成功,這說明 NTP 請求已經被劫持到了路由器自身而不是外網。然後把網線插回
重定向#
自定義防火牆配置如下
iptables -t nat -A PREROUTING -p udp --dport 53 -j REDIRECT --to-ports 53
iptables -t nat -A PREROUTING -p tcp --dport 53 -j REDIRECT --to-ports 53
即可
主路由 (OpenWRT + Clash + TTL + NTP + Flash) + 側路由 (OpenWRT + UA2F) (二級 NAT)#
此可以對付多微信情況下的 DPI 穿透檢測問題,是目前最穩定的手段,同時也避免了 UA2F 和 Clash 使用衝突
這個大概不是很麻煩,但是需要兩個路由進行防檢測,且兩個路由器需要都可以支持 OpenWRT 使用
在第一個路由器上部署 OpenWRT+Clash+TTL+NTP+Flash 方案 ————> 作為主路由,連接校園網交換機
在第二個路由器上部署 OpenWRT+UA2F 方案 ————> 作為旁路由,作為無線設備共享
在第一個路由器上關閉 wifi 功能,作為交換機僅連接第二級路由
在第另一個路由器上配置好 UA2F 後,可以將所需要的設備共同連接上
[scode type="red"] 已知問題:如果宿舍內有王者玩家,請勿雙方同時使用 wifi 功能進行遊戲 (UDP 防檢測無效)[/scode]
UA2F 編譯#
這邊使用immortalwrt源,自帶編譯包
在Link中找到適合自己路由器的固件,在 "自定義預安裝軟件包" 中添加 ua2f 後進行請求構建即可
如果不出意外的話應該是這個樣子的
之後按照 openwrt 的安裝方式安裝即可
或者可以自編譯到 OpenWRT 中,不過上手難度較高,建議查看相關教程。
總結#
經過上述的配置,可以達到預期的效果,實現在校園網環境下使用共享上網的方案
也有一種方案是 UA2F 的配合方案,此方案嘗試過會在幾小時內出現封號情況,不知是否是因為何種原因,不建議使用僅 UA2F 的方案。
如果想配置此方案建議參考:
https://sunbk201public.notion.site/sunbk201public/OpenWrt-f59ae1a76741486092c27bc24dbadc59
https://learningman.top/archives/304
本文也經過了一系列的參考根據實際學校情況編寫。
Reference#
此文由 Mix Space 同步更新至 xLog
原始鏈接為 https://lemonkoi.one/posts/tech/6