Pi-hole在Raspberry Pi 5上使用NetworkManager时的接口绑定问题解析

问题背景

在将Pi-hole从Raspberry Pi 4迁移到Raspberry Pi 5的过程中，用户遇到了DNS服务绑定异常的问题。原本在Pi 4上使用dhcpcd时正常工作的配置，在Pi 5上使用NetworkManager后出现了服务试图绑定到多个非预期接口的情况。

现象描述

Pi-hole的FTL服务（基于dnsmasq）在启动时尝试绑定到多个IP地址：

• 192.168.1.188:53（eth0接口）
• 127.0.0.3:53（lo接口）
• 并报告127.0.0.2:53地址已被占用

这与预期配置不符，按照配置Pi-hole应该只监听127.0.0.1:53，而127.0.0.2:53应由unbound服务独占。

配置对比分析

原Pi 4工作配置：

• 使用dhcpcd管理网络
• 01-pihole.conf中仅指定了interface=eth0和listen-address=127.0.0.1
• 无需额外排除接口的配置

新Pi 5问题配置：

• 使用NetworkManager替代dhcpcd
• 相同的01-pihole.conf和setupVars.conf配置
• 出现多接口绑定问题

根本原因

NetworkManager与dhcpcd在网络接口管理方式上存在差异：

1. NetworkManager可能会自动管理更多网络接口
2. 默认情况下dnsmasq会尝试在所有活动接口上绑定
3. 新系统（Bookworm）可能对网络配置有不同默认行为

解决方案

通过修改/etc/dnsmasq.d/01-pihole.conf，显式排除不需要监听的接口：

except-interface=lo
except-interface=wlan0

这两条指令明确告诉dnsmasq：

1. 不要监听环回接口（lo），避免与unbound冲突
2. 不要监听无线接口（wlan0），即使它存在但不使用

技术要点

1. 接口绑定优先级：在NetworkManager环境下，显式排除比隐式包含更可靠
2. 服务隔离原则：DNS服务应该明确指定监听范围，避免与其他服务冲突
3. 系统升级影响：从Bullseye到Bookworm的网络栈变化可能导致配置差异

最佳实践建议

1. 在NetworkManager环境下部署Pi-hole时，建议总是显式指定要排除的接口
2. 对于复杂DNS架构（如Pi-hole+unbound+第三方DNS工具），应该：
   • 为每个服务分配专用IP（如127.0.0.1/2/3）
   • 明确每个服务的监听范围
   • 使用lsof/netstat定期检查端口绑定情况
3. 迁移系统时，注意网络管理工具变更可能带来的配置差异

总结

这个案例展示了网络管理工具变更对服务配置的影响。在Pi-hole部署中，特别是在使用NetworkManager的较新系统上，显式声明排除接口是确保DNS服务按预期工作的关键步骤。这既保证了服务的稳定性，也避免了与其他本地服务的端口冲突。