方案速览

简单来说，方案包含了以下几个主要部分：

  1. 公网访问使用光猫桥接路由器拨号，通过路由器同时获取 IPv4 大内网和 IPv6 公网 /64 地址
  2. DNS 解析通过 MacMini 上部署的 ddns-go 实现
  3. v6 / v4 双栈访问采用了 Cloudflare 中针对 DNS 解析记录的 Proxied 能力
  4. 80 / 443 端口封禁通过在 MacMini 上开放 Cloudflare Proxy 支持的端口 并在 Cloudflare 控制台指定回源端口解决
  5. Gitea 仓库直接在 Nas 上通过 Docker Compose 部署，通过 MacMini 上 Caddy 反向代理 http/https 流量
  6. TLS 采用 caddy-dns 插件，通过 Cloudflare token 实现 dns 验证，并由 Caddy 自动部署证书

背景

大四毕业上班之后，便不再和父母一起住了，自然而然地就想改善一下家里的网络环境，也正好实践一下刚考完研还热乎的计算机网络知识，而不至于像之前重启一下路由器马上就能听到 “怎么没网了” 这样的投诉。

做的第一件事就是选一个宽带运营商。由于我自己两个号码都是中国联通的，一张是米粉卡 5r / mo 月租 + 1r / GiB (3r 不限量) 日租流量包的套餐，另一张曾经也是米粉卡，后来手贱改成了 19r / mo 月租 + 3GiB 流量 + 1r / GiB 日租流量包的大王卡套餐，一直都觉得第二张卡套餐太亏，于是想趁着宽带的机会把这张卡和宽带绑在一起共用一个套餐 (事实证明其实没什么用，因为现在宽带都改成最低消费模式了，也就是只要满足卡的每月最低消费就能有宽带，如果没有达到最低消费就直接扣中间的差额。所以其实这么看还是米粉卡最划算，相当于每月不限量流量才 95r，宽带 139r 低消只用再补 40r，所以有便宜套餐千万不要随便改啊)，就选了联通 139r / mo 的 1000M 宽带的套餐。

办套餐的时候最关心的就是：

  1. 有没有 IPv4 公网地址
  2. 有没有 IPv6 公网地址
  3. 上行带宽有多少
  4. 下行实际带宽能有多少

在办的时候专门确认了前三点，确认是不会有公网 IPv4 但是有公网 IPv6，上行带宽差不多 150M，想了想感觉也够了，遂同意，签合同，上门安装，便也有了后文。

光猫桥接和路由器拨号

这个 139r 的联通套餐实际上是他们的 FTTR 解决方案，会带一个主路由和一个副路由，中间用隐形光纤连接，主路由给的是 2.5G 网口版本，这点好评，不过官方的配网方案感觉应该是 AC + AP 模式，光猫必须作为网关，然后路由器估计也得用 AP 模式不然感觉应该路由器连接的设备和官方的 AP 连接的设备就不在一个子网了。

当即就觉得这样不行，还是得该桥接，代价就是官方的 AP 就浪费了 (虽然我感觉好像是不是如果把 AP 连上后面交换机的光口应该也能用？不知道官方的 AP 里面是什么逻辑)，但反正也是不要钱的东西，浪费就浪费了，于是初步规划了一下家里的网络拓扑如下：

network_topology

啥是光猫桥接

以我浅薄的计算机网络知识理解一下光猫桥接：

在默认情况下，光猫作为家里的网关路由，光猫出口端连接的是运营商网络，具有运营商分配的 IP；光猫另一端连接家庭网络的其他设备，运行在 192.168.1.0/24 子网 A (随便命一个名字方便区分) 下，并且光猫使用固定 IP 192.168.1.1 接入这个子网。

之后，如果路由器选择路由模式，则路由器与光猫连接的一端接入子网 A 中，并具有光猫分配的 IP，此时所有设备和路由器连接，并以路由器作为它们的网关，此时，这些设备和路由器向内的端口同处一个子网 B 中，一般也是 192.168.1.0/24 这个网段，路由器以 IP 192.168.1.1 接入这个子网。

