
最近在配置软路由时,遇到了 ChatGPT、Gemini 等 AI 工具的区域检测难以绕过的问题,其中涉及一些以太网相关的技术细节,在此与大家分享。
TUN 模式 与 兼容模式 的核心区别,本质上在于:流量是由谁、在哪个网络层进行接管的。
模式 | 本质 | 接管层级 | 兼容性 | 推荐程度 |
|---|---|---|---|---|
TUN 模式 | 虚拟网卡接管三/四层 | IP 层(L3/L4) | ⭐⭐⭐⭐⭐ | 强烈推荐(新方案) |
兼容模式 | 防火墙 + 代理转发 | 传输/应用层 | ⭐⭐⭐ | 老设备 / 特殊场景 |
OC 在路由器上创建一个 TUN 虚拟网卡:
终端设备
↓ 原始 IP 包
软路由内核
↓ 进 TUN 设备
OC Core
↓ 根据规则决定
直连 / 代理兼容模式依赖 iptables + 端口重定向 + DNS 技巧:
应用
↓
请求 example.com
↓
DNS 被 fake-ip / redir-host 劫持
↓
iptables REDIRECT 到 7892
↓
OC 再做代理核心是:
组件 | 作用 |
|---|---|
redir | TCP 重定向 |
fake-ip | DNS 返回假 IP |
redir-host | DNS 返回真实 IP |
iptables | 强制改路由 |
项目 | TUN | 兼容模式 |
|---|---|---|
接管层 | IP 层(L3) | socket / 端口层 |
是否需要 DNS 技巧 | ❌ | ✅ |
是否 NAT 感知 | ❌ | ✅ |
是否容易漏流 | 极低 | 较高 |
TUN 是在做路由,兼容模式是在做拦截。
协议 | TUN | 兼容 |
|---|---|---|
UDP | ✅ 完整 | ⚠️ 部分 |
QUIC | ✅ | 不稳定 |
WebRTC | ✅ | ⚠️ |
游戏 | ✅ | ❌ |
项目 | TUN | 兼容 |
|---|---|---|
DNS 泄露 | 几乎无 | 常见 |
fake-ip 依赖 | ❌ | 强依赖 |
国内直连 | 干净 | 容易污染 |
很多问题:
90% 是兼容模式的问题
Gemini 会检测:
example.google.comgenerativelanguage.googleapis.comnotifications-pa.googleapis.com是否满足:
DNS 解析的 IP 归属地区
==
实际 TCP/QUIC 出口 IP 的地区只要不一致就不通过
Gemini 优先 QUIC (UDP/443) :
如果:
会直接判定异常网络
Gemini 会做:
这些延迟模型和AS路径会被用来判断:你是不是在用中间人
兼容模式下常见:
Google 对这类行为 非常敏感
应用
↓
DNS → OC fake-ip(假 IP,或国内 DNS)
↓
iptables REDIRECT
↓
OC TCP 代理
↓
代理出口(国外)项目 | Gemini 看到的 |
|---|---|
DNS 解析来源 | 中国 / fake-ip |
TCP 出口 | 美国 / 日本 |
UDP 行为 | 有时直连 |
RTT 特征 | NAT + 转发异常 |
DNS ≠ TCP ≠ UDP,这是反代理系统最喜欢抓的特征。
TUN 做的是IP级视角
应用
↓ 原生 IP 包
TUN 虚拟网卡
↓
OC
↓
代理出口项目 | TUN 模式 |
|---|---|
DNS | OC 统一处理 |
TCP | 同一出口 |
UDP | 同一出口 |
QUIC | 正常 |
RTT | 合理 |
AS 路径 | 一致 |
在 Gemini 看来:你就是一台正常的美国机器
你可能会疑惑:GitHub、YouTube、搜索都没事
原因很简单,Gemini的监管等级更高
在大多数软路由、x86 和 ARMv8 环境中,TUN 模式的整体开销确实会略高于兼容模式,但差距并不大,而且换来的,是明显更好的稳定性和确定性。从网络模型上看,TUN 直接工作在网络层(第 3 层) ,像一张真正的虚拟网卡;而兼容模式更多停留在传输层和应用层(第 4 / 第 7 层) ,依赖重定向和“劫持”来完成代理。
如果你更在意网络行为是否“像一台真实的远端主机”,那 TUN 模式无疑更值得选择。