锐捷キャンパスネットワークにおけるプロキシ検出の考え方と解決記録

国家教育部と関連部門の大力支持に感謝し、キャンパスネットワークの発展は、一人一アカウントから一アカウント一端末の状況に発展しました。

本文書は大きな更新があり、この文書は锐捷公式说明に基づいて作成されており、SunBK と Rusyneir 大佬の助けに感謝します。

前言#

こちらの状況は百兆年費 180 ですが、一言言わせていただくと、一アカウント一端末の機器の状況は本当に面倒です。もしコンピュータを使ってホットスポットを開く方法でこの問題を解決しようとすると、15 分間のブラックリストに封じ込められることがあり、本当に辛いです。~~どこの馬鹿が考えたのか分かりません~~

しかし、校内の状況から見ると、どうやら某宝でキャンパスネットワーク版ルーターを購入する以外には（高くて面倒で、品質も低い）、キャンパスネットワークの共有ホットスポット封禁に対する良い解決策はないようです。道高一尺、魔高一丈、上に政策があれば下に対策があるということで、私の実戦経験に基づいて、私の学校で実行可能な共有実験プランを分析しました。

まず、私たちの学校のキャンパスネットワーク認証確認ページを表示します:
campusnetworkindex

もしあなたのキャンパスネットワークの認証画面がこちらと一致しているなら、おめでとうございます、これは ** クソみたいな锐捷キャンパスネットワーク認証サービス** です。

RG-SAM: https://www.ruijie.com.cn/cp/yyxt-yygl/samx/
もし通常の方法でコンピュータのホットスポットを利用してキャンパスネットワークの制限を回避しようとすると：
血圧上昇

原理#

キャンパスネットワークの検出は、NAT サブネット共有の状況を判断し、1 つの IP アドレスの下で複数のデバイスを識別する能力を検出することに過ぎません。

サーバーの計算能力に基づいて、キャンパスネットワークの検出はハートビートイベントに基づいてランダムにデータパケットを抽出してチェックするものであり、即時フィードバックではありません：

現在、2 つのフィードバック状況があります：

1 つは UA に基づくものです

UA にはオペレーティングシステム名が含まれており、複数のデバイスが同時に接続されている場合、1 つのデバイスが複数のデバイスにネットワークを共有していると判断できます。

キャンパスネットワークはランダムに一部のユーザーを抽出して検出し、一度でも検出されると、その後は特にあなたのアカウントを監視します。

インターネット使用の特徴を分析することもサーバーリソースを消費しますので、全てのインターネットユーザーを同時に検出することはサーバーに大きな負荷をかけます。~~キャンパスネットワークがよく落ちる理由~~

一部の人はエミュレーターを使用しているときにプロキシでインターネットに接続されていると検出されることもありますが、その原理は非常に簡単です。あなたがログインしているコンピュータがネットワークを Android エミュレーターに共有すると、両方のネットワークサービスの通信時に UA が異なる可能性があり、特徴がルーターを使用しているのと非常に似ているため、キャンパスネットワークに識別される可能性があります。

もう 1 つは明確ではないが、技術的に実現されている技術です

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）は、データパケットがルーターを通過する際に伝達できる最長距離（ホップ数）を指します。
データパケットがルーターを通過するたびに、その存活回数は 1 つ減ります。存活回数が 0 になると、ルーターはそのデータパケットの転送をキャンセルし、IP ネットワークの場合は、元のデータパケットの送信者に ICMP TTL パケットを送信してホップ数の超過を通知します。これは、不正なルーティングテーブルなどの理由でデータパケットが無限ループに陥り、到達できずにネットワークリソースを消耗するのを防ぐために設計されています。

これは比較的効果的かつ合理的な検出技術であり、IPv4 データパケットには TTL（Time To Live）というフィールドが存在し、データパケットが 1 つのルーターを通過するたびに（すなわち 1 つのネットワークセグメントを通過するたびに）、その TTL 値は 1 つ減ります。

異なるオペレーティングシステムのデフォルト 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.45

Mozilla/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 というフィールドがあり、このフィールドは 1 つの IP パケットを一意に識別するために使用され、実際のアプリケーションでは通常カウンターとして扱われます。1 台のホストが順次送信する IP データパケット内の Identification フィールドは順次増加し、同じ時間帯内で異なるデバイスの Identification フィールドの増加範囲は一般的に異なるため、キャンパスネットワークは一定の時間内での増加範囲の違いに基づいて多デバイスの共有インターネット接続が存在するかどうかを判断できます。

具体的には、この特許を参照してください：基于 ipid 和概率统计模型的 nat 主机个数检测方法

ただし、私のキャッチ分析によれば、Windows の TCP/IP プロトコルスタックは Identification フィールドの実装が増加するのに対し、iOS の実装は全て 0 を保持するため、キャンパスネットワークがこの検出メカニズムを使用しているかどうかは議論の余地があります。

ネットワークプロトコルスタックの時計オフセットに基づく検出技術#

異なるホストの物理時計は異なり、ネットワークプロトコルスタックの時計と物理時計には対応関係があります。異なるホストがパケットを送信する頻度と時計には統計的な対応関係があり、特定の周波数分析アルゴリズムを使用して異なるネットワーク時計のオフセットを発見し、異なるホストを特定します。

具体的には、この特許を参照してください：一种基于时钟偏移的加密流量共享检测方法与装置

この方法は一定の実験性を持つため、商用に投入されているとは考えません。

Flash Cookie は、ユーザーが Flash ウェブページにアクセスする際に保持される情報を記録します。ユーザーがブラウザを開いてインターネットにアクセスすると、AC は Flash Cookie の特徴値を記録できます。Flash Cookie は削除が難しく、各ユーザーに対して一意であり、クロスブラウザをサポートしているため、共有検出に使用されます。