相反，如果路由器选择 AP 模式，则路由器可以理解为一个无线交换机，其不分割子网，所有设备和光猫内侧端口处于同一个子网 A 中，此时使用 IP 192.168.1.1 则可以访问到光猫管理页面。

如果将光猫桥接，则可以理解为，光猫以一种子网设备的形式连接到运营商和家里真实网关设备之间的子网上，也就是可以想象成如下的网络拓扑结构：

bridge_topology

也就是，光猫自己充当这个交换机的角色，并以一个固定 IP 192.168.1.1 接入到广播域 A 中。路由器和入户网线都与光猫充当的交换机连接，路由器实际与运营商建立拨号连接并获得运营商提供的 IP，充当广播域 B 的网关设备。

为什么要强调光猫以固定 IP 接入广播域 A 中呢，因为从拓扑图中也可以看到，一旦光猫开启了桥接模式，并且所有的设备都与路由器连接，在广播域 B 中的设备将无法访问到广播域 A 中的光猫，想要访问光猫只有在路由器中建立路由表转发 192.168.1.1 的包到广播域 A 中或是直接将设备接入广播域 A 中才能通过 192.168.1.1 访问到光猫。

超管密码

其实改光猫桥接很简单，网上针对不同的光猫型号和运营商都有很丰富的教程了，反倒是超管密码的获取才是最难的一步，这就要考验和安装人员拉扯的话术了。

还记得当时和安装小哥说能不能改成桥接，小哥说现在公司规定他们是不可以这么操作的，也就是说以前明着要求小哥改桥接的路子就不太行得通了。后来想了一下，问小哥之后要是网络出了什么问题是不是要找他上门帮我弄，小哥说是的，我又问了价格，说这种不收钱的，我就顺水推舟说要不给我个超管的密码，我自己也会配网络，如果有什么问题我自己弄一下就好了也不麻烦他上门一趟，还没有费用拿，小哥很高兴就给我写了个小纸条留了密码，还嘱咐说这个密码是动态的，过几个月就失效了，要配得快点，失效了可以再问他要。

果然沟通还是要拿捏住让双方都获利还不明显违规的点哈哈，给我密码对他来说节省了跑一趟的时间和精力，减少了投诉率，对我来说又能够达成目的，还不违背运营商禁止小哥配桥接的要求，问就是我自己淘宝买的超管密码。

拨号上网和 IPv6

光猫桥接搞定以后，就是把路由器连接上光猫然后配置拨号连接了。

拨号的账号可以在光猫的页面看到，密码则可以问运营商人工客服，一般默认就是账号的后 6 位，IPv6 可以复用 IPv4 线路进行拨号，如下图所示：

ipv6_auth

由于需要允许内网设备与公网建立连接，需要关闭 IPv6 防火墙功能，其他厂商是否需要关闭取决于厂商如何定义它们的防火墙。TP-Link 对 IPv6 防火墙的描述为：“IPv6 防火墙能有效将外网和内网进行隔离，避免家庭局域网完全暴露给外网，保障用户的网络安全。”

同时，地址获取协议和前缀授权就都选择自动，DNS 服务器我选择了 Cloudflare 的 1.1.1.1 中的配置。

ipv6_config

针对局域网内的设备，可以根据运营商分配的数量灵活选择 SLAAC 和 DHCPv6。由于抠门的深圳联通只给了 /64 地址，相当于只有直接连接到路由器的设备可以使用 SLAAC 分配地址，下级设备无法继续使用 SLAAC 分配，索性我就直接关闭了 SLAAC 能力改用 DHCPv6。

ipv6_config_2

DDNS 动态域名解析与 Cloudflare Proxy

路由有了 IPv6 之后，接上机柜里的 MacMini，就可以使用 IPv6 访问到这台机器了，先拿个 python http 服务试试看通不通：

