方案背景

随着各运营商对IPv4公网地址的越发收紧(成都电信要399以上套餐加100元每月的服务费才能有ipv4公网地址，并且对于有公网IPv4地址的老用户，现在就算是升级套餐IPv4公网地址也大概率没了，我一直在坚守老套餐，也不知道能坚守到什么时候)，IPv6的普及是迟早的事情(当然，其实现在很多运营商的IPv6在骨干网上的支持都是没问题的，但是在局端方面就难说，很多上门装机的人员甚至根本就不知道啥是IPv6，我的IPv6地址都是投诉过后又折腾了很久才有的)。

而因为IPv4和IPv6的不兼容，导致无法直接通信，所以在IPv6一统天下之前，IPv4和IPv6会共存很长一段时间，而为了解决共存期内IPv4和IPv6的互访问题，出现了很多过渡方案：
1、双栈

同时提供IPv4公网地址和IPv6公网地址，DNS解析同时解析A记录和AAAA记录，这样不管访问用户是IPv4地址还是IPv6地址，都通杀。对于一般中小型企业而言，只要通过CDN发布，都可以轻易实现双栈的功能(必要工作CDN都帮你做了，当然，使用要给钱)；而对于一些数据中心自建的大型企业来说(例如地方银行)就需要自己找宽带运营商申请固定IPv6公网地址然后自己在出口设备上配置了。
2、6to4

用于IPv6设备通过IPv4网络与远端IPv6设备通信，简单来说就是在IPv4网络上搭建隧道承载IPv6通信，隧道两端的节点需要同时支持IPv6和IPv4地址并进行正确的6to4配置。
3、DNS64+NAT64(动态)

这个方案需要DNS64服务器和NAT64设备的支持。简单来说，就是IPv6 only的用户将DNS查询发往DNS64服务器，DNS64服务器会先查询该域名是否有AAAA记录，如果没有的话，会查询对应的A记录并得到IPv4公网地址，然后用特定的96位前缀(内网是使用64:ff9b::/96)和32位IPv4公网地址组成一个128位的完整的IPv6地址并将其作为解析结果返回给IPv6 only的用户。

用户访问该目标地址的请求到达NAT64设备(需要同时支持IPv6和IPv4)，NAT64设备会从目标地址中提取出真实的IPv4地址并将该请求转换成IPv4的正常请求(同时根据设置的IPv4地址池进行nat转换)发往IPv4服务器并同时记录到session表，得到响应后根据session表，将响应转换成IPv6报文并返回给IPv6 only的用户。
注1：公网上也有少量免费的IPv6地址能提供DNS64的功能(同时也提供配套的NAT64)，虽然是免费，但是一般都有某些实验性质，速度也不好说，大家可以去以下链接寻找：https://nat64.xyz/，如下：

注2：还有一种NAT64的静态方式，不过这种方式主要是解决IPv4客户端访问IPv6的问题，和我们主题不符，这里不涉及。

上述这3种方案中，第2种和第3种都是运营商(或者大内网)级的方案，第1种到是可以用在家庭宽带，但是如果真有IPv4公网地址的直接做个动态域名就行了，还搞什么IPv6？我这种IPv4+IPv6双栈的天选之人毕竟是少数～。

所以真正有价值的解决方案，是针对IPv6 only的家宽用户的入向需求(出向需求使用IPv4私网或者IPv6公网地址都可以，这取决于访问目标的DNS解析结果是否包含AAAA记录以及访问客户端操作系统对于IPv4和IPv6优先级的设置)，本文就是以这个为大前提撰写的。

---

另：IPv6公网IP最大的问题其实是在于要求访问客户端也具有IPv6地址，这个就很有挑战了，一般企业的商务光纤、酒店、其他商务场所、或者其他一些家庭宽带都未必开通了IPv6，所以本质上要解决这个问题还是需要经过CDN。而CDN如果采用cloudflare，free计划已经具备了比较强大的安全防范，加上tunnel这种方案，回源流量也不走公网，其实才不管你是IPv6公网地址还是IPv4私有地址，直接通杀了，也就没有这个需求；而如果采用国内的CDN(需要备案)就需要走公网，这种其实才是需要安全解决方案的，所以文章的题目才叫"家庭宽带IPv6公网地址入向访问解决方案探讨"。

