maybeonly

@MFWT 甚至不觉得这种用户运营商会上报 也就不会有授权费

并不疯狂，我已经用了好多年了，运行良好，方便折腾。
在 netns （容器）之间转发的数据和一般的来自外部网卡的数据，对于内核来说有略微的不同，可能线路 B 会遇到这方面的问题。
我的做法是，直接在母鸡上操作各 netns （容器）的网络设置……比较暴力，但是省事——都在一起了，还折腾什么鸟（ bird ）事？
以及，只有容器的话不是很需要 SR-IOV 的感觉。
而且我在很多场景下只分了 netns 。
还有一个坑，做这种东西的时候不可避免的会用到 iptables/nft ，特别是 iptables 因为内核版本的差异可能根本不好用，者也是只虚拟化 netns 的一大原因（其实刚开始做这套的时候才是 centos7 ，那时候默认还只是传统的 iptables ）

tls1.3 的服务器证书是加密的，墙看不见
现在用户不支持 tls1.3 的很少了（ cf 有分析，可以看自己网站的受众）
结论：暂时用 1.3 就好。
（猜测：可能是之间暴力检测证书中的 google 关键字了，然后你在访问 google ？那可不行）

有 bug （物理）
不过我以前租房的时候也是那样，那些设备发热，小强喜欢往暖和的地方聚集
更有甚者在里边产卵的，小小强长大了出不来在里边活活饿死的也有
解决方法就是……换一个，没办法，喷药没用。
后来搬家了，家里没有小强，也就没有这种问题了。

旁路由和 ipv6 兼容很成问题。建议有 v6 刚需的情况下换成主路由使用，或者 v4 和 v6 场景分开（二级路由）
和梯子本身支持不支持双栈关系不是那么大，根本原因是 v4 和 v6 的网关是没关系的，dns 的获取途径有多种（ dhcp ，ra ，etc ），解析结果是分开的（ a ，aaaa ），旁路由要兼容 v6 的话你得把各种 v6 网关都指过去还要避免收到主路由的 ra

然后在梯子那里把所有去墙外的 v6 都 reject 掉就行了，客户端会自动用 v4 尝试。

@milkman155
这种看着有可能是单向绕路，也就是联通到电信走北京，电信回联通直接在本地解决

我现在的实现是这样的：
基础的还是白名单+ip 分流+自建递归
+黑名单直接用 1111 解析的
然后每天在 gww （宽带出口）上收集来自递归服务器的访问 udp 53 端口的请求
夜里解析这些域名，然后动态扩充白名单。

这些累积的白名单目前是 3 个月校对一次

基本逻辑还是那个：有任何一层权威在墙内的就算墙内域名。
实际上遇到过的问题：有些域名在 dnspod 或者 ali 上，但是只能通过海外访问，这些就得手工配置了……

有公网 ip 直接 wireguard/openvpn 回家
用一般的梯子也可以
然后所有流量直接从家里出，顺便过墙

@basncy
@huihuilang

所以主路由的话方便很多，可以卡住 v6 流量上策略
下发真实地址或者 fd 开头的地址都可以，也可以直连 v6 直出/过梯子走转发或者 nat66
甚至可以下面不开 v6 但是给梯子开

最后说个旁路由无论如何解决不了的：多线