@Jirajine
耦合并没有那么深，重要性也是分层的。
比如在外边，开着公网 ssh 的话（实际上就是），只要三个核心的模块（ INGW ，OWGW ，RTGW ）活着就能连回去。当然对应的 WAN 得正常。
然后一些是重要模块，比如 DNSIW ，DNSOW ，RECURSIVE ，DNSROUTE ，这些正常工作的话里边可以正常上网。
不仅仅各种隧道是模块化的，连入 VPN 、ADBLOCK 这些也都是模块化的。
再有就是，分 netns 是为了能有更强的扩展能力，也是为了每个 netns 里规则相对清晰，更是可以实现路由和 nat 分离，这一点在 dnsroute 里有集中的体现。
核心模块搭起来的是一个框架，然后就可以往上附着各种模块。
还有一些模块不是以 netns 的形式出现的，比如存在一个 ingw.d 模块，可以设置某些客户端（ ip/ip6/mac ）是不是使用去广告 dns ，是只有常规端口过梯还是所有端口过梯，etc.。更别说还有隧道管理器、流量监控之类的东西，纯属外围模块。又比如如果有需求，可以很轻松地给一个或多个 WAN 添加 nat1 模块而不影响整体，之类的。

@jsq2627
自建递归是一种权衡的选择。
主要目的是为了给没有在名单里的域名兜底，也从根本上杜绝 dns 泄漏之类的问题。
很久很久以前是用黑名单解析境外个别网站的，后来经常因为名单维护不及时而有时候连不上很恼火，逐渐改成了现在这个样子。
实际上没有想象的那么慢，例如解析 www.google.com ，实际上.com 是几乎肯定被缓存的，只需要 2rtt 就能解到。
复杂一点的，比如 www.163.com ，要 cname 两次，需要 7rtt 才能解析出来（当然 163 显然是在墙内白名单里的）
如果觉得有必要可以用名单手工指向墙内或墙外。

@povsister
dns 分流这一点还是相信自己的创造力的。
现代专业梯子分流都是基于全用户态实现，dae 将无需代理的部分绕过了梯子用户态。
实际上这些软件，特别是 dae 之前的软件，设计场景都是单机使用，如果用在软路由上，就不可避免地会经常出现“为什么不过墙的网络也受影响”“啊，我改个梯子把整个网络搞坏了”“所以还是旁路由好”之类的情况。dae 一定程度上解决了第一个问题。
这边的实现，将调度模块与隧道模块分离，很大程度上解决了第二个问题。
通过自动维护的映射表（ LAN 通过 ip nei ，openvpn 通过 status.log ，wg 通过 allowedips ），解决 v4/v6 映射的问题。同时，考虑隧道可用性，匹配最佳隧道，对首包用用户态通过 mac 地址选择下一跳，然后根据回包 mac 地址匹配 conntrack ，并且在后续甩掉用户态程序全依赖 conntrack ，极大程度保证了首包以外的性能，而且 dnsroute 本身负载很低，也解决了第一个问题——这一段肯定够写个专利了。
c 艹虽然确实比较艹，但是真的是很好用的。应该说最早还在用 dd-wrt 的时候，就有 c++写的一些其他模块在用了，所以说形成路径依赖了吧，那时候肯定是 2012 年之前的事情了。

@eh5
> “和很多东西冲突”

也曾考虑过这方面的问题，在真实部署中会很依赖端口选择（配置）
确实，代码本身不会利用自己已经用过的 snat 后的源端口，但是如果这些端口和其他 dnat 规则冲突，抑或被其他程序占用呢？运营商的 cgnat 没有这个问题，毕竟人家的 ip 就是专供 nat 用的。家用的话，可能不得不特别小心 dnat 的选择，以及用 ip_local_port_range 隔离了。然后发现 dnat 搭配的 hairpin 怎么办？ emmmm 。。。

当时自己考虑的结果是，不得不和 conntrack 做某种程度的“交易”才能解决这个问题。
交给 conntrack 选 snat 后的源端口就没这个问题，只要识别到这个内部 ip:port 和外部 ip:port 的组合，后续不走 conntrack 按照 fullcone 的实现就好了。不仅能指定源端口，也可以实现比如针对某个 ip 实现 fullcone ，etc 。

