StrongSwan 推送的 DNS 地址 Mac 无法访问

Mac 或 iPhone 会忽略你的 StrongSwan 服务器推送的公共解析器地址。把解析器移入客户端地址池，并只对池开放 53 端口。

一切正常，直到有人打开 MacBook。隧道建立成功，内网主机按 IP 地址可通，域名解析却失效了。在 iPhone 上同一份配置文件表现相同，而 Windows 和 Linux 客户端一切正常。推送的 DNS 属性通常就是元凶：服务器下发自己的公网接口地址，而 Apple 的 IKEv2 客户端不会把查询经隧道发往那里。把解析器移进地址池内，症状就会消失，客户端无需改动。

症状指向那个被推送的地址

当只有部分平台失败时，隧道和凭据几乎肯定没有问题，因为它们是共用的。不同之处在于每个客户端如何应用收到的配置负载，包括内部 DNS 服务器。一个接受该地址却让查询绕过隧道的客户端，最终会得到一个看得见却用不了的解析器。

公网地址是常见选择，因为它是管理员本来就熟悉的那一个。它也是唯一保证在隧道自身前缀之外的地址，而这恰恰是会弄坏 Apple 客户端的属性。

动手之前先看这个值。如果推送的解析器是服务器的 WAN 地址，你就找到了问题的形态，可以省去其余猜测。也把它和地址池前缀比一比，因为一个位于池内却在租用范围之外的地址，正是修复后应有的样子。花两分钟看配置，胜过在客户端抓一下午包。

把解析器从租用范围中划出来

给隧道规划一套地址方案，让解析器属于地址池所在子网，然后保留该地址，使它永远不会被租给客户端。在这个例子里，地址池是 10.180.7.0/24，服务器占用 10.180.7.1，租约从 10.180.7.2 开始。

rightsourceip=10.180.7.2/24
rightdns=10.180.7.1

池前缀与解析器共处一个子网，因此承载隧道流量的那条路由也承载查询。正是这一特性让修复能跨客户端通用。在 swanctl 配置里，同样的两个事实表现为连接上的池定义和 DNS 设置，而不是 ipsec.conf 语法。

服务器不需要为此新增物理接口。把 10.180.7.1 加到回环接口上，解析器就足以绑定并应答，因为客户端通过已存在的池路由就能到达它。把这个地址排除在租用范围之外，免得哪个客户端误领。如果地址池由外部 DHCP 或 RADIUS 服务管理，也要在那里保留该地址，否则第一个来请求的客户端就会拿走它。

绑定解析器并关闭 53 端口

分配地址不等于在该地址上监听。只监听 LAN 地址的解析器会拒绝或忽略发往池地址的查询，而客户端看到的超时看起来就像路由故障。

interface: 10.180.7.1
access-control: 10.180.7.0/24 allow
access-control: 0.0.0.0/0 refuse

这个 unbound 片段接受来自隧道池的查询，拒绝其他一切，这正是多数企业解析器想要的策略。如果同一实例还要应答 LAN 客户端，就显式加上 LAN 前缀，而不是把监听范围放宽到所有来源。

防火墙规则随后必须与解析器自身的访问控制一致。接受来自池的 53 端口，丢弃其他所有来源的该端口，但先检查链的顺序。

iptables -A INPUT -p udp --dport 53 -s 10.180.7.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 53 -s 10.180.7.0/24 -j ACCEPT
iptables -A INPUT -p udp --dport 53 -j DROP
iptables -A INPUT -p tcp --dport 53 -j DROP

更早的、更宽泛的接受规则会让最后两行形同虚设，解析器仍可从互联网访问。要带计数器查看生效的规则集，而不是相信你设想的顺序。另一种策略，即推送公网地址并允许任意来源查询，对许多客户端确实有效，但它把解析器暴露在互联网上，需要单独的限速和监控。

核实客户端实际收到了什么

先看服务器的视角，再看客户端的，因为两者的不一致很有信息量。池列表显示哪个地址被租出，安全关联列表显示连接是否以预期身份建立。

swanctl --list-sas
swanctl --list-pools
dig +short @10.180.7.1 intranet.plant.example

直接查询证明解析器会在池地址上应答，前提是从能到达它的主机发起。这并不证明 Mac 选择了那台服务器。在 macOS 上，scutil --dns 会按作用域服务列出解析器，比摘要面板信息更多；在 Windows 上，Get-DnsClientServerAddress 显示隧道适配器是否接受了推送的值。

如果客户端显示了池地址而查询仍然超时，隧道路由或防火墙链就是问题所在。报告没有解析器的客户端，说明配置负载从未落地，那么要查的是该平台如何应用推送设置，而不是网络。在改动其他东西之前，先记下你观察到的是这两种情况中的哪一种。这两种故障在支持工单里看起来一模一样，却通向相反的修复。

相关文章