背景
在企业内网环境中部署服务时,经常会遇到这样的问题:
- 公司防火墙拦截了frp、rathole等常见内网穿透工具的协议特征
- SSH隧道被DPI(深度包检测)识别并阻断
- 开放的端口有限,仅允许80/443等常见端口出站
- 传统穿透方案需要额外开放端口,增加了暴露面
我们需要一种方案:既能穿透内网暴露服务,又能伪装成正常HTTPS流量绕过防火墙检测,同时还能作为梯子使用。
方案对比
| 方案 | 性能 | 抗检测 | 备注 |
|---|---|---|---|
| frp | 高 | 差 | 自定义协议特征明显,容易被DPI识别和阻断 |
| rathole | 高 | 差 | 基于Noise协议,性能优秀但协议指纹已进入黑名单 |
| SSH隧道 | 中 | 中 | 加密流量,但SSH握手特征明显,企业防火墙通常直接拦截 |
| Xray VLESS+REALITY | 高 | 强 | 流量与正常HTTPS访问完全一致,目前无已知检测手段 |
frp和rathole在性能上表现优秀,连接稳定、延迟低,但它们的协议特征已经被主流防火墙和DPI设备收录。在企业环境中,这些工具的连接往往在建立阶段就被拦截。
Xray的VLESS+REALITY+Vision组合完美解决了这个问题。REALITY协议不需要域名和证书,直接复用TLS握手,流量特征与访问正常HTTPS网站完全一致。配合反向代理功能,一个443端口同时承载多服务穿透和梯子。
架构说明
1 | ┌──────────────────┐ ┌──────────────────┐ |
流量走向
- 内网穿透:bridge用
.internal域名连接portal → portal识别为隧道注册 → 外部HTTP流量通过dokodemo-door进入 → portal转发给bridge → bridge转发给本地服务 - 梯子:普通客户端用任意域名连接443 → portal识别为普通流量 → freedom直连出站
两种流量共用同一个vless+reality入站,portal通过域名自动区分。
关键配置
公网服务器(portal端)
/usr/local/etc/xray/config.json:
1 | { |
内网机器(bridge端)
/usr/local/etc/xray/bridge-config.json:
1 | { |
Systemd 服务配置
bridge端
1 | # /etc/systemd/system/xray-bridge.service |
portal端
1 | # /etc/systemd/system/xray.service |
生成 Reality 密钥对
1 | # 安装 xray |
作为梯子使用
portal的443端口同时支持梯子功能。任何支持VLESS的客户端都可以连接使用。
节点链接(可直接导入v2rayN/Clash)
1 | vless://替换UUID@替换公网IP:443?encryption=none&flow=xtls-rprx-vision&security=reality&sni=www.microsoft.com&fp=chrome&pbk=替换公钥&sid=替换shortId&spx=%2F&type=tcp#节点名称 |
Clash配置示例
1 | proxies: |
注意事项
- 版本一致性:bridge和portal必须使用相同版本的Xray
- 不要重复开启Mux:反向代理底层已使用Mux.cool,不要在interconn outbound上再次开启mux
- 启动顺序:建议先启动bridge,再启动portal
- bridge端不需要inbound:reverse.bridges本身就是虚拟inbound,不需要额外配置dokodemo-door
- 域名路由规则顺序:
.internal的规则必须放在direct规则之前 - 穿透服务数量:每增加一个穿透服务,需要在两端各加一组bridge/portal + 对应的路由规则
说些什么吧!