@
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 年之前的事情了。