项目背景介绍
我家的emby以前只有2,3个朋友在看，没有考虑那么多，就用的一个未备案域名然后直接在爱快上做的端口映射，直接映射到NAS上安装的emby的内网http端口上就完事了。本来这也没什么，不过自从电信出上那一档子事(详见以前的文章：家庭数据中心系列 有公网IP的家庭宽带建站注意事项)，然后觉得未备案域名加http明文太过于危险，于是有了优化emby发布方式的想法；然后想到现在IPv4公网地址这么精贵，不得不防什么时候电信打着遵守国家"网络强国"政策的旗号强行收回IPv4公网地址，所以干脆优化一下我的家庭数据中心的整体架构，提前为未来只有IPv6公网地址的建站做好准备；最后又想，既然项目规模都搞那么大了，干脆趁机把家庭数据中心的流量访问逻辑梳理一下，结果就有了这个项目：家庭数据中心v4v6双栈网络架构及应用访问流程优化。
本身只是想随便水一篇文章的，结果一不小心就把项目搞大了？？措不及防啊，这就是"一个emby引发的血案"？
原有环境分析
原来的环境流量逻辑比较混乱，如下图：
腾讯云CDN回源的请求是经电信1线路到达爱快，cloudflare的tunnel访问请求经电信3线路到达爱快，emby的http请求经电信2线路到达爱快，关键是经过爱快软路由进入家庭数据中心内部的访问流量没有统一的流量处理逻辑。
从上图可以看出，访问流量到达内网应用的途径有3条：
1、爱快上直接做端口映射到应用(代表应用emby)，跑的是还是明文http(电信看在眼里，只是没吱声)。
2、爱快端口映射到v4网关(就是宝塔linux面板)的指定端口(https)，然后v4网关进行SSL卸载以后通过反向代理直接指向应用。
3、爱快端口映射到WAF，然后WAF对访问请求进行安全检查以后通过反向代理指向应用，这里的应用也包括v4网关，为什么呢？因为有些应用我以前贪图方便所以直接源码部署在了宝塔面板上。。
综上所述，整个网络的流量逻辑实际上乱七八糟。。当然，这个主要是历史遗留问题，也不能只说我懒～。
除了流量逻辑乱起八糟，ipv6我也完全没有利用起来，白瞎了v4/v6双栈环境了。同时，也没有足够的安全预案，比如，如果受到ddos攻击以后怎么办？如何牵引攻击流量到流量清洗(cloudflare)？总之问题多多啊。
优化改造后逻辑拓扑
经过一番折腾，优化改造之后的逻辑网络架构如下图所示：
入向访问流量线路分配
1、腾讯云CDN的回源流量从电信1线路进入
实现该目标是通过爱快"高级应用"-"动态域名"功能将电信1口的公网IPv4地址实时更新到域名B之后：
将腾讯云CDN上对应的加速域名的回源地址指向域名B：
2、cloudflare的tunnel访问流量从电信2线路进入
实现该目标是通过爱快"流控分流"-"端口分流"功能，将部署cloudflare tunnel的设备指定从电信2线路出去，这样cloudflare就会以电信2口的IPv4公网地址进行连接：
3、阿里云CDN的IPv6回源流量从电信3线路进入
实现该目标是通过爱快"网络设置"-"IPv6"-"IPv6设置"页面支持在多线路环境下指定启用IPv6线路这个功能，从而在电信线路3上启用IPv6，这样IPv6流量就只能从电信3线路进入了：
因为IPv6都是走公网路由，原有IPv4的端口映射功能已经失效，而爱快暂时还不支持IPv6—>IPv4地址的端口转发功能，所以，IPv6回源流量到达v4/v6网关需要配合爱快的动态域名功能实现(也可以由v4/v6网关自己运行动态域名功能，这种方式准确性更高，爱快获取其他设备的IPv6地址要看情况，如果是有状态IPv6地址的准确性没问题，但是如果是无状态的，只能通过其他设备的mac地址获取，这种有时候会获取失败)。
从安全角度考虑，可以在爱快上启用IPv6防火墙的功能，指定访问目标只有匹配v4/v6网关IPv6地址后缀和特定的目标端口(例如反向代理端口、tcp、udp类端口转发端口)的请求才能通过，而访问其他内部IPv6公网地址的请求都进行阻断，这样可以大大提升内网IPv6地址的安全性。实现该目标是通过爱快"安全设置"-"ACL规则"功能来实现的：
4、其他入向流量线路分配
emby访问入口现在分配到电信线路3，使用的备案域名访问，而挂PT的transmission的数据入口分配到电信线路1。之所以这么分配是因为emby访问的域名会导致我的电信线路3的公网IP暴露，如果遭受DDOS的大流量攻击我可以直接断掉电信线路3，反正主要也是emby和IPv6备用线路使用电信线路3；而电信线路1本来就是用来作为腾讯云的回源线路，平时也不会有太大的流量，干脆用transmission来废物利用一下。
访问我com域名的clouflare的入向流量走的是电信线路2，同时电信线路2也是我的上网线路，断掉电信线路1和3也不会影响我com域名的访问，同时也不会对我正常上网有任何影响。
v4/v6网关
对v4/v6网关(原有的宝塔linux面板)进行优化：
1、迁走源码部署的应用
将所有源码部署的应用迁移到docker区的nginx上(docker方式部署nginx+php参见：docker系列 单容器nginx、单容器php(一个版本)之多站点共用)。
2、对所有站点启用ipv6支持
宝塔linux面板的nginx默认安装时已经加上了"–with-ipv6"模块，所以只需要在对应站点配置里加上以下代码即可：
listen [::]:443 ssl http2; #具体端口大家根据自己实际情况修改，比如本例中是55555如下图：
如果是单独安装的nginx，可以进入nginx的文件目录，使用./nginx -V 查看已安装的模块，如果有--with-ipv6，则表示已安装此模块，否则需要重新编译安装。
3、所有站点启用SSL加密
为了应对以后只会越来越严峻的环境，所有站点都必须启用SSL加密(包括emby)，证书使用宝塔面板内置的let’s encrypt证书就好，如果主域名下主机数量超过20，可以使用ohttps(参见文章：家庭数据中心系列 SSL证书一站式管理工具OHTTPS使用教程)，v4/v6网关对外提供唯一的站点监听端口(例如tcp 55555，同时所有站点均要添加该监听端口)，同时供爱快软路由上电信IPv4公网地址做端口映射及阿里云CDN IPv6回源地址对应的端口使用。
所有SSL解密都必须在v4/v6网关上完成，内网理论上都只跑http，个别特殊应用除外(比如DOH)。
4、阿里云CDN IPv6的回源地址
其实为什么我要在已经有腾讯云CDN的情况下又引入阿里云CDN？因为腾讯云CDN回源目前只支持IPv4地址：
这就很坑啊，而阿里云CDN支持IPv6回源：
所以如果以后真的没有了IPv4公网地址而那时候腾讯云还不支持IPv6回源的话，我就只能被逼全面转向阿里云CDN了。
阿里云的回源地址需要直接指向v4/v6网关的IPv6公网地址对应的动态域名，这个也需要通过爱快"高级应用"-"动态域名"功能来实现：
爱快IPv6的动态域名解析可以根据内网某个主机的mac地址、DUID2种方式来获取内网主机的IPv6地址，并将该主机IPv6地址更新到用于阿里云CDN回源的域名A中，所以在阿里云CDN中的回源地址处填写域名A，端口指向v4/v6网关的监听地址55555即可：
注1：其实还能在腾讯云CDN里把阿里云的地址加为热备源站，这样如果哪天忽然收回IPv4公网地址也不会影响我国内域名的访问。
注2：爱快软路由的IPv6及IPv6动态域名配置参见：爱快软路由系列 爱快IPv6功能配置教程。
5、爱快软路由端口映射
删除爱快软路由IPv4公网地址所有直接指向家庭数据中心内部的端口映射，只创建唯一一条端口映射指向v4/v6网关的站点监听端口，本例中是指向tcp 55555端口。
注：腾讯云CDN回源指向的55555端口其实是爱快软路由上电信线路1上配置的端口映射的端口，实际上v4/v6网关上的端口可以不必是55555，但是阿里云CDN回源指向的tcp 55555端口却是v4/v6网关上的端口了，为了统一，干脆在v4/v6网关上的ipv4和ipv6的监听端口都设置成55555。
6、在v4/v6网关上部署v6–>v4的端口转发
对于非http类型的应用(例如魔兽世界服务器端)，无法通过反向代理的方式进行部署，而只能使用端口转发从IPv6公网地址的特定端口直接转发到内网IPv4私有地址的特定端口，这需要部署lucky来实现(详细lucky的部署配置参见：docker系列 使用docker基于lucky搭建简版公网IPv6访问入向网关)。
7、v4/v6网关下一跳指向
所有入向访问请求，在经过v4/v6网关进行SSL解密之后，都需要通过反向代理的方式指向下一跳的WAF设备进行安全检查（宝塔linux面板的反向代理配置步骤参见：linux面板系列 配置反向代理并使用非443端口进行发布）。
虽然原则上v4/v6网关上接收到的所有的入向请求都应该通过反向代理的方式指向下级的WAF进行检查，不过一些特殊应用需要绕过WAF(例如emby的访问流量)，这是因为从emby服务器返回的流量太大，全经过WAF，估计WAF撑不住。其实最好的方式应该是DR模式，既从emby服务器返回的流量直接绕过WAF返回v4/v6网关，但是仅仅为了一个应用这么折腾我觉得性价比实在不高，只能暂时忍了。
所以最终的折中方式，emby的访问请求直接从v4/v6网关上通过反向代理绕过WAF直接指向emby服务器。
8、v4/v6网关本身的加固
其实本来nginx本身也是需要加固的，不过一来经过了CDN，源站的IP地址没有暴露，二来v4/v6网关上的nginx只是做SSL解密和反向代理(源码部署的应用已经迁移到了docker区NGINX)，所以也没啥必要折腾了，唯一可以做的就是配置一个虚假的默认站点来应对IP扫描，避免泄露站点域名。这个网上教程很多，我这里就不详述了，记得使用虚假的SSL证书。
WAF
cloudflare因为自带流量清洗和WAF功能，所以通过tunnel进入内网的访问请求我都是比较放心的，可以直接指向了docker区的应用。但是对于国内CDN进来的请求，这个就要非常小心了，所以WAF就非常重要：v4/v6网关上除了emby之外的所有对内部应用的访问都要先指向WAF，经过WAF的检查。
具体配置根据WAF不同而不同，我是用的长亭雷池的社区免费版，主要进行语义分析和高频访问/攻击限制：
从com域名过来的访问，特别重要的应用(比如博客)，我也过了WAF，为的是和国内域名过来的访问数量进行对比以及提供最后一段防护：
(可选)NGINX负载均衡
因为我有docker1区(macmini)和docker2区(inter mini主机)，都部署了NGINX，所以有负载均衡和应用高可用的需求，至于这里是用NGINX还是HAproxy或者zevenet-ce来做负载均衡，就看大家各自的习惯了。
zevenet-ce的界面，讲道理还是可以的，关键社区版免费。。基本的服务器负载均衡功能都有(截大图就不清楚了，大家将就下，看个大概就行)：
不过最终我选择了nginx的stream模块来实现的4层负载(7层负载暂时用不上)，因为感觉更加轻量级，使用的nginxWebUI解决没有图形界面的问题：
因为目前流量不大，所以采用主备的方式部署来实现博客的高可用。
docker系列 使用docker基于nginxWebUI搭建图形化的nginx
安全预案
这个安全预案，主要针对的是大流量DDOS攻击的应对方式(非大流量攻击需要靠WAF之类的设备处理)。一般正常项目中如果用户是购买的供应商(运营商或者云服务供应商)的云清洗服务，一旦监测到异常流量，供应商就会将异常流量牵引到流量清洗设备进行清洗，然后再把清洗过后的访问流量送回给用户。
但是，我一个屌丝博主可没钱搞这些。。那咋办？只能想办法尽量利用手头现有的资源了。com域名是放在cloudflare上的，不怕ddos攻击，需要安全预案的主要是国内的通过腾讯云或者阿里云CDN过来访问cc域名的流量，那么如何操作呢？
1、利用CDN上的部分特性抵御攻击
IP访问限频我都要配置，100QPS正常应用也足够了：
用量封顶，超过设置的封顶数值直接关闭CDN，这里需要大家根据自己网站实际的访问量设置：
禁用TLS1.0，其实1.1也可以考虑禁用：
2、WAF的高频访问限制和高频攻击限制
经过CDN的访问频率限制进行初步筛查，WAF可以再筛查一次，同时限制高频攻击行为。
3、cloudflare流量清洗
cloudflare free计划经过简单配置之后即可进行流量清洗功能，只不过默认提供的CDN IP不是优选IP，用户访问比国内CDN慢不少而已。但是，关键时候慢总比打不开好吧(而且可以手动测试并填写优选IP)？所以可以把cloudflare作为万不得已时候(已有的安全策略已经无法阻挡攻击)的防护方式。
如何操作呢？就是把国内域名以自定义主机名的方式接入cloudflare：
只不过平时分为境内和境外2个解析结果：境内范围的访问直接用cname的方式指向国内CDN厂家的地址，而境外直接以A记录的方式指向1.0.0.5即可：
这样，一旦发现DDOS攻击行为，可以直接把CNAME记录暂停，然后把A记录的"境外"范围改成"默认"即可，后续新攻击再解析你的域名就直接解析到1.0.0.5上了，然后就打到cloudflare的anycast IP上，从而进入cloudflare的流量清洗范畴。
不过这种方式对已经存在的攻击是无效性，因为别人已经通过域名解析把攻击打到你现在IP上了，所以对于我来说，还有一步操作，就是断掉电信线路1并重新拨号，由于动态IP机制电信线路1就获取了新的IPv4地址，后续攻击也打不到我了。
相比购买昂贵的云清洗服务以及自己购买DDOS设备，咱这种方式就是反应速度慢，需要人工干预，但是胜在免费。。当然，这一套只适合个人站点，如果是商业站点，就不要省这些小钱了。
后话
通过这篇文章，我发觉还真应了古人一句老话：好记性不如烂笔头。上文这些知识都是平时常用的，也没觉得有啥，但是当我把这些下来，并且需要写一些总结性质的结论的时候，还是发现一些平时没注意到或者没有去深入思考的细节，果然，坚持写博客的确是很有益处的。
另：4月17日，一觉醒来，多拨没了，虽然知道迟早有这么一天，但是也没想到这么快，这样下去IPv4公网地址可能也快没了，虽然对我影响不大，但是这么多年了还是有些伤感的。
