NAS远程访问不安全？用Lucky给自己的服务增加手机二次验证
Summary
本文介绍利用 lucky 为 NAS 本地服务添加域名反代及二次验证的方法。首先通过 Cloudflare 和 lucky 设置 DDNS 与反向代理，随后在 lucky 中配置 GitHub 第三方认证，并可选绑定 Bitwarden 二步验证。访问服务时需登录 GitHub 并输入验证码，从而在不支持密码的服务上实现安全访问。注：此功能需安装完整版万吉。
前言
为了方便在外面也能访问家里 NAS 上的服务，我一直用 lucky（一款功能很全的反代/DDNS 工具）给 NAS 上的本地服务添加域名反代，通过 DDNS 实现外网访问。
但"方便"和"安全"往往是矛盾的：一旦把服务用域名暴露到公网，就等于把它开到了公网上，谁扫到都可能来试。为了安全，我通常会再给服务加一道登录密码。可麻烦的是——
有些服务本身没有登录功能；
有些服务我压根就不想让它暴露出去，却又需要在外网临时用一下。
这种情况下，给这些服务加一道"二次验证"（第三方认证），就是一个很好的兜底方案。今天以我在 NAS 上部署的一个搜书服务为例（这个项目本身没有登录功能，但又不想被陌生人访问），演示怎么用 lucky + GitHub 给它套上一层登录墙。
前置：添加域名反代
先用 lucky 给服务做好域名反代（DDNS 的详细方法可以参考我之前的文章，这里快速过一遍流程）：
Cloudflare 添加解析：添加一条解析记录，指向 NAS 的 IPv6 地址。
lucky 添加动态域名记录：在 lucky 的 DDNS 里配置这条域名记录，让外网 IP 变化时能自动更新解析。
web 服务中添加反代规则：在 lucky 的 Web 服务里新增一条反代规则，把域名指向 NAS 上的搜书服务。
测试外网访问：配置好后先从外网访问一下，确认能正常打开。
到这里，服务和"能外网访问"已经打通了，但此刻它也是完全裸奔的——谁拿到域名都能进。接下来就给它上锁。
添加 GitHub 认证
1. 添加认证用户
在 lucky 里选择 第三方认证，先添加一个认证用户。这里的思路是用 GitHub 账号作为"入场券"——只有被你授权的 GitHub 账号才能通过认证。
2. 发起授权
添加用户后，点击 发起授权，lucky 会生成一个 GitHub OAuth 授权链接。
3. 登录 GitHub 并授权
在弹出的新页面里，登录你的 GitHub 账号并完成授权。授权成功后，这个 GitHub 账号就和 lucky 的认证用户绑定了，只有它能通过这道登录墙。
4.（可选）添加二步验证
想更保险的话，还可以给认证加上二步验证（2FA）。这时需要用登录工具器（TOTP 扫码工具）扫码绑定——我选择用 Bitwarden 来管这个动态码。之后每次登录除了 GitHub 授权，还要再填一个 6 位动态验证码。
5. 在反代规则上启用认证
回到 Web 服务的反代规则里，修改这条子规则：打开 网页认证，选择刚才绑定的那个 GitHub 账户。这样这条反代就挂上了"登录墙"。
安全登录效果
配置完成后再访问服务链接，就会看到 lucky 的登录页面：
打开服务链接，不再直接进入搜书服务，而是先跳到 lucky 的登录页面；
点击下面的 GitHub 图标（首次会要求登录 GitHub 并完成授权），授权通过；
如果开了二步验证，还要填 Bitwarden 生成的 6 位动态密码，全部通过后才进入服务。
结尾提醒
⚠️ 需要注意：这个功能可能需要 lucky 的完整版（万吉）才支持；而且 3.0 版本的界面和 2.7 可能略有不同。如果你用的是精简版或旧版本，找不到对应选项是正常的。
个人结论
用 lucky 给"没有登录功能"的服务套一层 GitHub 认证 + 可选的二步验证，等于给裸奔的反代服务补上了一道像样的门禁：未授权的 GitHub 账号进不来，加上 2FA 后即使 GitHub 账号泄露也需要动态码才能过，安全度明显上了一个台阶。特别适合那些"不得不暴露、又没有自带认证"的自托管服务。缺点是第三方认证依赖 GitHub 可用性，但对于个人自托管场景，这个方案在安全与便利之间的平衡已经相当好了。值得一试。