前言
在以前的文章中，我用虚拟机的方式部署了openwrt(参见：OpenWrt软路由系列 PVE部署OpenWrt(23.05.2)详细教程)，除了这种方式，还可以裸机直接装openwrt以及使用docker部署openwrt的方式，裸机安装不谈，我想谈一下我对docker版openwrt的使用方式的看法，毕竟docker方式最简单，是更多人愿意采用的首要选择(具体怎么部署我就不写了，网上教程很多)。
先谈谈"旁路由"部署
在前一篇文章(软路由系列 爱快+openwrt最佳部署方案探讨(再见吧，旁路由))中我提到过，从网络角度来讲，就没有"旁路由"这种说法(路由就是路由，不要加什么定语)，从网络专业的角度来说，这种实现效果应该叫做：单IP混杂模式收包、转发同时进行NAT。以前这种类似的需求在一种特殊的部署方式：单臂模式(one-arm)中出现过，比如负载均衡设备，就经常有单臂部署的情况，感兴趣的朋友可以看看下面这张图：
在单臂模式这种部署情况下，负载均衡设备只通过一个三层接口连接到服务器的同一个网段，按照正常的配置逻辑，负载均衡设备需要对访问vip(服务器上需要负载的应用对外发布的虚拟ip地址)的请求同时进行dnat(目标地址nat)和snat(源地址nat)。dnat是负载均衡的最基本操作，而snat就要看具体情况来配置了，比如服务器要求能看到客户端的真实源IP地址(以前有些老的应用需要获取客户端IP但是又不支持从X-Forwarded-For获取)，所以负载均衡设备就不能对访问vip的请求启用snat，这个时候就必须要服务器的默认网关指向负载均衡的三层接口IP，对服务器而言，这不就是"旁"路由的部署方式了？
不过，虽然支持这种部署方式，但是其实从负载均衡厂家的角度来讲，却从来不推荐这种部署方式(都是推荐X-Forwarded-For)，只是没办法而已，具体从技术上来分析太繁琐了，简单总结就是：浪费负载均衡设备性能、容易引发服务器上一些稀奇古怪的问题(毕竟莫名其妙多了一跳)、复杂了网络结构(不利于运维和排错)。
上面的结论把负载均衡设备换成openwrt一样是适用的。
"旁路由"唯一的好处就是简单，只需要客户端把默认网关往openwrt的接口IP上一指就好了，但是却带来了一系列的问题：openwrt出问题就网络中断、openwrt的大部分性能消耗不是科学而是正常上网的流量处理、如果主路由有端口映射到客户端可能会导致端口映射无法成功、需要更改网络结构(修改客户端默认网关)等。
再谈谈docker部署方式
docker这种部署方式有哪些优点呢？随便在网上一搜：持续部署、版本控制、可移植性、隔离性和安全性，大家注意，这些优点可没有稳定性和性能，而docker的稳定性和性能是靠集群技术来实现的。
到不是说单独的docker性能和稳定性就一定不好，只是在我实际的使用中，感觉同样的部署方式，docker的稳定性比直接部署在linux中的稳定性差了一点点，比如cloudflare的tunnel，docker方式部署的偶尔会抽下风(流量越大越容易出现)，而直接部署的却稳定得一逼。同时，我觉得docker方式部署最适合的是对外提供内容的应用(比如nginx，mysql)，而不是需要频繁从容器内部访问外部网络这类(比如lucky、cloudtunnel、openwrt)，比如看看lucky作者的说明：
docker hub上"shellspec/openwrt"(docker版openwrt绝大多数都是安这个版本)的说明：
所以从这些角度来说，docker版的openwrt也不太适合用来做"旁路由"网关，更不用说"旁路由"本身就不科学了。
docker版openwrt怎么用？
其实，一般人群对科学的需求，只是占正常上网需求的很少一部分，所以最理想的解决方式，就是正常上网的请求正常走，需要科学的请求特殊走。
需要科学的请求细分开来，又分为：浏览器科学、app科学、cli科学。
1、浏览器科学
浏览器科学的解决方案是上网插件，比如chrome、edge浏览器就用smartproxy，除了学习阶段需要点一下鼠标，后面用起来就轻松愉快了。
2、app科学
比如macos、win下的app的需求，可以使用proxifier来解决，参见我另一篇文章：家庭数据中心系列 使用proxifier让不支持而又需要使用代理的应用走代理。
3、cli科学
这类主要包括没有图形界面的情形，比如linux终端下命令的科学，这个可以使用proxychains来解决，参见我另一篇文章：家庭数据中心系列 强大的局部代理工具：proxychains。
这3类解决方案就离不开一个关键点：你得有个靠谱的高性能的代理，所以这个时候，openwrt闪亮登场了。
docker版的openwrt，我觉得最合适的就是提供这种代理了，如果你本来就打算使用openwrt进行科学，你肯定已经有了科学的前提条件，这个时候使用openwrt打通了科学的大门以后，只需要同时提供代理服务就好了。至于提供代理的方式，如果是openclash，本来就是自带的：
其他的插件我不太熟悉，我记得以前的科学上网插件也是默认提供socks5代理的，退一万步来讲，就算没提供，也可以通过安装gost来实现(关于gost的详细使用教程，参见：家庭数据中心系列 使用gost搭建自己的代理服务器及转发代理链)。
采用代理这种方式，虽然和"旁"路由这种方式比起来，开始的准备工作多了些(唯一的缺点)，但是好处也很多：
1、docker版的openwrt工作量大大减负了，可以更加专注于科学本身，所以稳定性也提高了
2、不需要改变原来的网络结构(不用手动改客户端默认网关或者修改dhcp默认网关的指向)，大家不要小看这点，你去客户哪里做实施的时候这点很重要，要改网络结构会麻烦很多
3、docker版openwrt出问题也不影响正常上网(重启docker或者重建一个docker也不废什么时间)
4、流量逻辑清晰，运维和故障抓包排查都非常容易(有运维经验的朋友就知道这有多重要了)
5、不用为了一个docker去把宿主机网卡设置为混杂模式
6、上网流量在客户端本地就进行了分流操作，发往代理的流量都是需要科学的，这比依赖于clash之类科学软件本身的分流要准确得多
后话
说了那么多代理方式的好处，其实"旁路由"部署也不是一无是处的，可以作为一种应急的手段，比如：部署了一个全新的linux系统，上面啥都没装，想使用apt update然后安装openssh-server结果等死人，然后想编辑sources.list文件改可用源结果用不惯vi，想下vim结果还是下不动(我一个朋友以前就经常遇到)。碰到这种尴尬的情况，有"旁路由"的话，直接修改默认网关指向"旁路由"就解决了(能够熟练使用vi的高手就当作没看到就好～～)。
