基于DNS嗅探的自动策略路由 / A realDNS opposites to fakeDNS

[povsister]

自从我开始使用v2ray的时候就在考虑这个问题，如何更加优雅的基于路由按需分流到旁路代理，现有的路由代理方案要么是软路由做网关，要么就是基于日更的GFW list在主路由上写路由表交给旁路做透明代理。前者不适合高吞吐场景，而且可能会遇到一些NAT转发/或者v2ray内核bug的问题；后者灵活性和鲁棒性都不够好。

v2ray本身已经提供了灵活的DNS/Routing配置，那么其实只要接管主路由的DNS，然后把解析结果拿来进行一次routing decision，取结果的outbound tag进行判断，接着进行适当的路由条目聚合（或是扩展到/30?甚至/28后再聚合），然后将其作为动态路由条目，通过标准的路由协议通告到主路由上，即可灵活的按需通过路由分流。

优点：

• 不产生DNS污染
• 路由协议足够灵活，支持几乎所有电信设备
• 除接管primaryDNS外，几乎不侵入现有网络拓扑
• 鲁棒性好，可以有优雅的重启/停止方案

缺点：

• 造轮子麻烦
• 需要一定的网络知识，配置相对麻烦
• 只适用于具有准电信设备的用户（至少得有个openWRT？）
• 直接TCP访问不会自动走旁路
• 对于某些应用内置DNS over HTTPS / DNS over TCP 没法嗅探到（同上）

现有想法是：
路由协议采用OSPFv2，暂不直接上v3。在dns app下新增一个dnscircuit的模块（意为通过DNS形成导线通路），保存OSPF配置/要监听的outbound tag之类的，通过features整合router决策（可能得改造现有router提供模拟路由以便拿到现有配置下的决策？还没细看代码），接着在dns circuit内部比对配置的outbound tag决定要通告的路由表，最终将此路由表用LSA通告出去。

最近刚差不多读完RFC2328，感觉只能先写个满足要求的最小化OSPF实现，后面再看要不要接着去新增功能啥的。
而且还在纠结这个OSPF instance是内置在v2ray里，还是提供一个额外的模块，v2ray通过RPC和它通信？
WIP: https://github.com/povsister/dns-circuit
看开源项目代码真爽啊，公司屎山让人窒息

先开个discussion看看大佬们有无什么想法，轻喷。

---

English version.

There are now 2 ways to setup a transparent proxy on your router(or gateway).

1. Using v2ray as your primary router. All traffic go through your proxy and v2ray will re-route your traffic by rules.
2. Using v2ray as secondary router(or known as router-on-a-stick), plus some static routing rules made on primary router. This will only route desired traffic to secondary router, and v2ray only handles those traffic on-demand.

For option 2, it's now implemented as "fakeDNS".
Re-routing traffic on-demand, it sounds great for high-thoughput network.
However, it also has a fatal shortcoming: fakeDNS returns FAKE DNS record which fits the static routing previously made on your primary router.
This make on-demand routing possibile, but also give you annoying surfing experience at certain circumstances.

I hereby propose another DNS-based policy routing mechanism called "dns-circuit".
Basically, sniffing by DNS query, routing decision by v2ray routing rules, announcing by dynamic routing protocol(OSPFv2).
DNS result leads to routing decision, routing result leads to route table, route table announced by routing protocol.
Finally, a "circuit pathway" is made for certain traffics, all happens because of a very simple DNS query, it is so called "dns-circuit".

Advantages:

• No DNS pollution.
• Supports almost all standard telecom devices.
• Not a very big change to existing network-topology.
• Graceful shutdown/restart capable.

Disadvantages:

• No existing OSPFv2 lib in go. (at least I didn't find one)
• Advanced network knowledge needed for configuration.
• Only suit for routers which support OSPFv2.
• How to sniffing DNS-over-HTTPS/TCP querys ??

I just finished reading RFC2328 recently, I might want to make a minimal OSPFv2 implementation my own to accomplish the step3 mentioned above.
I will be glad to accpet your help if you are interested in :)
WIP: https://github.com/povsister/dns-circuit

Feel free to share your ideas!

[dyhkwong]

[povsister]

由于现在的fakeDNS实在是不够好用，而且副作用太大。本身来说我还是想去对fakeDNS做一些改进，和应用更实用/灵活的分流设计。

从我有限的开发堆屎山经验来看，划分系统/软件边界确实是一个需要慎重考虑的问题。
虽然我个人有想过，但没有明显表述出来，上文只是一句话简单的带了一下这个问题：

而且还在纠结这个OSPF instance是内置在v2ray里，还是提供一个额外的模块，v2ray通过RPC和它通信？

现在看来，不妨由v2ray定义一个aggregated routing rule接口，经由此接口可以获取到v2ray聚合后的proxy路由，路由通告/维护交由外部模块去做，这样看起来是一个比较合理的方式。

[povsister]

坑了很久，搞出来叻。效果目前来说很不错，配合DNS分流+白名单模式，自动嗅探并通告路由给ROS

[sunnysab]

时间上来得及吗？如果 OSPF 更新路由慢了一步，此时客户端传输层的包已经发出去了……

[povsister]

首次访问能立即刷出来的概率五五开吧。9成情况稍等1-2秒就加载好了，偶发会需要手动点一下刷新。

[ZqinKing]

有没有可能直接用passwall的ipset结果做ospf通告？路由的一致性有保障，起码不会环路。还能解决部分不适用DNS查询的IP地址的路由问题。

[povsister]

暂无二开其他类似软件的计划，有能力的可以自己做适配