---

出口方案的选择：路由器中心化与路由器边缘化

传统的有IPv4公网地址的家宽方案中，宽带路由器对外进行外向请求的NAT，对内则是通过端口映射来进行内向请求的准入和传递工作，这种方式其实是我们最习惯也是最好制定安全策略的方式。只不过，到了IPv6时代，宽带路由器本质上变成了一个IPv6公网地址分发的承上启下者：从上游设备获取被分配的60位前缀，然后从16个(注：64-60=4,2^4=16)可用64位前缀的网段中选择一个(一般是第一个)，最终以有状态或者无状态的方式将IPv6地址分发到内网中，这和传统的IPv4公网地址终结于路由器的wan口有本质的差别，所以就会衍生出2种不同的实现方式，而不同方式有各自的优点和缺点。

方式1：路由器中心化，终结入向IPv6流量

这种方式仍旧将对外发布应用的IPv6公网地址终结于路由器的wan口，既使用宽带路由器wan口的IPv6公网地址，例如我爱快的IPv6是启用在adsl3口上，所以adsl3口上有一个IPv6的地址，如下：

所以如果爱快支持adsl3接口的IPv6地址到内网IPv4地址的端口转发，就完美复现了IPv4端口映射一样的效果，但是现在的关键问题在于，爱快并不支持IPv6地址到内网IPv4地址的端口转发～。

所以如果要使用路由器中心化的方式，主路由需要换成openwrt。

openwrt的安装、基本设置及IPv6相关的配置网上教程很多，我这里就不多说了，并且openwrt也不是主角，而只是主角的载体，真正的主角是lucky。通过在openwrt上部署lucky，则可以直接实现基于openwrt wan口IPv6公网地址的动态域名解析(openwrt自带的ddns不支持常用的国内域名供应商，还是要用lucky带的动态域名解析)；实现wan口IPv6公网地址到内网多个IPv4私有地址的web应用的反向代理、到内网IPv4私有地址的tcp、udp端口转发等，所以目前看来openwrt+lucky的搭配是路由器中心化的最佳选择(socat应该也可以，只不过我没有用过，没啥发言权)。

另：其他路由系统如能实现类似功能的其实都可以，不过我没研究过，所以不知道，其实最期待爱快能实现这个功能～。

不过，这种方式的缺点和优点都很明显：
1、缺点
依赖openwrt做主路由，具有较强的限制性(比如我的主路由是爱快，用于多拨和分流，不可能将主路由换成openwrt)，所以只适合于本来就将openwrt做主路由或者愿意用openwrt做主路由的人群(这种人群占总体人群的比例较小)。
2、优点：
内网设备的IPv6地址不用考虑发布的问题(甚至可以不启用IPv6，仍旧只使用私有IPv4地址)，从运维角度来说轻松了很多。

期待以后主流的商用路由器也实现类似的功能，那个时候就有更多选择了(除非你有其他特殊需求)。

方式2：路由器边缘化，以专用的设备终结入向IPv6流量

这种方式本质上就是让路由器只做好IPv6地址的传递分发工作，将对外发布IPv6地址并终结IPv6流量的工作让给专用设备去实现。这个专用设备比较灵活：可以是个虚拟机，也可以是个LXC(linxu容器)，甚至可以是个docker。

以我家目前的专用设备为例，是一个LXC，部署了nginx作为反向代理以及lucky来实现端口转发，如下图中的红框所示：

如果大家需求比较简单且只是自己、家人、朋友使用，可以直接使用lucky的端口转发功能将访问IPv6公网地址特定端口的访问请求转发到内网私有IPv4地址的端口上(就跟以前配置宽带路由器端口映射一样)；如果需要使用反向代理而要求又不是很高，可以直接使用lucky自带的反向代理功能来实现(lucky的相关配置参见我另一篇文章：docker系列 使用docker基于lucky搭建简版公网IPv6访问入向网关)。

这个时候其实就是把lucky当作专用设备的核心了，如果流量大建议采用非docker的方式进行部署，流量不大docker方式也可以，不过网络类型尽量使用host方式。

