@mohumohu #91
部分设备走代理与否，这其实是一个策略问题，与方案无关。
既然可以让旁路由的流量绕过代理规则直接发出，那你觉得内网任意设备可以吗？自然是可以的。
ok ，到这里我觉得可以结束讨论了。这方面我们各自都有不愿意放弃的点，应该是无法达成一致的。

@everfly #92
国内是否会允许 DoH/DoT 以及 ECH 的落地，这个我持保留意见，毕竟审计需求是客观存在的。
而且 ECH 属于 TLS1.3 的 extension ，依赖 DNS SVCB 记录，本质上属于一个可选的安全特性，并不是那么好普及的。
未来可以预见的是：海外套过 CF 的网站必然会逐渐默认支持 ECH ，但绝对不会直接拒绝普通 TLS1.2/1.3 的访问流量。

而且由于 ECH 的出现，很多现代化梯子依赖的 sniffing+基于域名匹配的路由规则将受到严重冲击。届时除 FakeDNS 外，唯有一条路：DNS Route ，依赖 DNS 解析，动态构建基于 IP 的路由规则，而不是现在的这套基于域名的路由规则。

@Jirajine #45
同意的，各种方案都有其优缺点。我描述的多网站共享 anycast ip 问题，确实适合在客户端侧自行解决。网关上只能有限的进行优化，无法彻底根治。属于透明代理的 tradeoff 了。

@maybeonly #46
完全理解了！
也就是只通过 DNS query 去刷新 DNS route 规则，已建立的连接依赖 conntrack 保持，不受 DNS route 限制。

我昨天给自己的实现添加了 onConnectionActivity 时，重置对应 DNS Route 的有效期，只要现有连接上有数据活动，则对应路由条目会一直刷新有效期。直到所有连接断开，且没有对应 DNS 请求时，对应 DNS route 才会被清理掉。
用于应对客户端 DNS 记录的缓存时间超过 DNS TTL 的情况。不过感觉似乎有点矫枉过正了。。

你这个旁路使用方式是 !CHNRoutes 固定路由模式（即常说的大陆 IP 白名单机制），属于比较初级的旁路模式。

再来讲问题
> 首先是走了旁路网关，会导致带宽劣化
旁路性能取决于旁路由本身，无法更改，只有两个优化办法：
* 优化路由选择策略，做到必须走旁路的情况下，再去承担这个性能损耗
* 旁路软件使用 dae 这种带直连转发加速的代理实现（但是需要额外注意直连流量可能导致路由环路问题）

> Nat 状态异常
解决方案只有一个，优化路由策略，能不走旁路就不走旁路。
否则你只能信任代理软件的承诺，比如 dae 和 xray 都承诺支持 FullCloneNAT

理想的旁路由模式应该是 DNSRoute ，即 FakeDNS 的优化版，做到全真 IP 。
放弃使用!CHNRoutes 固定路由，转而使用基于域名的 DNSRoute 。可以看这位大佬的帖子，很详细了。t/1034955

@maybeonly #34 感谢分享思路！
这个问题我个人猜测应该是不会那么痛，但是明显还是大佬思考更细致。

我赞同你对现实情况的考量，只要路由选择上添加 srcIP - dstIP 做匹配，把不同终端的路由选择分割开，就能极大缓解这一问题。
目前我自己的实现是：只做了 dstIP 的路由规则，后续会抽空加上大佬的 srcIP 路由匹配策略。

另外咨询一个问题，大佬的 DNS route 的有效期是怎么计算的？什么时候废止这条路由表？
是靠客户端的 DNS 请求刷新吗？

@Jirajine #36
不能算在错误的 layer 解决问题吧，只能说是：把解决的问题的阶段下沉，对内网终端设备隐形。
然而把方案下沉，其实哲学意义上，就意味着解决问题时能获取的有效信息会减少。
这和运营商选择把反诈插件放在用户侧光猫里是一样的道理，只有足够贴近用户，才能提高反诈预警的准确性（只是举个例子哈，不对反诈这个东西做任何评价。

说到底，我和 OP 的哲学是一样的，能在网关解决的问题绝不在客户端上解决。

@maybeonly #24
DNS 分流实现思路和我一样，都是“不过墙的网络完全不走梯子”，但是我选了继续完善旁路由方案，对于 conntrack 部分我还是依赖主路由的路由表和防火墙的。给你这个全手搓的 DNS 分流跪了 Orz

