家庭 VPN 服务器需要动态 DNS 吗？

动态 DNS 修的是名字，不是入口路径。三项检查决定一个主机名是否够用，或者入口路线本身已经断了。

别人来问我的家庭 VPN 故障，大多不是 DNS 故障，但他们还是先买了动态 DNS 订阅。配置任何东西之前，先判断主机名是不是真正坏掉的那一环。更新器只在运营商给你的地址变动时改写记录；它打不开端口，穿不过运营商 NAT，也没法让一条正在运行的 WireGuard 会话察觉到自己的端点变了。动态 DNS 是全部答案还是只占一行，由三个条件决定。

条件一：你的地址确实在变

住宅地址会因为很平常的原因变化：断电后调制解调器重新同步、运营商重新平衡地址池、长时间中断后换到新租约。有些线路上的地址几乎不变，我见过同一个地址撑了一整年；企业套餐往往自带固定地址。如果十二个月什么都没变，手改一条 A 记录，反而少了一个要养活的守护进程。

测一下，别猜。读路由器状态页上的 WAN 地址，再和外部世界看到的地址比较。在局域网内的机器上执行：

curl -fsS https://api.ipify.org; echo

如果两个值不同，说明路由器前面有东西在做转换，任何主机名更新都救不了。落在 100.64.0.0/10 里的地址是运营商级 NAT 的共享段，这也是名字更新正确、从外面仍然超时的常见原因。

条件二：客户端会重新解析这个名字

TTL 设短是很多人跳过的一步。递归解析器会遵守记录的 TTL，但客户端栈自己还有缓存，而已建好的隧道不会重新解析任何东西。调试期间把记录设成 60-300 秒；这只缩短了旧答案被发出的窗口，并不会迁移一条已连接的会话。

OpenVPN 每次重连都会重新解析 remote vpn.example.net 1194 那一行，而 resolv-retry infinite 让它在解析失败时继续重试而不是退出。服务器端的 float 允许已建立会话跟随源地址发生变化的对端。WireGuard 更直白：wg-quick up 在应用配置时只解析一次 Endpoint ，客户端重建隧道时会再解析一次，所以一场针对旧地址仍然成功的握手会一直成功，直到它停下来。

这个差别决定了方案。客户端按需连接，地址变动只值一次重连；客户端把会话挂上好几天，就要预计隧道在下一次握手时死掉，让客户端自己重试，而不是假设它一直在线。

条件三：入口路径仍然通

动态 DNS 只改名字指向哪里，别的什么都不改。路由器上的端口转发、VPN 主机上的防火墙规则、运营商放行入站报文，三件事都得先成立，记录才有意义。注意转发指向什么：如果它绑的是 WAN 地址而不是接口，地址一变转发就会静默失效，背锅的却是记录。

从外面测。关掉 Wi-Fi 用蜂窝数据的手机是最便宜也最诚实的测试；同一个局域网里的笔记本不算。当名字解析到你的公网地址、路由器又没有 NAT 回环时，内部测试会失败，但记录其实完全正确，多数人就是这样跑去改一条从来没出错的记录。

三个条件都成立时该跑什么

小主机上最不让人意外的更新器是 ddclient。最小配置发布的是运营商看到的那个地址，正好绕开双重 NAT 的坑：

protocol=dyndns2
use=web, web=https://api.ipify.org
server=updates.your-dns-provider.net
login=vpn-home
password=update-token
vpn.example.net

用 systemd 定时器每隔几分钟跑一次，而不是写 shell 循环；记录运营商返回的内容，而不是假定成功。把凭据当成钥匙来对待，因为它决定每个客户端被送去哪里：用限定范围的更新令牌代替账户密码，文件权限设成 0600，更新走 HTTPS。

落地之前先验证

一次查询就能告诉你外面世界看到的是什么，也会打印出改动之后要等多久的 TTL：

dig +noall +answer vpn.example.net @1.1.1.1

把那个地址和路由器的 WAN 地址比一比。一致，说明名字在干本职工作，还失败的属于入站可达性、密钥、或者一个没有重新解析的客户端。不一致，说明更新器发布的是错误的接口，常见原因是它跑在路由器后面的 VPN 主机上，而不是路由器本身。

准备一分钟能完成的回滚：记下最后一个可用地址和上一个 TTL，这样运营商出状况的下午，两样都能手动发布。

当答案是“不需要”

条件一或条件三不成立时，要改的是决策而不是配置。在运营商 NAT 后面，现实的选择是向运营商申请公网地址、把入口搬到一台地址稳定的 VPS 上，或者用自带会合点的覆盖网络。如果地址本来就是固定的，跳过更新器：一条 A 记录，跑 IPv6 就再加一条 AAAA 记录，端口转发不变。

客户端连着而地址在变的话，诚实的修法在客户端：重连逻辑和重试间隔，不是更快的更新器。再加一家服务商只是把间隔藏起来。

继续之前，按顺序确认四件事：

  • 更新器发布的地址和路由器 WAN 地址一致。
  • 记录 TTL 够短，改动几分钟内就能看到。
  • 端口转发绑的是接口，不是固定地址。
  • 上一次变动之后，有一个真实客户端重连并成功通过了流量。

四条都成立，就别动它；下一次故障是密钥或防火墙规则，不是命名问题。哪条不成立，先把那一行修好，再往上加会动的零件。RFC 2136 描述的是更新机制本身，想看看守护进程到底往线路上发了什么，可以读它。

相关文章