NextDNS CLI VLAN DNS重定向问题排查与解决方案

问题背景

在使用NextDNS CLI工具(版本1.44.4)配合UDM网络设备(固件版本9.0.108)时，遇到一个关于VLAN间DNS流量重定向的有趣问题。用户配置了多个VLAN分别对应不同的NextDNS Profile ID：

• 主网络使用Profile ID 1000
• IoT VLAN使用Profile ID 2000
• 儿童网络VLAN使用Profile ID 3000
• 游戏VLAN未特别配置，默认回退到主Profile ID 1000

问题现象

用户发现，当尝试通过NAT规则将IoT VLAN(192.168.6.0/24)中的Hue Bridge设备的DNS请求(端口53)重定向到该VLAN的网关(192.168.6.1)时，DNS查询被错误地路由到了主Profile ID 1000，而不是预期的IoT VLAN Profile ID 2000。

更奇怪的是，查询日志显示请求源IP为192.168.1.179(一个不存在的IP)，而非设备实际的IP地址192.168.6.2。

初步分析

这种现象表明，在DNS请求重定向过程中，源IP信息可能未被正确保留。在典型的网络环境中，NAT规则应当保持源IP不变，但这里似乎发生了源地址转换(SNAT)，导致请求看起来像是来自其他网络段。

排查过程

1. 检查NextDNS查询日志：确认查询确实被路由到了错误的Profile ID，并且源IP异常
2. 尝试MAC地址绑定：临时解决方案是通过MAC地址将设备强制映射到正确的Profile ID
3. 系统重启测试：完全重启UDM设备和NextDNS CLI服务后，问题意外解决

根本原因

经过分析，问题可能源于以下方面：

1. UDM NAT规则实现：某些固件版本中，NAT规则对DNS流量的处理可能存在bug，未能正确保持源IP信息
2. NextDNS CLI缓存：服务可能缓存了旧的网络配置信息，导致路由决策错误
3. 服务启动顺序：NextDNS CLI服务未能在系统启动时自动运行，表明服务管理可能存在问题

解决方案

1. 完整系统重启：重启UDM设备和NextDNS CLI服务可以清除潜在的缓存问题
2. 服务自启动配置：确保NextDNS CLI服务配置为系统启动时自动运行
3. 固件升级：检查并安装最新的UDM固件版本，可能包含相关修复
4. 替代重定向方法：考虑使用防火墙规则而非NAT规则进行DNS重定向

最佳实践建议

1. 在配置VLAN特定的DNS路由时，始终检查查询日志确认实际路由路径
2. 对于关键设备，可考虑使用MAC地址绑定作为备用路由策略
3. 定期检查并更新网络设备和DNS解析服务的固件/软件版本
4. 复杂的网络配置变更后，建议执行完整重启以确保所有服务状态一致

总结

这个案例展示了在复杂网络环境中DNS流量管理可能遇到的边缘情况。通过系统性的排查和验证，最终确认问题源于服务状态而非配置错误。这提醒我们在网络故障排查时，除了检查配置外，也应考虑服务状态和系统级因素。