不过我的帖子里，@mohumohu 提出了一个很有意思的问题：
有些网站会有区域限制，全真 IP 的情况下，如果两个网站解析到同一个 anycast IP ，而且域名嗅探失败的情况下，基于 conntrack 这一套 L3 的分流，如何正确选择代理隧道？
举个例子：假设 Netflix 套了 Cloudflare 的 CDN ，解锁 NF 需要美国 IP 。假设 DMM 也套了 CF 的 CDN ，解锁 DMM 需要日本 IP 。但因为 CF 的全球 CDN 网络，这两个站解析出的 IP 地址都是同一个 anycast 地址。

代理实现越靠下层，则会损失越多偏上层的信息。
我思来想去感觉很无解，随着 http3 和加密 SNI 普及，IP 数据包中的域名嗅探会变得越来越难，那么全真 IP 下的域名分流机制可能会始终面临这个痛点。

@MikuM97
上海电信去年五月取消了达量降速的条款，现在也是枪打出头鸟，如果你敢一个月上行十几 T ，那就是 pcdn 停机警告

分流思路和现在各种代理 core 差不多，而且在 dns route 上也摒弃了 FakeDNS 的路子好评。
但是，什么？你用 C++写的？还搓了这么多轮子？这是真大佬惹不起惹不起。

@mohumohu
哎，一并回复你 88 和 89 楼的问题吧
#88
本文的前提是：家庭网关层面的透明科学方式，并不是“管理一个企业级网络”。
我理解，各种各样的网络配置都有其优缺点。所以不存在一种完美的解法：你选择接受 FakeIP 的负面影响，我选择更复杂的方案，但是根除 FakeIP 的负面影响。

但，有一点应该是明确的：哪怕是一个“企业级”网络，放任“自助配置”，绝不是一个好办法，花样性配置才会带来更大问题排查和稳定保障难度。管理员本身是绝对没有那么多精力去挨个检查并测试个性化配置的。

另外，我所希望的特性已经在开头完完全全的讲明白了。我需要的是 all the same ，with no exception 。你一直在反复质问我怎么解决 exception 。这一点就讲真有些离题了。
所以我更希望大家能在同一个 context 下讨论问题。而不是“教我企业级网络应该具有什么特性”。

#89
OK ，来回答你怎么在网关上处理 exception 的问题。
用伪代码表示一下吧，可以理解为作用于 linux 的 postrouting 规则链上。
1. 不对称路由方式
from {某个内网终端设备 IP} to {旁路由 IP} proto=UDP and dstport=53 redirect-to {主路由 IP} port=53
2. 对称路由方式
from {某个内网终端设备 IP} to {旁路由 IP} proto=UDP and dstport=53 dstnat-to {主路由 IP} port=53

@mohumohu #85
DNS 问题两个方案没有本质差别，完全取决于怎么用。。
而且作为应用层的一部分，把 DNS 算进拓扑有点牵强。

罢了，我回复你的问题吧。
* 将主路由 DHCP 下发的 DNS 服务器改为旁路由 IP
* 主路由 DNS 不变，使用 ISP DNS
* 如果不需要科学，也有两种方案
1. 自己把设备的 DNS 手动改成主路由 IP
2. 在路由上写一条防火墙转发规则，将指定设备访问旁路由 IP 的 DNS 请求 redirect 至自身。（这种情况是非对称路由），也可以使用 DSTNAT ，保证对称路由。

所以你看，有区别吗？
何况，我所做的一切，都是为了让内网终端设备“完全感知不到代理存在+最大程度保证主干网络稳定与正确”。
因而，本方案下的旁路由是完全可插拔的，哪怕不做任何设置，直接拔网线也不会影响到主路由正常工作。
你这个“某个设备不想使用代理”的要求属实有点范围外了。

@mohumohu #82
拓扑侵入问题，FakeIP 需要操作两点：
* 手动添加静态路由
* 手动修改主路由 DNS
并且，故障降级前提是：旁路代理软件工作正常。如果旁路彻底挂掉，除了恢复主路由 DNS 配置外，还无法立即降级，因为 DNS 污染还会持续一段时间，并导致这段时间内路由选择错误。

OSPF 方案，只需要操作一点：
* 不需要手动添加静态路由
* 手动修改主路由 DNS
故障情况分两种：
1. 代理节点故障，则降级行为取决于使用的代理软件本身，FakeIP 和 OSPF 两种方案无异。
2. 旁路故障（包括：旁路 IP 不可达，旁路由代理软件崩溃），FakeIP 无法立即降级（原因上面讲了），OSPF 路由可以立即失效，此时路由选择完全正常。