1
2
cd ~/some_dir
python -m http.server 23333

IPv6 地址可以使用 ipconfig (Windows) 或是 ip addr (Linux/Mac) 命令查看到，一般是查看 无线局域网适配器 WLAN 或是 以太网适配器 (Windows) 或是 eth0 (Linux)，en0 (Mac) 下面的 IPv6 或是 inet6 标识的地址。还会有很多标有 临时 或是 deprecated 的地址，那些是系统为了防止网站跟踪 IP 地址，轮替生成的用于主动建立连接时使用的地址，这些地址有效期较短并且时常变化，不适用于监听传入的连接。

inet6_addr

浏览器直接 http://[这里填 IPv6 地址]:端口号 即可测试能不能正常访问了，不放心可以流量访问确定链路是通的。

接下来就该把这个地址解析成域名了。因为 IPv6 始终不是静态的，因此需要动态地轮询设备的 IPv6 地址然后更新 DNS 服务商上的解析内容。

ddns-go 安装

参考 ddns-go 文档即可快速在系统中安装 ddns-go。没有选择 Docker 主要是看到可以使用 brew 安装，甚至感觉比 docker 还简单。

1
2
brew install ddns-go
ddns-go -s install -l 23333

这样就启动了控制面板在 23333 端口的 ddns-go 服务，配置文件默认保存在 ~/.ddns_go_config.yaml 中，这个我个人懒得改，想改看文档可以 -c 指定路径

然后就是 http://192.168.X.X:XXXXX 登陆进去面板配置了，这里需要注意的是需要局域网登录进去配置，如果是非局域网地址会拒绝连接。

Webhook 通知我选择了 Server 酱，每天免费 5 条消息也够用，Webhook 格式配置如下：

1
https://sctapi.ftqq.com/<my_token>.send?title=检测到 DDNS 设备 IP 变化&desp=MacMini の IP 已变更为 #{ipv6Addr}, 域名更新 #{ipv6Result}

搞完以后就可以浏览器进 域名:端口号 看看服务生没生效啦，在这一步测试的时候，记得在 Cloudflare 中关闭 Proxied 模式，后面会具体讲到原因。

Cloudflare Proxied 代理

这个时候已经可以在 IPv6 的网络下通过 域名:端口号 访问到服务了，但是这时候还有两个令人头疼的问题：

  1. 很多时候网络环境是仅 IPv4 的，例如各种酒店、公用 WiFi、公司内网等等，仅 IPv6 的网络访问覆盖率还是太低，感觉实用性不强
  2. 网址后面带着端口号，怎么看都很丑，有些不能指定端口号的地方就会收受到阻碍

所以在完成了 DDNS 之后，就可以着手使用 Cloudflare 提供的回源能力了。

Cloudflare Proxy本质上就是，Cloudflare 将域名解析到它的代理服务器，然后转发你对源服务器的请求。这样做有几个好处：

  1. 隐藏了服务器的实际 IP 地址，用户只知道 Cloudflare 代理服务器的 IP 地址，对于家里部署的服务而言更安全
  2. Cloudflare Proxy 支持用户使用 IPv4 连接，同时使用 IPv6 与源服务器通信，也就是说可以充当 v4 转 v6 的中间件
  3. 回源的时候支持指定具体的端口号，这样就可以在网址里不再输入端口号了

开启 Proxy 十分简单，直接在 DNS 记录里打开 Proxied 开关即可。

不过，由于 Cloudflare 只支持有限的端口转发，并且只支持基于 http/https 协议的流量转发，因此适用面相对不那么广，但是家用部署网站服务还是绰绰有余了。具体允许的端口号见 Cloudflare 文档。

经过测试，中国联通封了 80，443，2096 端口，回源我采用的 2095 端口，这个在 Cloudflare 控制台 - 规则 - Origin Rules 可以创建回源规则针对特定域名指定。

Gitea 安装与反向代理

待后续翔实~