另：这个专用设备还需要考虑安全问题，进行安全加固，毕竟是对外暴露的IPv6公网地址：需要对外暴露的端口不要用默认端口(尽量用大端口)、合理配置防火墙端口防护规则(如有可能，配置访问的黑白名单)、反向代理合理配置默认站点(使用虚假的SSL证书)及响应内容敏感信息过滤等等。

这种方式的优点和缺点如下：
1、优点

对路由器品牌和功能不依赖，只要支持正常的IPv6功能就行，适用于绝大部分的用户。
2、缺点

需要有一定动手能力和环境来搭建适合自己的专用设备并完成相关的配置。

可选的安全策略(虽然说是可选，但是强烈建议)

IPv6防火墙

如果路由器支持IPv6防火墙功能(目前我使用的爱快和华硕AC86U都支持IPv6防火墙)，建议开启，可以根据本文前面提到的不同的出口方案，选择不同的安全策略：
1、路由器中心化

这种方式里对外暴露的只是路由器wan口的IPv6地址，所以可以在IPv6防火墙上只允许对wan口IPv6地址特定端口的访问，而其他访问内网IPv6公网地址的访问请求全部阻断。
2、路由器边缘化

这种方式对外暴露的只是专用设备的IPv6地址，所以可以在IPv6防火墙上只允许对对专用设备IPv6地址特定端口的访问，而其他访问内网IPv6公网地址的访问请求全部阻断。

反向代理

如果需要发布的http类型应用比较多(比如家庭数据中心作为CDN的源站)，强烈建议使用反向代理，而不是直接使用端口转发。使用反向代理的好处很多：
1、可以对外只暴露一个端口

如果采用端口转发来访问内部应用，一个应用就需要暴露一个端口，而且是直接将所有访问(不管是不是合法)请求转发到内部应用端口，非常不安全。而采用反向代理，可以只暴露一个端口，然后可以根据访问域名是否有效来进行选择：合法的访问进行后续处理，而不合法的直接返回404或者444。所以合理的方式是http类型的应用发布都采用反向代理，而tcp、udp之类的应用发布采用度端口转发。
2、可以方便的将访问升级为https

通过设置SSL证书，可以方便的将http升级为https。
3、对应用的部署方式更加灵活

通过设置proxy_set_header参数，可以灵活的自定义传递到内部应用的http header参数，让应用的部署方式更加灵活。

SSL加密

在以后的日子里，网络监管只会越演越烈(参见我另一篇文章：家庭数据中心系列 有公网IP的家庭宽带建站注意事项)，为了自我保护，我觉得SSL加密已经是个必选项了(如果在加上域名备案就比较完美了)。

一般情况下，SSL加密流量都是终结于反向代理上，至于反向代理的选择很多：常用的NGINX，NPM都可以方便的进行SSL解密(细节参见：linux面板系列 配置反向代理并使用非443端口进行发布、docker系列 使用docker基于NPM搭建自己的反向代理)，甚至使用lucky搭建反向代理也是一样(参见上文链接)。

WAF防火墙

反向代理虽然可以直接指向内网的应用端口(比如只是自己或者家人朋友访问家里的应用)，但是在需要对外进行发布的时候(比如作为CDN的源站)，直接指向应用就太危险了，这个时候就可以考虑部署免费的WAF进行安全防护(长亭雷池不错，虽然社区免费版只支持反向代理的部署方式，但是和上级反向代理刚好完美契合)。

使用该方案的真实案例可以参看：家庭数据中心系列 家庭数据中心v4v6双栈网络架构及应用访问流程优化。

后话

IPv6公网地址的推广现在还面临很多问题，就像本文前面提到的包括家庭宽带局端支持太差、写字楼和酒店等公用场所出口不支持IPv6等等，这些都会影响IPv6公网地址的实用性(毕竟绝大部分人都不会备案，然后又恰好会使用CDN来解决IPv4 only的客户端的可访问性)。

目前对IPv6支持最好的就是各运营商的蜂窝网络，所以如果家里只有IPv6公网地址，又没法用CDN的方式提供IPv4的访问能力的时候，用手机蜂窝网络做热点，然后带其他设备访问也是一种方式。

其实，IPv6公网地址最大的用处还是建站(作为CDN的源站)，否则如果仅仅是自己访问，最合适的方式是通过虚拟组网方案(如tailscale)提供的固定私有IP进行访问。