透明代理+OSPF动态路由=近乎完美的全自动旁路由方案

[povsister]

前言

家里各种杂七杂八设备很多，有些设备可以方便科学，有些不行。
而且，我个人不太喜欢在需要科学的时候再开软件，尤其是手机同步电脑阅读记录时，打不开链接的感觉仿佛是坐马桶上蹿了一样难受。
所以，用网关做科学是我的基本要求。

设想

网关目前比较成熟的方案就是透明代理，但现在的透明旁路方案，都需要手动修改内网设备的网关，或者把默认网关指向旁路。
前者繁琐，后者不适合高吞吐场景。

有没有一种按需自动走旁路由的方案呢？
把不需要科学的流量直接从主路由发出，需要科学的流量再按需转发到旁路处理。
根据我有限的网络知识来说，这种情况只能从路由表下手。

为此我提出一个设想：
由旁路由接管DNS，以域名+DNS解析结果，去匹配旁路由的路由决策

• 如果路由决策命中需要代理，返回DNS解析结果，然后把对应IP路由通告给主路由。
• 如果决策为直连，则不做任何操作直接返回DNS解析结果，这种情况下仿佛旁路不存在。

具体细节可以看我在v2ray那边的讨论
v2fly/v2ray-core#2686

目前状况

目前我已经按上文设想，手搓了一套OSPF实现，然后在自己内网搭好了一整套解决方案。
代码目前在我fork的v2ray分支上，感兴趣的大佬可以自己尝试一下。
https://github.com/povsister/v2ray-core/tree/app/dns-circuit

这几天体验下来基本符合预期，唯一缺点是v2ray对于UDP的支持有点鬼畜，teams还有部分游戏表现不佳。
最近关注到了xray，看到xray对于UDP转发这块做了很大的改进。所以想迁移到xray上试试。
不知道xray社区对于这个带路由通告的透明代理有没有兴趣。

文末详细叙述一下整套解决方案

解决方案细节

前置要求

• 同时支持OSPFv2动态路由协议和策略路由（路由标记）的主路由，我个人使用ROS
• 可运行Xray-core的旁路由，我个人使用debian linux
• 主路由和旁路由最好和内网设备单独隔离出一个网段

配置要求

• 旁路配置tproxy透明代理，配置DNS分流，根据个人喜好配置GFW黑名单或者大陆白名单模式。
• 主路由DNS配置指向旁路，由旁路接管所有DNS解析。
• 主路由和旁路的xray之间配置OSPF动态路由协议，旁路由会把所有命中指定outboundTag的路由通报给主路由。
• 旁路由nftable配置：所有经旁路转发出去IP报文，进行masquerade（重要）
• 主路由配置策略路由：所有来自于旁路由srcIP的IP报文，直接经WAN口发出（避免路由环路）

目前缺点

• 直接IP访问无法被嗅探到
• DoH/DoT无法被嗅探到

我个人体验下来这俩缺点基本没啥影响。
被自己回旋镖打了，电报压根没用DNS
个例可以通过直接在配置里写静态CIDR，或者指定一个active loading的domain list file，由xray定期主动解析并刷新路由（不管有没有DNS请求）即可。

一些截图

v2ray配置，指定命中特定outbound的路由通告，指定OSPF运行接口及相关配置

v2ray与主路由形成OSPF邻接关系+自动根据DNS请求通告路由CIDR

ROS（主路由）上的路由表

旁路由设置好IP转发masquerade，用于直接转发透明代理不处理的流量（TCP/UDP以外的流量），以及部分不小心被默认/24 CIDR误伤的流量，

ROS 设置策略路由，避免形成转发环路

[povsister]

xray电报群的验证问题好鬼畜啊，今天又被踢了（

[xiaorong61]

你需要借助 gpt

[povsister]

实验性添加了persistent route设置，用于解决电报不用DNS直接IP直连的回旋镖
支持手写CIDR和geoip，需要在路由设置里也写上对应geoip的路由规则。

// config example
  "dnsCircuit": {
    "outboundTags": ["proxy-hk", "proxy-jp"],
    "persistentRoute": [
      "geoip:telegram"
    ],
    "ospfSetting": {
        "ifName": "ens160",
        "address": "192.168.87.2/24"
    }
  }

已知问题：

• persistent route的掩码可能和自动嗅探的默认/24掩码产生重叠

