Thanks to the strong support from the Ministry of Education and relevant departments, the development of the campus network has evolved from one account per person to one account per terminal.
This document has significant updates and is written according to the official instructions from Ruijie. Thanks to SunBK and Rusyneir for their help.
Introduction#
Although our situation is that the annual fee for 100 Mbps is 180, to be honest, having one account per terminal is really too troublesome. If you try to solve this problem by creating a hotspot on your computer, you may end up being blacklisted for 15 minutes, which is quite frustrating. I wonder who came up with this ridiculous idea.
However, based on the situation on campus, it seems that aside from using campus network version routers purchased from certain online platforms (which are expensive, troublesome, and of low quality), there doesn't seem to be a good solution for dealing with the campus network's restrictions on shared hotspots. As the saying goes, "where there is a policy, there is a countermeasure." Based on my practical experience, I have analyzed feasible shared experimental solutions for our school.
First, let me show you the campus network authentication verification page of our school:
If your campus network authentication interface is the same as ours, congratulations, this is the damn Ruijie Campus Network Authentication Service.
If you try to use the normal method to utilize the computer hotspot to bypass the campus network restrictions:
Principle#
The campus network detection is mainly about determining the situation of NAT subnet sharing, specifically the ability to identify multiple devices under one IP.
According to the server's computing power, the campus network detection should be based on heartbeat events to randomly sample and check data packets, rather than providing immediate feedback:
Currently, there are two types of feedback situations:
One is based on UA
The UA contains the operating system name, and if multiple instances appear simultaneously, it can be determined that one device is sharing the network with multiple devices.
The campus network randomly checks a portion of users; once detected, they will specifically monitor your account thereafter.
Analyzing online behavior also consumes server resources, and checking all online users simultaneously puts a heavy load on the server. This is why campus networks often crash.
Some people may also be detected while using emulators to proxy the internet, and the principle is quite simple. If your computer shares the network with an Android emulator, the network service communication on both sides may have different UAs, resembling the characteristics of using a router, which may be recognized by the campus network.
The other is a less obvious but technically implemented method
DPI (Deep Packet Inspection) technology
Currently, a well-performing example is --> Sangfor.
Based on practical experiences from some universities regarding campus network sharing, the following situations have been summarized:
- Detection based on the TTL field in the IPv4 packet header
- Detection based on the User-Agent field in the HTTP packet request header
- DPI (Deep Packet Inspection) technology
- Detection based on the Identification field in the IPv4 packet header
- Detection technology based on network protocol stack clock offsets
- Flash Cookie detection technology
According to official documents, it has been confirmed that DPI technology + UA detection methods are being used.
Detection based on the TTL field in the IPv4 packet header#
Time To Live (TTL) refers to the maximum distance (number of hops) a data packet can travel when passing through a router.
Each time a packet passes through a router, its TTL value is decremented by one. When the TTL value reaches zero, the router will discard the packet and, in the case of IP networks, send an ICMP TTL packet back to the original sender to inform them that the hop limit has been exceeded. The design aims to prevent packets from being stuck in an infinite loop due to incorrect routing tables and to conserve network resources.
This is a relatively effective and reasonable detection technology. The IPv4 packet has a TTL field, and each time the packet passes through a router (i.e., through a subnet), the TTL value decreases.
Different operating systems have different default TTL values: Windows is 128, while macOS/iOS and Linux are 64.
Therefore, if we connect our router to the campus network, the packets passing through the router will have a TTL of 127 or 63. Once the campus network captures packets and detects that the TTL is not 128 or 64, it will determine that the user has connected a router.
Detection based on the User-Agent field in the HTTP packet request header#
The HTTP packet request header contains a field called User-Agent, which typically identifies the operating system type, for example:
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
The campus network will capture this field multiple times, and if it detects fields like Windows NT 10.0 and iPad appearing simultaneously, it will determine that multiple devices are online.
DPI (Deep Packet Inspection) technology#
This detection scheme is relatively advanced. The detection system captures and analyzes application layer traffic, determining whether multiple devices are online based on the characteristic values of different application data packets.
For more details, refer to: Detection methods and systems for network sharing devices based on DPI technology.
This method has been confirmed to be applied in Ruijie-related devices, but due to the high performance cost of this feature, some schools may not enable it.
Detection based on the Identification field in the IPv4 packet header#
The IP packet header contains a field called Identification, which uniquely identifies an IP packet. In practical applications, it is usually treated as a counter; the Identification field of IP packets sent by a host will increment sequentially. During the same time period, the increment intervals of Identification fields from different devices are generally different, allowing the campus network to determine whether multiple devices are sharing the internet based on the differences in increment intervals over a period of time.
For more details, refer to this patent: Detection method for the number of NAT hosts based on IPID and probabilistic statistical models.
However, based on my packet capture analysis, the TCP/IP stack of Windows implements the Identification field as incrementing, while iOS maintains it as all zeros. Therefore, whether the campus network uses this detection mechanism is still debatable.
Detection technology based on network protocol stack clock offsets#
Different hosts have different physical clock offsets, and there is a correspondence between the network protocol stack clock and the physical clock. The frequency of packet transmission from different hosts corresponds statistically to the clock, and specific spectral analysis algorithms can identify different network clock offsets to determine different hosts.
For more details, refer to this patent: A method and device for detecting encrypted traffic sharing based on clock offsets.
This method is somewhat experimental, so I do not believe it has been commercially implemented.
Flash Cookie detection technology#
Flash Cookies record information retained by users when accessing Flash web pages. As long as the user opens a browser to go online, the AC can record the characteristic values of Flash Cookies. Since Flash Cookies are not easily cleared and are unique to each user, supporting cross-browser functionality, they are used for anti-sharing detection.
(It has been confirmed that our school uses this type of technology.)
Based on the assessment, the Ruijie campus network will use global port scanning (focusing on unencrypted traffic on ports 80 and 8080) + UA review + DPI WeChat UnionID encryption scheme.
Personally, I think encrypting ports 80 and 8080 is a better choice.
According to Ruijie's documentation, it has been confirmed that this project will use UA detection methods + WeChat UnionID scanning to address the issue.
Solutions#
Temporary Solution (ADB Reverse)#
I'm sorry, this method only applies to Android | HarmonyOS devices and does not support Apple iPad & iPhone devices.
This method uses the Gnirehtet project, which can establish a tunnel network connection to the computer via adb.
Since this connection has built-in encryption properties, it can be used as a temporary solution.
Here, we use the GUI version from Chen Zhongjiang (with online network device) https://jamcz.com/wirenet/.
It seems that no further introduction is needed; just connect the data cable to the computer and enable adb debugging from the developer tools to use it.
However, it is worth noting that under a single NAT environment, there is still a certain probability of being detected.
Router Configuration Solution (OpenWRT + Clash)#
This is currently the router solution for the campus network that does not allow sharing, but this solution can only be used with the same WeChat account on terminals (different accounts will be detected by DPI).
First, you need a suitable router to install the required configuration. Here, we use the Netgear WNDR 4300v2, which can be found for about 50 RMB on certain resale platforms. If your budget is low, you can choose the K2P, which has many tutorials available for firmware modifications.
At the same time, you need a server that can be used for encryption to help you encrypt unencrypted solutions; you will need to explore this yourself.
[collapse status="false" title="Hide"]Look for domestic free-flow airports; they are generally cheap and have large data allowances.[/collapse]
↑ ↑ ↑
Please find the appropriate framework for your router here. Some routers do not support direct installation; if necessary, please search for "xxx install OpenWrt" to find installation instructions.
[scode type="yellow"]Please try to find a non-brick firmware (Breed) for your router; this can protect your router from becoming a brick due to some misoperations. | Although not mandatory, it is recommended to flash it for safety.[/scode]
Some routers may require installation via Factory + Sysupgrade.
Debugging on OpenWRT#
Solving the TTL Detection Issue#
The method is simple: modify the TTL to a fixed value.
Connect to the backend via SSH and enter:
# Install necessary packages on the OpenWrt router
opkg update && opkg install iptables-mod-ipopt kmod-ipt-ipopt
At the same time, in the custom settings of the firewall, configure:
iptables -t mangle -A POSTROUTING -j TTL --ttl-set 64
This step is saved to complete the setup.
UA Detection (Clash Encryption Method)#
This step requires using Clash to handle the detection.
https://github.com/juewuy/ShellClash/blob/master/README_CN.md
After configuration, access the file backend via sftp or pre-configure it (or in any way you prefer, as long as you can access the backend files).
In the already configured config file, add the following rules at the top of the Rule section:
- 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
Here, Proxy refers to your encryption server, which is your Clash service; please configure it according to your situation.
[scode type="yellow"]If the configuration is successful, your unencrypted interface should be using the kernel network, achieving encryption.[/scode]
Detection Technology Based on Network Protocol Stack Clock Offsets#
This step requires establishing an NTP server in the local area network to unify timestamps.
Enter the OpenWRT system settings.
Check Enable NTP client and Provide NTP server.
Fill in the NTP server candidates:
ntp.tuna.tsinghua.edu.cn | ntp1.aliyun.com | ntp.tencent.com | time.windows.com
Actually, all four sources are usable; it depends on your preference.
Go to the OpenWrt firewall settings and fill in the following content in the custom settings:
# Prevent clock offset detection
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
# The last 192.168.1.1 needs to be modified to the router's gateway address.
Confirm the effect:
On a Windows computer, open the Control Panel, select the small icon view in the upper right corner, then click "Date and Time." Click Internet Time -> Change Settings, and click "Update Now" several times until it prompts "The clock has successfully synchronized with xxx."
At this point, temporarily unplug the cable between the wall interface and the router (disconnecting the external network connection), then click "Update Now" again; it should still prompt success, indicating that the NTP request has been hijacked to the router itself rather than the external network. Then plug the cable back in.
Redirection#
The custom firewall configuration is as follows:
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
That’s it.
Main Router (OpenWRT + Clash + TTL + NTP + Flash) + Secondary Router (OpenWRT + UA2F) (Secondary NAT)#
This can address the DPI penetration detection issue in the case of multiple WeChat accounts and is currently the most stable method, while also avoiding conflicts between UA2F and Clash.
This is not very complicated, but it requires two routers for detection prevention, and both routers need to support OpenWRT.
Deploy the OpenWRT + Clash + TTL + NTP + Flash solution on the first router —> as the main router, connecting to the campus network switch.
Deploy the OpenWRT + UA2F solution on the second router —> as the secondary router, for wireless device sharing.
Disable the WiFi function on the first router, using it as a switch only to connect to the secondary router.
After configuring UA2F on the second router, you can connect the required devices together.
[scode type="red"]Known issue: If there are players in the dormitory, please do not use the WiFi function simultaneously for gaming (UDP detection prevention is ineffective).[/scode]
UA2F Compilation#
We use the immortalwrt source, which comes with a compilation package.
Find the firmware suitable for your router in Link, and add ua2f in "Custom Pre-installed Packages" to request a build.
If everything goes well, it should look like this:
Then install it according to the OpenWRT installation method.
Alternatively, you can compile it into OpenWRT yourself, but the difficulty is relatively high, so it is recommended to check related tutorials.
Conclusion#
With the above configurations, the expected effect can be achieved, allowing shared internet access in the campus network environment.
There is also a UA2F combination scheme, which has been attempted but may lead to account bans within a few hours for unknown reasons; thus, it is not recommended to use the UA2F-only scheme.
If you want to configure this scheme, it is advisable to refer to:
https://sunbk201public.notion.site/sunbk201public/OpenWrt-f59ae1a76741486092c27bc24dbadc59
https://learningman.top/archives/304
This article has also been compiled based on a series of references according to the actual situation of the school.
Reference#
-
Guide to disguising multiple devices on campus network routers
-
Research and solutions for campus network sharing detection mechanisms at a certain university
This article was synchronized and updated to xLog by Mix Space. The original link is https://lemonkoi.one/posts/tech/6