同时被解决的另一个问题是，什么都没配置的话可以继续走系统的 conntrack ，只有配置了命中了正确的端口范围才能 fullcone 。在实践上也会是相对比较安全的。

然而咱终究是懒得 1b ，对勤奋的楼主表示深深的敬意。

@eh5
> 这个只有改了包的大小超过 MTU 时需要发回去，比如 Cilium 的 NAT64 对超过 MTU 的包就是这样的，但 einat 没改理应不需要啊。。 为什么内核没有拆包我就不知道了
理论上吓一跳链路比包“窄”就需要。虽然对于 ipv4 ，我是没见过哪个路由器是不分片而回 icmp 的（除非设置了 df ）

> 正常情况下 ctrl + c 是会清 bpf 程序再退出的，可以`bpftool prog` 看一下有没有 `egress_snat` 和 `ingress_rev_snat`， 但 qdisc clsact 确实没删但也没什么大问题（主要是懒得查 qdisc 占用情况了，也不能全部删掉。。）
没有了，只是再启动会报个 warning ，并不影响正常工作的。
WARN einat: libbpf: Kernel error message: Exclusivity flag on, cannot modify

@eh5
1. 既然想着共存了，改 conntrack 确实不是好事情，不过似乎可以（部分）绕过 conntrack ？
当时考虑的是在入口和出口分别捕包，然后在出口处发现符合条件的报文后反查刚刚从入口抓过来的数据包，可能用到的匹配条件有：protocol+dst ip & port/id, length, 应该还有 ip 报文的 id 。
抓到该端口相关的东西后续由 ebpf 完成 nat ，不再经过内核。
2. 对于碎片，考虑发 icmpv6 type2 或者 icmp type3 回去？不确定能起多大作用。

由于我太懒了，以上全部都停留在设想，具体能实现到什么程度，在真实网络环境中运行咋样，以及对性能的影响，也只能说停留在设想中了。。。
p.s. ctrl+c 掉程序没有清理 tc 钩子，下次重启进程得手工删 tc 。。。

再次感谢楼主。

很多年前在本站某网友的影响下设置为 254 ，就渐渐成为习惯了
直到今天我家内网有 7 个/24 了还是这样
曾经某一天有了 v6 ，突然发现，这 192.168.0.254 是网关，那 v6 网关是多少？
1. 用 2001:db8::fe ？嗯，有点奇怪，但是其实是问题最小的。（实际上在用这个）
2. 用 2001:db8::1 ？啊，那 192.168.0.1 怎么办？
3. 用 2001:db8::ffff:ffff:ffff:fffe ？*，输入这种地址要死了。
4. 肯定有人说，用 fe80::1 呀？这个，路由没问题，但是如果需要连接到网关呢？（实际上也配置了 fe80::1 ，并不矛盾）
你看，用.1 就这些鸟问题。

赞
有个问题是，有没有机会和现有的 ipt/nft 创建的 dnat 规则甚至 snat 结合使用呢？
有考虑过自己搓一个，用 ipt/nft 写 snat ，对于匹配某些东西的 snat 到某些特定的源端口（范围），然后在出口侧抓住这些内核 nat 过的源端口，对与这些源端口相关的报文/连接/端口进行 full cone 的……不过不知道能实现到什么程度，以及代价到底怎么样
再赞一遍。
p.s. 用 netns 测试了 v4 ，好像没有理睬用 ip l s mtu 设置的 mtu ，设置为 1480 仍然是按照 1500 拆包的

用单个 wg 的话
给自己发 4 个配置文件，然后起 4 个 wg 隧道
假如四个 wg 客户端 ip 分别是 198.51.100.1-198.51.100.4 ，接口分别是 wg1-wg4
那么可以加路由
ip r a default dev wg1 table 1001
...
ip r a default dev wg4 table 1004
然后加规则
ip ru a f 198.51.100.1 table 1001
...
ip ru a f 198.51.100.4 table 1004
然后加出口 nat 规则（可能需要适当调整一下，比如结合默认路由的 srcip ）
iptables -t nat -A POSTROUTING -m statistic --mode random --probability 0.25 -j SNAT --to 198.51.100.1
iptables -t nat -A POSTROUTING -m statistic --mode random --probability 0.33 -j SNAT --to 198.51.100.2
iptables -t nat -A POSTROUTING -m statistic --mode random --probability 0.5 -j SNAT --to 198.51.100.3
iptables -t nat -A POSTROUTING -j SNAT --to 198.51.100.4
然后就可以把不同的连接丢到不同的 wg 上了……
必要时调整 rp_fillter 。

