@hez2010
这数据看起来有点顶啊

头一次见把 go 代码写这么丑的，有一种不伦不类的美

jellyfin 的 UI 和功能上确实都比不太上 emby ，但毕竟开源版嘛，就这样。
plex 感觉有点用不惯

toB 文档写成这样也能卖钱啊。。
从这实际任务流程上感觉就是：世界果然是草台班子搭起来的

你说他是外行吧，他懂容器懂 k8s ，你说他是内行吧，他要搞两套 k8s 做主备。
我建议你按他说的做

@lanthora 可以，上面有关键词，tun （虚拟网卡），或者使用透明代理，本质都是把运行代理软件的这台机器当作网关使用，配置 ok 的话三层基本上就是通的

感觉这轮子造的有点重复了，xray/v2ray/clash 等工具都可以结合 tun 接口/tproxy 做到以 IP 转发模式完成对等网络配置，两侧网络的连接除了 ws 外，还有非常多的代理协议/transport 可选择

老实说，你这些要求单个看似不难，但合起来基本上是相互冲突的。最稳的办法：在自己终端设备上科学（斜眼笑

错别字有点多，不过是涉嫌 PCDN 。也就是说确认是 PCDN 的用户该停机。而且现在上海电信取消达量降速后 PCDN 禁令是写到协议里的

@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