NetBird网络环境下DNS配置问题排查指南

问题背景

在使用NetBird构建的虚拟网络环境中，用户遇到一个典型的DNS解析问题：虽然已经正确配置了DNS服务器（Pi-hole）并设置了组策略，但组内客户端设备未能按照预期使用指定的DNS服务器进行域名解析。

环境配置

1. 网络拓扑：

   • 创建名为"Convidats"的Peer组
   • 指定vm1作为出口节点(exit node)
   • 在vm1上部署Docker化的Pi-hole DNS服务器
   • 开放53端口(TCP/UDP)

2. 软件版本：

   • Android客户端：0.28
   • 服务端(vm1)：0.29.4 (Docker容器)

问题现象

通过nslookup手动指定vm1作为DNS服务器时可以正常解析，但组内Peer的自动DNS请求未能路由到配置的DNS服务器。

排查过程

1. 服务验证：

   • 确认Pi-hole服务正常运行
   • 检查53端口监听状态：

     netstat -tunelp | grep 53
     

     输出显示Docker-proxy正确监听了所有接口的53端口

2. 网络连通性测试：

   • 从客户端可以telnet连接到vm1的53端口
   • 基础网络连通性正常

3. 配置检查：

   • 确认NetBird仪表盘已正确配置Nameserver
   • 但未设置明确的访问策略(Policy)

解决方案

经过深入排查，发现问题根源在于系统配置的完整性。虽然基础配置看似正确，但某些深层配置参数可能存在问题。建议采取以下步骤：

1. 完整服务重启：

   • 停止NetBird服务
   • 清理缓存配置
   • 重新启动服务

2. 策略配置：

   • 即使基础连通性正常，仍建议明确配置访问策略
   • 确保"Convidats"组有权限访问vm1的53端口

3. 配置验证：

   • 使用dig或nslookup工具验证DNS查询路径
   • 检查系统解析器配置(/etc/resolv.conf)

经验总结

在NetBird网络环境中配置自定义DNS服务时，需要注意：

1. 容器化服务要确保端口正确映射到宿主机
2. NetBird的组策略和DNS配置需要协同工作
3. 系统级DNS配置可能会覆盖应用层设置
4. 测试时应该区分手动指定DNS和系统自动DNS查询两种情况

通过系统性排查和验证，最终确认问题是由于某些配置不完整导致的，重新配置后DNS服务恢复正常工作。