如果用多个 wg ，或者其他 vpn ，可以考虑类似 ecmp 的实现，或者分别随机打标签……
单个 wg 不能这么做是因为客户端地址是同一个的话，wg 这种三层 vpn 没办法路由到不同的客户端去。

确实是天天 vpn 回家，然后出国策略什么的都在家里路由器上
不过呢
家里挂了就很难受

分配 fd 开头的私网 v6 然后做 nat/snpt

移动去什么北美
香港，新加坡，日本
它不香吗
北美的话推荐用联通

北京移动也有一批“神秘 ip”是这么处理的
实测只影响家宽和蜂窝网
idc 还是普通路由

问题是，
谁同你 peer 呢？

图片中第二个包（ ttl=87 ）显然是墙回的，这个包中断了连接
第一个包很有可能也是墙回的
问题根源是墙
解决方案是用境外手机卡漫游开热点

二百多 GB 就上门拍照啊？也太事儿了吧

旁路由的 wan 口接主路由的 lan 的话，就相当于二级路由，
* 对在这个路由器下面的设备来说，这个设备就是主路由，
* 但是对于接到原本的主路由上的其他设备来说，绝大多数情况下无法使用这个旁路由

@neos2014
不管用 openvpn 还是 wg 还是其他东西，都可以这样指定 vpn 客户端的下一跳（在 vpn 服务器上）：

ip ru add from vpn 网段 table xxx
ip r a default via 旁路由 table xxx
会把所有流量转发给下一跳（你的例子是旁路网关），所以翻墙策略都是可用的
必要时可能还要 snat 一下，取决于下一跳的配置：iptables -t nat -A POSTROUTING -s vpn 网段 -o 去下一跳的网卡通常是内网网卡 -j SNAT --to 一个下一跳接受的内网 ip

命令都是手敲的如有报错敬请见谅

tailscale 其实是多点互联用的……这里只做出口的话，openvpn server 就相当于 exitnode 了

同 2 楼，基于 linux 一般发行版自己搭一个
按照自己的喜好添加模块扩展功能
~~极其稳定~~ （虽然结果上是这样没错）
极其考验设计和实现

我家情况类似，联通+移动，常年 openvpn 回家
基于 rockylinux 的软路由做核心路由器
1. ddns：用自己的域名开策略解析啊。维护两个子域名（我都有公网所以都是双栈，其实一个双栈一个只有 AAAA 也没问题），然后自建了一个策略解析 dns 服务器，也可以买国内的带策略解析服务的 dns 服务。udp 跨不跨运营商体验云泥之别。
内网如果忘了关 vpn 的话，建议再加个内网 dnsmasq 记录直接把 vpn 域名劫持到 vpn 服务器上。
不想搞这么复杂就弄两个 ddns ，自己手工选择。
2. 翻墙：这种事情……旁路由的话得 vpn 出来指向旁路由，虽然也不是做不到就是了。ip ru add from vpn 网段 table xxx ，ip r a default via 旁路由 table xxx ，大概这样，必要时可能还要 snat 一下。主路由都这么复杂了干嘛还念念不忘旁路由呢？
3. 为什么这里没有用 wg ？
a. openvpn 支持两种协议，爱开 tcp 就开 tcp ，爱开 udp 就开 udp 。
b. wg 只在连接的时候解析一次域名，当然会有保活检测，这里还需要一个网络变化重新解析域名的。比如我手机也是联通+移动双卡，切换网络甚至回家之后就希望用新的 ip 连（会比较快）。不知道有没有合适的客户端。跨运营商这种事情真的就是中国特色。
c. 2024 年了，越来越多的设备都有硬件 aes ，没必要死磕 cpu 去算 chacha20 。
b+. 为什么回家还要开 vpn 呢？还是中国特色，总有恶心的 app 想通过运营商接口偷窥我手机号，直接给他个 vpn ，嘿嘿。