maybeonly

你要找的是不是
https://ris.ripe.net/docs/mrt/

下面也给了几个 tools

如果要做墙内路由表，
成品的话 相对比较好的是
https://github.com/misakaio/chnroutes2

自己分析有个问题，有些 ip 段（如 114.114.112.0/21 ）是在墙内墙外分别宣告的，没有墙内数据源的话看不到墙内的宣告，会被误认为墙外。

以及，不要迷信容器。

这样下去迟早那个远程控制的接口被找出来干掉
不过另一面 用 D 版 B 源软路由……emmmm

@shenyuzhi
openvpn 也可以动态分配地址，但是我用这么久以来，还是在用 fd 开头的地址做 snpt
如果有固定地址当然没问题，如果是前缀的话……用脚本更新前缀虽然说也可以，但是根本不如分配私网地址省事
没必要那么忌讳 nat

以及，openvpn 也好 wg 也好，实际上也可以不用从上游拉整段/64 （这里不一定可以方便实现），随便拆个/120 ，在网关上静态路由指过去就得了，撞上的机会基本没有……

应该是 bug ，运营商侧没做源地址限制。
之前偶然一次程序出现 bug ，到北京移动的路上没设置上 snpt ，用了联通的 ip ，结果能正常通信……

@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 尝试。