DNS 降级方案 FakeIP 和 OSPF 共通，就不详细叙述了。
所以，综上所述，我认为 OSPF 是对拓扑影响最小的一种方案。

DNS 缓存问题，个别平台的规则，肯定是不能拿来当范例使用的。
网关遵循并使用的方案，应该是放之四海而皆准的。所以正确性这点我不打算妥协。

CF 分配 anycast 地址这个现象，你我都是就现状进行猜测。所以确实没有争论价值。
就要解决的问题来说，结合我之前提到的方案，我提出两个解决方案：
1. sniffing + Domain routing rule （基本所有代理内核都支持）
2. OSPF 路由通告/32 掩码的路由，降低 IP 和网站重叠的可能性，这点我已经作为默认设置了。

而且除去 FakeIP 这个方案外，你提到的“多个网站分配同一个 CDN 地址”这个问题，在其他代理模式下有且仅有通过 sniffing 解决。
除非将代理协议上移至应用层（例如：socks5 ），由应用本身通过代理协议，直接告诉代理软件它要访问的域名。这样才能保证域名分流准确。
总之，有舍必有得，如果将代理行为下沉，则必然会损失上层的一些信息，这些是正常的 tradeoff 。

@zbatman
> 扶墙挂了就通过“完全不能访问”来提醒我
这个其实取决于如何定义“扶墙挂了”，上面讨论中的扶墙挂了=旁路由完全不可用，而不是代理节点故障。
在默认配置下，如果不对代理节点做探活，代理节点连接出现问题，其实也会导致你没办法访问扶墙的网站。如果你在配置中明确了代理探活不可用就降级直连的话，才会出现你说的类似“DNS 泄露”的问题。

至于代理软件崩溃，以及旁路由实例故障，这种情况属于小概率事件，在我目前设计下，会造成旁路由从网络拓扑中直接消失，而完全不会影响主网络拓扑结构。

> 国内返回真实 ip ，国外请求 clash 返回 fake-ip 。即使 clash 挂了，不用任何配置，都不影响国内流量
这个前提条件是，国内外网站划分是准确的。实际上嘛，很难。
举个灰色的例子，比如 GitHub ，属于半墙不墙的状态，平时肯定直接走代理保证访问体验。但如果扶墙寄了，我这时候又因为某些事情不得不直连访问。那么 fakeip 带来的污染问题会让我一个头两个大。

其实讨论了这么多，我核心的诉求可以概括为一句话：旁路由在拓扑中存在与否，只通过一条命令 systemctl start/stop v2ray 来实现。
旁路由的优势就是，其对于除网关以外的设备完全隐形。所以我对它的要求是，悄悄的来，悄悄的走，不留下任何痕迹。这也是我哪怕自己耗费 2 周时间手搓 OSPF 也不使用 fakeIP 的原因。

@jink2018us
视频很好，适合入门。但感觉有点故意混淆旁路和 FakeIP 按需分流的概念。
另外，视频中提到的所有的旁路由问题其实都已经被我解决了。

@terrancesiu #39
不能，鉴于国内目前 ipv6 的环境，短期内不考虑做 ipv6 支持，开发成本不划算。

@zbatman
没问题，v2ray 的出站 DNS 流量一样可以匹配出口，这点你根据需求自由配置即可。

举个例子：我有两个 1.1.1.1 的 DoH DNS 服务器配置，一个匹配域名写了 pixiv ，另一个作为默认兜底。
前者的 DNS 查询流量可以被标记为 dns-jp ，后者标记为 dns-default ，然后路由模块添加 tag 匹配规则，来源为 dns-jp 的流量，送往日本节点即可。

@zbatman
就是正常的 v2ray DNS 模块，支持所有配置规则。
具体取决于你希望国外域名怎么配置。

比如我是 geosite:cn 和部分我个人指定的域名走 ISP DNS + DNSPod 做备份，其余不命中规则的域名，默认走 DoH 1.1.1.1 从代理解析。
策略选择 disable-fallback-if-match ，避免国内域名超时后请求国外 DNS 。

@terrancesiu
使用 ROS 的用户可以参考下我前两天发布的旁路动态路由方案：DNS 嗅探+ROS 路由表分流，旁路拓扑完全可插拔。所有旁路配置集中管理。

@wawaguo #20
全部流量都走软路由的透明代理模式，或多或少会有一点影响。
而且部分游戏会有奇奇怪怪的连接问题（取决于代理软件的 NAT 行为）
可以参考 dae 的 issue 区反馈，虽然 dae 是 fullClone NAT ，但确实还是有一些反馈问题的。