（確認済み、本校はこのような技術を使用しています）

判断によれば、锐捷キャンパスネットワークはグローバルポートスキャン（特に 80 および 8080 の非暗号化トラフィック） + UA 審査 + DPI Wechat UnionID 暗号化スキームを使用しています。

~~個人的には 80 および 8080 ポートを暗号化するのが良い選択肢だと思います~~

锐捷の文書によれば、このプロジェクトは UA 検出手段 + WeChat UnionID 方式スキャンを使用することが確認されており、対策を講じています。

方案#

一時的解決策（ADB Revese）#

申し訳ありませんが、この方法はAndroid | 鸿蒙プラットフォームのデバイスにのみ適しています、Apple の iPad & iPhone デバイスはサポートしていません
この方法はGnirehtetプロジェクトを使用しており、adb の方法でトンネルネットワーク通信を介してコンピュータと接続を実現します。
この接続は暗号化属性を持っているため、一時的な解決策として使用できます。
こちらでは晨钟酱の GUI バージョン（オンライン接続器あり）https://jamcz.com/wirenet/を使用しています。
特に説明する必要はなく、データケーブルをコンピュータに接続し、開発者ツールで adb デバッグを開くだけで使用できます。

ただし、注意が必要なのは、1 層 NAT 環境下では、一定の確率でキャッチされる可能性があることです。

ルーター設定プラン（OpenWRT + Clash）#

これは現在、キャンパスネットワークが共有を許可しない場合のルーター解決策ですが、このプランは同じアカウントの WeChat 端末でのみ使用可能です（異なるアカウントは DPI にキャッチされます）。

まず、必要な設定をインストールするための適切なルーターが必要です。こちらではネットギア WNDR 4300v2 を使用しており、某魚で 50 元で良い状態のものが手に入ります。予算が低い場合は k2p を選択できます。k2p はファームウェアでの改造者が多く、多くのチュートリアルが参考にできます。

同時に、暗号化に使用できるサーバーが必要で、未暗号化のプランを暗号化するのを手伝ってくれる必要があります。ここでは自分で x を用意して探る必要があります。

[collapse status="false" title="Hide"] 国内の免流空港を探してみてください。一般的に安くてトラフィックが大きいです。[/collapse]

OpenWRTFirmWare

↑ ↑ ↑

ここであなたのルーターに適したフレームを探してください。一部のルーターは直接インストールをサポートしていないため、必要に応じて「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]

ネットワークプロトコルスタックの時計オフセットに基づく検出技術#

このステップでは、LAN 内に NTP サーバーを設立して統一タイムスタンプを作成する必要があります。

OpenWRT システム設定に入り、

NTP クライアントを有効にする（Enable NTP client）と NTP サーバーとしてサービスを提供する（Provide NTP server）をチェックします。

NTP サーバー候補（NTP server candidates）には以下を記入します：

ntp.tuna.tsinghua.edu.cn | ntp1.aliyun.com | ntp.tencent.com | time.windows.com

実際、この 4 つのソースはすべて利用可能ですので、気分次第で選んでください。

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 コンピュータでコントロールパネルを開き、右上の表示方法で小アイコンを選択し、「日付と時刻」をクリックします。「インターネット時間」->「設定の変更」をクリックし、「今すぐ更新」を数回クリックして「時計が 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）#

これは複数の WeChat アカウントに対する DPI 透過検出問題に対処できる、現在最も安定した手段であり、UA2F と Clash の使用の衝突を回避します。

これはそれほど面倒ではありませんが、2 つのルーターを使用して検出を防ぐ必要があり、両方のルーターが OpenWRT をサポートする必要があります。

最初のルーターに OpenWRT + Clash + TTL + NTP + Flash プランをデプロイし、キャンパスネットワークスイッチに接続します。
2 つ目のルーターに OpenWRT + UA2F プランをデプロイし、無線デバイスの共有を行います。

最初のルーターで Wi-Fi 機能をオフにし、スイッチとしてのみ2 次ルーターに接続します。
2 つ目のルーターで UA2F を設定した後、必要なデバイスを共に接続できます。

[scode type="red"] 既知の問題：もし寮内に王者プレイヤーがいる場合、両方が同時に Wi-Fi 機能を使用してゲームを行うことは避けてください（UDP 防検出が無効です）。[/scode]

UA2F のコンパイル#

ここではimmortalwrtソースを使用し、コンパイルパッケージが付属しています。

Linkで自分のルーターに適したファームウェアを見つけ、「カスタム事前インストールパッケージ」に ua2f を追加してリクエストを構築します。

もし問題がなければ、以下のようになるはずです。

builder

その後、OpenWRT のインストール方法に従ってインストールします。

または、OpenWRT に自分でコンパイルすることもできますが、難易度が高いため、関連チュートリアルを参照することをお勧めします。

まとめ#

上記の設定を経て、キャンパスネットワーク環境下での共有インターネット使用プランを実現することができます。

また、UA2F の組み合わせプランもあり、このプランは数時間内にアカウントが封鎖されることがあるため、理由が不明ですが、UA2F のみのプランは使用しないことをお勧めします。
このプランを設定したい場合は、以下を参照してください：

https://sunbk201public.notion.site/sunbk201public/OpenWrt-f59ae1a76741486092c27bc24dbadc59

https://learningman.top/archives/304

この記事も一連の参考に基づいて、実際の学校の状況に基づいて作成されました。

参考文献#

この文は Mix Space によって xLog に同期更新されました。
元のリンクは https://lemonkoi.one/posts/tech/6