从家宽端口暴露到 Cloudflare、Lucky 与 SafeLine 统一认证：我的家庭服务安全改造记录
本文记录一次家庭网络服务的安全改造过程：把多个带端口访问的服务逐步收敛到二级域名，通过 Cloudflare、Lucky 和长亭雷池 SafeLine WAF 组成一条更清晰的访问链路，并为重要服务加入统一认证。
出于安全原因，本文不公开家宽源站 IP、管理端口、账号密码、OAuth Client Secret、API Token 和内部敏感配置。
一、改造前的问题
早期服务主要通过家宽公网 IP 加端口访问，例如书签导航、面板管理、PVE 管理界面以及其他家庭云和内部工具。
这种方式的问题很直接：
- URL 中暴露端口，服务入口分散。
- 历史端口转发长期存在，容易忘记清理。
- 部分服务直接暴露源站，绕过了统一防护。
- 各服务登录方式不同，缺少统一的认证和授权管理。
- 历史 DNS、旧域名、证书和端口都可能泄露源站信息。
改造目标是：公网访问尽量使用域名，流量先经过 Cloudflare 和 Lucky，再进入 SafeLine，最后到达内网服务。
二、最终访问链路
整体链路如下：
访客浏览器
↓ HTTPSCloudflare DNS / Proxy
↓Lucky 统一入口
↓ 按域名分流SafeLine WAF
↓ 身份认证与 Web 防护内网业务服务
目前的职责划分：
- Cloudflare：DNS、代理和公网边缘证书。
- Lucky：家宽入口、HTTPS 监听、域名分流和反向代理。
- SafeLine：Web 防护、身份认证、第三方登录和统一认证中心。
- 后端服务：只接受来自内网反向代理的访问。
三、先把端口服务改成域名访问
在 Lucky 的 HTTPS 监听中，按 Host 配置了多个子域名规则。外部用户访问标准 HTTPS 端口，Lucky 根据域名转发到不同的内网服务。
| 公网域名 | 作用 | 后端方向 |
|---|---|---|
| nav.52mobileweb.com | 导航服务 | 内网导航服务 |
| pve.52mobileweb.com | PVE 管理 | SafeLine 的 PVE 防护应用 |
| paint.52mobileweb.com | 绘图或面板服务 | SafeLine 的对应防护应用 |
| bt.52mobileweb.com | 宝塔或相关面板 | 内网面板服务 |
| waf.52mobileweb.com | SafeLine 控制台 | SafeLine 管理入口 |
| auth.52mobileweb.com | 统一认证中心 | SafeLine 统一认证监听 |
Lucky 中为这些域名配置了独立的反向代理规则，并保留必要的 Host 头设置。验证时不能只看 DNS，还要同时检查域名解析、HTTPS 证书、Lucky 是否命中正确规则、SafeLine 是否收到请求以及后端页面是否正常返回。
四、把重要服务接入 SafeLine
在 SafeLine 中建立了多个防护应用，将需要保护的后端服务接入雷池。PVE 的入口尤其重要，因为它同时具备管理权限和基础设施操作能力。
PVE 的访问路径变成：
浏览器 → Cloudflare → Lucky → SafeLine → PVE
SafeLine 对 PVE 开启了身份认证。账号密码认证先作为保底方案保留，后续再逐步切换到第三方登录和统一认证。
这里有一个容易忽略的安全边界：如果路由器上仍然保留旧的 WAN 端口转发，用户仍可能绕过 Lucky 和 SafeLine 直接访问后端。因此，旧端口转发不能只记录，最终还应逐项确认是否需要删除，并从公网实际测试绕过路径是否仍然存在。
五、配置 GitHub OAuth 登录
SafeLine 官方 GitHub 登录回调格式为：
《https://应用域名/.safeline/auth/api/callback/github》
创建 GitHub OAuth App 时，使用了专门的 SafeLine 应用信息，并加入了 PVE 域名的回调地址。最初只配置控制台域名，访问 PVE 时出现：
The redirect_uri is not associated with this application.
原因是 SafeLine 按实际被保护应用的域名发起回调。修复方式是把实际应用的回调地址也加入 GitHub OAuth App，例如：
《https://pve.52mobileweb.com/.safeline/auth/api/callback/github》
之后回调地址匹配成功，但又出现“获取用户信息失败”。这说明 OAuth 回调本身已经成功，问题转移到了 SafeLine 服务器访问 GitHub 用户信息接口的网络链路。这个问题需要继续检查 SafeLine 主机到 GitHub API 的出站连通性，必要时配置可用的 HTTP/HTTPS 代理。
OAuth 排错要分成三段看：
- GitHub 是否接受 redirect_uri。
- SafeLine 是否成功交换授权码和访问令牌。
- SafeLine 是否能读取 GitHub 用户资料并完成用户绑定。
六、建立 SafeLine 统一认证中心
随后在 SafeLine 中开启统一认证，使用：
- 认证中心域名：auth.52mobileweb.com
- SafeLine 内部监听：独立 HTTPS 端口
- 登录方式：账号密码 + GitHub
- PVE：加入统一认证
PVE 的应用跳转地址使用 HTTPS，避免认证完成后跳回 HTTP。
统一认证的作用是：用户完成一次身份认证后，可以访问已经加入统一认证的多个 SafeLine 应用。每个应用仍然由 SafeLine 负责授权，统一认证解决的是登录会话复用，不等于自动授予所有应用权限。
七、Cloudflare 代理状态的细节
Lucky 的 Cloudflare DDNS 记录中，不能只打开“指定代理状态”。还需要继续打开记录下面的“代理状态”，让状态从：
仅 DNS → 已代理
正确完成后，DNS 查询返回的是 Cloudflare 地址，而不是家宽源站地址，浏览器也能使用 Cloudflare 的边缘证书访问 auth.52mobileweb.com。
这次排查中，统一认证中心最开始能从 Lucky 返回页面，但浏览器仍提示证书不匹配。最终发现 auth 域名的记录还处于仅 DNS 状态，仍直接拿到了其他域名的源站证书。切换为 Cloudflare 代理后，HTTPS 证书和统一认证页面恢复正常。
八、验证清单
以后每新增一个服务，可以按下面的顺序验证：
- 内网后端本地访问正常。
- SafeLine 防护应用的后端地址正确。
- Lucky 的前端域名和后端地址正确。
- Cloudflare A/AAAA 记录正确，代理状态符合预期。
- 公网 HTTPS 证书与域名匹配。
- 公网访问命中正确的 SafeLine 应用。
- 未登录时出现身份认证页面。
- 登录后可以访问后端服务。
- 认证日志中能看到成功或失败原因。
- 旧端口和旧域名不能绕过新的防护链路。
九、后续安全计划
这次改造完成了域名化、反向代理、SafeLine 防护、GitHub OAuth 和统一认证中心的基础链路，但还需要继续做几件事：
- 检查并清理不再需要的 WAN 端口转发。
- 检查历史 DNS、旧域名和旧证书是否仍暴露源站。
- 确认 GitHub API 出站访问问题，完成一次完整的 GitHub 用户绑定测试。
- 为 PVE、SafeLine 和 Lucky 管理入口启用更强的二步验证。
- 保留账号密码应急入口，但使用高强度密码并限制授权范围。
- 定期从公网测试端口、证书、DNS 和绕过路径。
- 记录每个域名对应的后端服务，避免未来新增规则时出现重复或错误转发。
结语
家庭服务器安全不是简单地“套一层 WAF”。真正稳定的方案需要把 DNS、证书、入口代理、应用防护、身份认证、授权和旧端口清理连成一条完整链路。
这次实践中最重要的经验有三点：
- 域名解析成功不代表流量已经经过 WAF。
- OAuth 回调成功不代表用户资料读取成功。
- 认证中心配置成功不代表所有应用都已经加入统一认证。
每个阶段都要用实际公网请求、响应头、页面和认证日志来确认，而不是只看控制台上的配置项。