在之前的文章中，我已经配置了各种各样奇怪的东西。拜它们所赐，虽然现在的网络不是不可以用，但是一旦想要修改就特别麻烦。
因此我制定了这个计划，其目标是用多个部分融合来模拟甚至超越 Surge 的效果。需要实现的功能包括但不限于：
- 网关级透明代理
MITM- 高扩展性的请求/返回修改
- 局域网
DNS代理接入 - NAT Type A
- …
运行环境
首先需要声明的一点是，这个计划和路由器是无缘的。为了满足 MITM 的性能要求，本计划的运行环境为本人目前手上的笔记本电脑
树莓派能不能达到性能要求我也说不准，毕竟我手上没有（笑）
功能解释
下面来简单介绍一下各个部分的功能吧。虽然并不一定会有读者（笑）
网关级透明代理
简单来说，就是使以本机作为网关的其他设备能够实现透明代理。实现这个功能的方法很多，大致可以分为 Redirect、TProxy 和 Tun/Tap，这个计划也会选择上述三种之一。
MITM
如果想要以非请求者的身份获取/修改 https 请求的明文内容，那么就必须 MiTM 了。MiTM 的原理是自签名，因此需要让使用 MiTM 功能的终端信任自签名的 CA 才行。因此如果是 Android 7 以上的 Android 系统就无缘了。
但是这个功能仍然是必要的，因为除 Android 以外，iOS 等是支持信任用户导入系统级 CA 的。并且 MiTM 能够做到的事情非常多，诸如绕过 Abema 地域限制等等都可以做到。
高扩展性的请求/返回修改
这个功能是基于上面的 MiTM 的。既然能看也就能改，这应该也是必然的吧（笑）
问题就出在这个高扩展性上。目前使用的方案是 MITMProxy，虽然确实挺方便，但遇到需要修改或调试的话，事情就变得麻烦了。在 Project Glow 中，需要找到一种方便的调试手段。
局域网 DNS 代理接入
这个功能对应的是之前那篇讲 SNI Proxy 的文章，但是那篇文章的配置实际上是有一定问题的，不知道大家注意到没有（
首先是 http 的问题。虽然 http 已经解决了，但拜它所赐，现在本机的所有网站都不能搭建在 80 端口了。这是一个非常迫切需要解决的问题。
其次，如果本机需要提供 https 服务（虽然不太常见），在那篇文章的配置下是做不到的。
最后，那篇文章使用了非常 hack 的手段来解决本地 DNS 冲突的问题。通过将所有 INPUT 链中目标端口为 53 的 UDP 请求的目标端口都替换成 5353，我们看似解决了本地 53 端口占用的问题，但事实真的是这样吗？这里就当留给
NAT Type A
这个功能对于游戏而言还是挺重要的，需要的都懂，不需要的也用不上，这里就不多赘述了（
基本架构
如上图所示，想要达到上述目标，我们的基本架构就是这样的了。这里为了看起来清楚点用 Packet Tracer 瞎几把画了个图，实际上并不会（悲）
可以看到，这里描绘的是 AP 模式下的工作状态。各设备通过 AP 连接至本机；本机将所有流量转向第一层路由，决定是否需要经过 MITM；经过 MITM 或否的流量再流经第二层路由判断需不需要代理；最后将请求发往对应的服务器。
这个结构对 SNI 代理也有效。SNI 代理相当于监听了 80/443 端口，在它们请求原服务器的同时流量也会被 MITM Judger 处理。
待解决的问题
当然了，饼画得很好也就意味着随之而来的问题也会接连不断。下面就是这个计划面临的一些问题了。
Tun 还是 TProxy？
虽然前几个月我从 TProxy 切换到了 clash 的 Tun 模式，但是实际上我并没有享受到这个模式的红利，反而增加了维护成本，并且 GitHub 上也有反馈网速问题的 issue[1]。
从事实来看，使用 Golang 实现的网络栈必然会比 C 要慢。虽然这是无可奈何的事情，但我是不是可以简化这一步，使得这个流程相对更加内聚呢？
双层的 MiTM Judger 与 Rule-based Proxy
从逻辑分层上来说，MITM Judger 和 Rule-based Proxy 是两层的；但是从实现角度来说，我们又希望这个过程能够合并成一个应用。
其实分成两层的根本目的是希望经过 MITM 的请求还能根据规则选择代理，那么我们能不能单独增加一种规则类型，然后再开一个端口，从这个端口进入的流量都绕过这些规则呢？这样的话我们甚至可以配合防火墙实现某些 IP 段启用/禁用 MITM，保证 Android 系统的正常访问。
这些修改意味着我们需要修改 clash 的实现，不过我找到了这个：
如果有空的话我或许会选择把它集成进 clash 里。
MiTM 持续服务
在目前的部署下存在非常致命的问题：当需要重新启动 MiTM 部分时，所有的 MiTM 流量都会被中断。我们需要解决这个问题，或是使用 MITMProxy 的热重载，又或是其他方法。
DNS 解析
正确的 DNS 解析是访问现代互联网的前提。而与之对应的，SNI 代理又有修改部分 DNS 解析的需求。我们希望把这两个过程合并，根据请求的 IP 返回对应合适的解析。
例如，我们希望将 192.168.1.0/24 配置成使用 SNI 代理的网段。这样的需求在目前是无法实现的，具体如何实现还需要看之后的研究情况。
目前的一个迫切问题是 clash 在执行一段时间之后就会串 IP，导致证书错乱。这是很严重的问题，需要尽快解决。
整合各部分的配置
刘大爷在实现完这么多功能之后一定也注意到了：很多需求是需要多个功能配合实现的。我估计也正是因为这个原因，刘大爷推出了 Surge 的模块系统。
在这个计划中，我们也需要这样一个整合多个部分的系统。或许是直接的类似系统，又或者是能够方便操作的命令行工具之类的，总之不能纯手动配置各个部分（笑）