时间:2025-04-3 作者:剧中人
可能你看到这个标题有些懵逼,小剧这是又在整个什么花活?
当你在部署服务时,一般都是部署在内网环境中。比如在公司、学校、家庭环境中。部署一些文件管理、OA系统、各种登记报名请假之类的 Web 服务。
这种场景下的服务,用户群体集中且数量有限,也很容易管理,所以易用性并不是优先级非常高的需求。
在 Web 规模较小时,服务部署之后直接将 IP + 端口告诉大家,也就完成了内网服务的搭建。
考虑到在外网访问需求,出于安全和部署的复杂度的考虑。一般的套路是强制大家使用 VPN 连接内网,接下来就和内网保持相同的访问路径就完事了。
当然可以,比如请假系统,当在外遭遇突发情况时,需要借助于公共电脑访问内网,发起请假流程。
这时安全性较高的 VPN 很难或无法顺利配置成功。
又或者在时间上或人员上,有很大的比例需要在局域网以外访问内网服务。比如学生的寒暑假,公司的居家办公。
每次的 VPN 认证就显得格外繁琐。
除非保密等级极高,现在主流的服务部署都是尽力让使用者不区分内外网,用同一套网址保持云端使用体验的方案。
前面说的有些发散了,只是为了方便大家理解而写的引子。
小剧遇到的和要解决的问题,其实仅限于家庭内网服务,正如标题提到的"局域网公网DNS 融合,居家外出畅通无阻"。
相信你也了解,小剧近些年在捣鼓家庭服务搭建。没有搞出什么大的名堂,但是也有一些心得体会想和大家分享。
今天分享下,关于家庭服务网络搭建的经验。
家庭服务硬件照片
最早小剧在家中部署了 SMB 文件共享服务、Immich 照片管理服务。
这两个服务几乎涵盖了绝大多数个人文件管理的范畴。使用了一段时间后便给媳妇手机也配置上了。
内网速度贼快,但服务也只有在内网才能访问,使用起来不方便,媳妇并不怎么用它。
正如前文引子里提到的,内网 VPN 的方案被提上了日程。
小剧斥巨资(闲鱼79元)购入了蒲公英设备,用于实现身处公网环境时,一键回到家庭内网中。
蒲公英小盒子
蒲公英免费版有设备限制,当 P2P 不成功的时候提供的带宽也不高,但访问速度足以应付一般情况下的使用了。
看起来一切问题都解决了,简单给媳妇做了"培训"后,家庭网络 2.0 版本就算完工了。
经过一个月的实际使用,小剧经常开启 Immich 的时候忘记登录蒲公英,转了半天圈加载失败,还得重新登录蒲公英,再回到 Immich 中访问。
又或者登陆了蒲公英后忘记关掉,导致回到家中手机显示网络异常。
蒲公英 APP 截图
看起来使用前登录蒲公英,使用后退出蒲公英这么一个小小的动作,实际使用中也会带来不小的困扰。
小剧都是如此,想必媳妇更不习惯如此"繁琐"的使用方式。
还没等小剧去做"用户使用调研",就发现媳妇早就已经把蒲公英卸载了。
相信这一步你比小剧更熟,想让一个内网服务在公网可访问,方案简直不要太多。
有前面提到的蒲公英设备可以搭建,也有 zerotier 之类的免费服务可用,但这些都不算"直接访问"。
能称得上"直接访问"的,一般有以下三个方案。
对于很多小伙伴来说,家庭公网 IPV4 是遥不可及的梦。幸运的是小剧很多年前因为机缘巧合申请到过,至今可用。
但出于"安全与合规"的考虑,小剧并没有使用这个方案。
安徽电信还是很给力的,公网 IPV6 无需申请就可以得到,不过使用它还得放弃一点点的安全性。需要额外关闭路由器的 IPV6 防火墙才可以顺利使用。
至于服务器中转这条路,对于个人站博主的小剧来说,简直是零成本。阿里云 99 包年的服务器可太适合干这件事了。
公网直接访问的方案好么?
确实,不管用上面哪种方式,身处于外网时"直接访问"家庭内网服务的需求是达到了。
但仔细想想依然不够。
因为在家时使用的是形如 192.168.xxx.xxx
的内网地址,在外网时使用的是公网 IPV4 或 IPV6 解析后的域名。
绝大多数应用或者 Web 都需要手动切换网址,还是非常麻烦。
虽然有少数 APP 支持配置内外网地址,APP 根据连接的 Wi-Fi 自行切换网络。但前提是你得允许 APP 始终获取设备位置的权限。好用但不优雅,还费电。
Immich 网络配置截图
v3.0 的方案虽然没有达到给媳妇用的标准,但在网络配置层面已经有了质的飞跃。
再往前进一步就是我们今天的主题了。
这部分涉及到的内容较多,具体的实现下面展开聊。
正如标题提到的 "局域网公网 DNS 融合,居家外出畅通无阻"。
总体思路就是:同一个域名在局域网和公网,借助于 DNS 分别配置不同的解析。让使用者从外面回到家里,或者相反的时候,都能够无感切换服务地址。
我知道你现在肯定有顾虑:DNS 会有缓存的,内外网切换的过程,有问题么?
确实,这也是小剧早期的担忧,测试后发现完全是多虑了。
当然,要实现这一套切换流程,以下几个关键环节必不可少。
局域网 & 公网访问拓扑图
前面已经介绍了三个支持公网"直接访问"的方案。这里只提下思路和小剧的使用情况,具体教程可以去 B 站搜索,有很多手把手教你实现的视频。
公网 IPV4 + DDNS + 端口转发方案
公网 IPV6 + DDNS 方案
服务器中转方案
无论使用 IPV6 + DDNS 方案,还是服务器中转方案,在公网中都是使用域名或域名 + 端口的访问方式。
而在家中一般是借助于内网 IP + 端口的访问方式。
想要借助 DNS 统一内外网的访问体验,势必需要在内网中也支持域名或域名 + 端口的访问方式。
熟悉服务部署的小伙伴应该知道,这一步需要有 Nginx 之类的反向代理服务,用来根据域名做流量的代理分发。
极摩客小主机
反向代理服务可以部署在主服务本机,也可以部署在独立的机器上。
小剧出于设备分离的角度出发,购入了极摩客G5,作为专职的反向代理服务器。
使用 Caddy 作为反向代理服务。
有了反向代理服务还不够,局域网内还得支持把特定域名的请求指向到反向代理服务器上,才能完成整个网络的闭环。
我们以访问 immich.sample.com 为例,反向代理服务器 IP 为 192.168.2.10,immich 服务 IP 为 192.168.2.11 端口 8080。
手机电脑之类的设备 → 访问 https://immich.sample.com → 局域网 DNS 解析域名至 192.168.2.10 反向代理服务器 → 反向代理服务根据域名反向代理至 192.168.2.11:8080
这一步就是全文的关键,如何在内网通过 DNS,将具体的域名指向到特定的服务?
这一步其实方案有很多,如果你们家在使用软路由做主路由,有很多插件可以完成。
还可以搭建了一个局域网 DNS 服务,用更灵活的自定义局域网 DNS 的方法来实现。
最开始小剧用的就是这个方法,但在跑了一段时间才发现,家里在用的小米路由器竟然支持自定义 Hosts,来实现域名的自定义解析。
小米路由器自定义 Hosts 截图
因为小剧需要自定义的域名并不多,而且没有动态逻辑,小米路由器自带的自定义 Hosts 足够小剧用了。
借助于小米路由器的自定义 Hosts 功能,Hack 局域网 DNS 的功能就算完成了。
如果你有过服务部署的经验,应该知道在互联网上发布服务,HTTPS 是必须的。
近些年能够免费申请到的 SSL 证书,有效期也越来越短了,并且申请过程也需要各种验证,很是麻烦。
有一些自动脚本可以辅助我们自动签发证书。但前提是 SSL 签名的服务商,需要能够通过公网中域名解析的通道,借助于 80 之类的端口,验证你对这个域名是否拥有控制权限。
局域网 & 公网访问拓扑图
我们再看一遍拓扑图,从图中可以看出来,在公网和局域网中各有一个反向代理服务器。
按照前面的描述,公网中的反向代理服务器是很容易申请到 SSL 证书签名的。身处于局域网中的反向代理服务器则无法顺利的完成证书签名的鉴权流程。
好在本方案要实现的是局域网公网 DNS 融合,服务器中转这条路中,局域网中配置的域名公网中都存在。因而只需要用任意方案将公网的 SSL 证书的自动签发完成,局域网再定时去更新就好了。
小剧使用的是 Caddy 作为反向代理服务器,它将自动化做到了极致。在公网中几乎可以做到零配置签发 SSL 证书,而且是自动续期的。
局域网则需要放弃 Caddy 的证书自动签发逻辑,手动指明证书位置。
公网 Caddyfile 配置
immich.sample.com {
reverse_proxy 127.0.0.1:22233
}
局域网 Caddyfile 配置
immich.sample.com {
tls ./immich.sample.com/immich.sample.com.crt ./immich.sample.com/immich.sample.com.key
reverse_proxy 192.168.2.6:8096
}
同步服务端证书并不难,因为 Caddy 存放证书的目录是确定的,且没有经过二次加密。简单的使用scp 命令就能实现跨服务器拉取证书,再辅助使用 crontab 之类的定时脚本会更加方便。
下载服务端证书脚本
scp -r user@11.11.11.11:/user/.local/share/caddy/certificates/acme-v02.api.letsencrypt.org-directory/* ./
如果你细心看上面的网络拓扑图,会发现 DDNS + IPV6 方案的流量不经过公网服务器,因此也不会生成对应域名的证书。
家庭局域网也无法签发证书,HTTPS 是个难题。
正当小剧一筹莫展时,一个精妙的思路浮现在小剧的脑海中。
公网的反向代理同样配置一条 IPV6 服务对应域名的解析,使用静态文本做响应。这一步完全是为了自动化获取 SSL 证书,没有其他意义。
ipv6.sample.com {
respond "Hello This is bh-lay.com"
}
局域网的反向代理服务用相同的方法获取对应域名的证书。
当身处家庭局域网中倒没什么问题,因为域名会被 Hack 成仅内网 IP 的解析。
而当你处在公网中就变得复杂了,ipv6.sample.com
域名对应的解析,既有公网 IPV4 的地址,同时也有 IPV6 的地址,设备将会如何选择链路?
这部分小剧并没有找到权威的解释,仅从实际测试结果来同步下结论:
IOS、MacOS 在某个域名同时能解析到 IPV4 和 IPV6 的地址时,会优先使用 IPV6 的链路。如果当前网络环境仅支持 IPV4,将会使用 IPV4 的地址。
如此一来刚好满足小剧的需要,IPV6 同样可以用这套方案兼容。
这里还有一个小贴士:家庭 IPV6 用不了 80、443 端口,需要设置形如 8080、8443 的高位端口。
SSL 证书只关心域名,不同端口可以使用同一套证书。
这一点也是最初小剧的顾虑,万幸验证后并不存在。
目前来说,家庭局域网、公网 DNS 融合的方案已经成为小剧家中的服务部署范式。在最近半年的使用中也没有掉过链子。
有了前面的背景知识,应该能看出来服务器中转和 ipv6 有各自的特点。
服务器中转的方案,速度稍慢但非常稳定,天然适合一些常用的、对网络要求较轻的服务。比如笔记、相册服务。
IPV6 速度理论上的上限较高,但使用场景比较局限,某些时候还得借助于手机流量才能访问。
比较适合一些大流量的服务,比如 Jellyfin 观影类的 APP,在外给娃看动画片最合适不过了。
不同类型的服务可以按照特性,去选择合适的方案,实际使用下来相当舒适。
在前面 2.2 部分,提到小剧"斥巨资"购入了蒲公英小盒子。看起来后面的服务部署方案和它没有一丁点关系了。
其实不是的,内网中零零碎碎的服务很多,协议也多种多样,绝大多数服务都不太适合,也没有必要部署到互联网中。
蒲公英作为安全性较高的内网穿透方案,很适合给小剧做远程运维的通道。
在外时借助于它可以连接 Mac mini 的远程桌面,使用 SSH 管理 Docker 容器。
偶尔遇到服务故障时也能掏出手机,从容的进行故障恢复。
因此蒲公英成了小剧专属的回家通道。
DNS 融合的模式,对小剧媳妇来说不需要任何前置操作。需要用某个 APP 的时候直接点开,用完了放到后台或者关掉即可。
目前 Immich、Jellyfin 已经在媳妇手机里成为常客,Outline 文档 APP 虽然不怎么用,但是也一直没有删掉。
也算是对小剧"瞎折腾"的一种认可吧。
最后的提醒:
任何将服务暴露在公网中的行为都是带有风险的,要注意数据安全哦~