Apr 20 16:22:27 debianpov v2test[176916]: V2Ray 5.15.1 (V2Fly, a community-driven edition of V2Ray.) Custom (go1.22.2 linux/amd64)
Apr 20 16:22:27 debianpov v2test[176916]: A unified platform for anti-censorship.
Apr 20 16:22:36 debianpov v2test[176916]: 2024/04/20 16:22:36 [OSPF] adding persistent route: 91.105.192.0/23
Apr 20 16:22:36 debianpov v2test[176916]: 2024/04/20 16:22:36 [OSPF] adding persistent route: 91.108.4.0/22
Apr 20 16:22:36 debianpov v2test[176916]: 2024/04/20 16:22:36 [OSPF] adding persistent route: 91.108.8.0/21
Apr 20 16:22:36 debianpov v2test[176916]: 2024/04/20 16:22:36 [OSPF] adding persistent route: 91.108.16.0/21
Apr 20 16:22:36 debianpov v2test[176916]: 2024/04/20 16:22:36 [OSPF] adding persistent route: 91.108.56.0/22
Apr 20 16:22:36 debianpov v2test[176916]: 2024/04/20 16:22:36 [OSPF] adding persistent route: 95.161.64.0/20
Apr 20 16:22:36 debianpov v2test[176916]: 2024/04/20 16:22:36 [OSPF] adding persistent route: 149.154.160.0/20
Apr 20 16:22:36 debianpov v2test[176916]: 2024/04/20 16:22:36 [OSPF] adding persistent route: 185.76.151.0/24
Apr 20 16:22:36 debianpov v2test[176916]: 2024/04/20 16:22:36 [Warning] app/dnscircuit: persistent route: geoip:TELEGRAM ignored non-IPv4 cidr [2001:67c:4e8::]/48
Apr 20 16:22:36 debianpov v2test[176916]: 2024/04/20 16:22:36 [Warning] app/dnscircuit: persistent route: geoip:TELEGRAM ignored non-IPv4 cidr [2001:b28:f23c::]/47
Apr 20 16:22:36 debianpov v2test[176916]: 2024/04/20 16:22:36 [Warning] app/dnscircuit: persistent route: geoip:TELEGRAM ignored non-IPv4 cidr [2001:b28:f23f::]/48
Apr 20 16:22:36 debianpov v2test[176916]: 2024/04/20 16:22:36 [Warning] app/dnscircuit: persistent route: geoip:TELEGRAM ignored non-IPv4 cidr [2a0a:f280::]/32
Apr 20 16:22:36 debianpov v2test[176916]: 2024/04/20 16:22:36 [Warning] V2Ray 5.15.1 started
Apr 20 16:22:38 debianpov v2test[176916]: 2024/04/20 16:22:38 192.168.87.1:60474 accepted udp:192.168.87.2:53 [dns-out]

[jdjingdian]

V站来的，我目前使用ospf的时候，确实被透明代理direct流量产生环路的问题困扰。请问这个方案是否可以与dae配合

[povsister]

从dae的原理解释来看，如果你在主路由上使用!CHNRoutes转发流量，而不是将全部流量交由dae处理的话，由于dae的默认不做SNAT的行为，很容易就会形成环路而且基本无法避免。
解决方案有两个：

• 删除!CHNRoutes规则，将全部流量交由dae分流，利用dae direct的高性能特性+非对称路由即可。
• 在dae所在的旁路开启SNAT（即开启masquerade），然后结合我上文提到的策略路由方式，标记由dae机器IP的数据直接送出WAN口即可。

[jdjingdian]

另外关于DNS，可以用VRRP让主路由与旁路由共享一个虚拟IP，dhcp服务器将dns指向这个虚拟ip，然后旁路由的VRRP优先级设置为更高。主ROS的dns采用运营商默认DNS，这样如果旁路由挂了，主路由会自动接管VRRP的IP，不影响客户端的DNS查询

[povsister]

VRRP有点大材小用了，而且在ROS上加一个备份DNS会造成旁路偶尔查询超时的时候，降级到ROS的备份DNS，可能会引入DNS污染问题（旁路上我对于GFW list的域名都是disable-fallback-if-match的，这个特性在ROS上反倒不太好做）

V2EX那边有老哥提醒我可以利用ROS的脚本和一些netwatch的功能，做旁路的探活和自动切换，我应该会选这个方案。

[Fangliding]

唔 旁路由

[povsister]

呃，旁路由有什么问题么？

[povsister]

功能更新：

• 添加了对于默认outbound Tag的匹配
• 路由条目掩码调整至默认/32，存活时间6个小时。
• 活跃连接（而不是仅DNS请求）现在也可以刷新对应路由条目的存活时间了

[fbion]

mark

[greatxin]

经过几天测试，我配合ikuai的docker运行bird进行了部署，大致工作良好，但对于那些像图片通过二级域名cdn加速的图片有时体验会不好。
有些补充，通过ospf通告dns ip 即可，无须配置health-check，v2挂了dns请求会走正确的路由，再对分流规则做完善些，只要不出现环路就可以不配置策略路由。主要是虽然搞到了ikuai的特权容器，但是容器内不能跑iptables，导致要想用iptables的功能重启后自动执行会麻烦，干脆不弄了。
还有当前版本v5.16.1-mod有bug，只会为第一个访问的分流规则添加src ip，可以通过写规则时在source里额外添加一个src，然后启动完访问一次那个规则来缓解问题。
https://www.right.com.cn/forum/thread-8384180-1-1.html

[povsister]

bug问题已知，最近太忙，有空会修，另外还有个bug是路由不活跃时间设置无效，这个代码已经修了，但是还没release

[cnclg]

目前能用到Xray上面了吗？

[sqngm]

我现在用 dreamacro/clash-premium:2023.08.17 搭的透明代理，有同样的困扰，请问还有更简单的方案嘛？
之前用个梅林上的猫咪爬梯，他里面有个黑白名单的模式，就挺简单的。

[sdttttt]

感觉和我的透明代理思路挺像的，不过我是做的利用FakeIP做的策略路由。
旁路由的DNS分流后(代理流量FakeIP，正常流量RealIP)，需要代理流量就能直接在ROS上通过判断FakeIP观察到。

OSPF来分流确实是个好主意，有点新鲜