文章介绍了如何配置Pi-hole和Tailscale实现分片DNS（Split Horizon DNS），使Tailscale网络客户端和局域网客户端分别解析到不同的IP地址。作者原本使用OpenVPN，后改用基于Wireguard协议的Tailscale，因其速度更快。尽管Tailscale网络已运行一段时间，但作者尚未为网络客户端设置分片DNS，本文详细描述了如何通过Pi-hole实现这一功能，使Tailscale客户端解析到Tailnet IP，局域网客户端解析到局域网IP。

文章主要内容总结

标题: 使用Pi-Hole和Tailscale配置Split Horizon DNS

发布时间: 2025年7月5日

主要内容:

1. 背景介绍:

   • 作者长期使用VPN来保护设备在外出时的连接安全。最初使用OpenVPN，后来转向了基于Wireguard协议的Tailscale，因其连接速度更快。
   • Tailscale构建了一个网状网络，虽然网络已经运行了一段时间，但作者尚未为Tailscale客户端配置Split Horizon DNS。

2. Split Horizon DNS的需求:

   • 作者希望通过Pi-hole实现Split Horizon DNS，即Tailscale客户端返回Tailnet IP，而局域网客户端返回局域网IP。
   • 许多DNS名称已经实现了Split Horizon，局域网和外部互联网客户端都连接到同一个反向代理，但局域网客户端使用代理的本地IP连接。

3. Tailscale的特殊性:

   • 尽管可以通过WAN访问服务，但某些服务（如Nextcloud）的客户端不支持额外的认证，导致反向代理无法强制执行额外的认证。
   • 作者还提到使用地理封锁来减少攻击面，但这也带来了灵活性上的限制。通过为Tailnet配置Split Horizon DNS，可以避免这些问题。

4. 实现计划:

   • 作者计划让Tailscale客户端也通过Pi-hole进行DNS查询，但返回的是Tailnet IP。
   • Pi-hole基于dnsmasq的pihole-FTL，支持localise-queries设置，可以根据接收查询的接口返回不同的IP地址。

5. Docker容器的调整:

   • 作者最初使用桥接网络运行Pi-hole容器，但无法识别查询的物理接口。改为使用主机网络后，Pi-hole的Web界面无法绑定到端口80，最终通过环境变量WEB_PORT解决。
   • 在切换到主机网络后，Pi-hole无法响应DNS查询，原因是Pi-hole配置为仅响应eth0接口的查询，而实际接口为enp0s25。通过修改配置为“允许所有来源”后，问题解决。

6. Tailscale的配置:

   • 作者移除了之前的路由广告，并通过Tailscale的Web界面添加了Split DNS条目，使Tailscale客户端使用Pi-hole进行DNS查询。
   • 在Linux和Android设备上，作者需要手动启用Tailscale的DNS功能。

7. 结论:

   • 通过配置Split Horizon DNS，作者在外出时可以透明且更安全地访问服务。
   • Tailscale的网状网络特性使得设备在同一网段内可以直接连接，而无需通过远程协调器进行往返。
   • 作者还提到Tailscale与Mullvad的合作，使得在旅行时可以通过Mullvad路由所有连接。

图片: - - - - -

1. 关于Chromecast忽略本地DNS的问题

   • 评论1（leipert）指出Chromecast忽略本地DNS，建议强制将流量导向8.8.8.8/8.8.4.4的端口53，以通过PiHole进行拦截。
   • 关键引用：
     • "Chromecasts ignore local DNS... grrr"（Chromecast忽略本地DNS... 真是让人恼火）
     • "Can’t you force traffic to 8.8.8.8 / 8.8.4.4 (especially port 53) to hit your PiHole instead?"（你不能强制将流量导向8.8.8.8/8.8.4.4（特别是端口53）以通过PiHole拦截吗？）

2. 关于Tailscale的法律实体变更

   • 评论2（dolmen）提到Tailscale的法律实体已从加拿大公司变更为美国公司，引用了其服务条款中的相关内容。
   • 关键引用：
     • "However this is no longer the case. From Tailscale’s Terms of service 'Schedule A', 'New customer accounts on or after September 3, 2024' are bound to 'Tailscale US Inc., a Delaware corporation'"（然而，情况已不再如此。根据Tailscale的服务条款“附录A”，“2024年9月3日或之后的新客户账户”将受“Tailscale US Inc., 一家特拉华州公司”约束。）

3. 关于强制DNS流量和拦截DoH的实践

   • 评论3（elashri）分享了如何强制将所有DNS流量导向本地DNS（Adguard home + unbound），并拦截常见的DoH地址，尽管这不是完全防弹的解决方案。
   • 关键引用：
     • "I do force all plain DNS on port 53 to my local dns (Adguard home + unbound on a gl-inet router)."（我确实强制将所有端口53的普通DNS流量导向我的本地DNS（在gl-inet路由器上运行的Adguard home + unbound）。）
     • "This is not a bullet proof solution in case there is a semi known custom DoH an application use."（如果应用程序使用半已知的自定义DoH，这不是一个完全防弹的解决方案。）

4. 关于使用Headscale和VPN加密所有流量的建议

   • 评论4（snvzz）建议使用Headscale并通过VPN加密所有流量，即使在同一局域网内，以确保所有流量都是加密的。
   • 关键引用：
     • "Why trust the wires at all. Just run all traffic through VPN, even if it’s in the same LAN."（为什么要信任任何线路。只需通过VPN运行所有流量，即使在同一局域网内。）
     • "This way, I know all traffic is encrypted. I don’t have to worry about SMB or the like being plaintext."（这样，我知道所有流量都是加密的。我不必担心SMB等协议以明文传输。）

5. 关于IP欺骗和SSRF攻击的疑问

   • 评论5（udev4096）质疑允许192.168.3.0/24网段的IP是否可能导致攻击者伪造IP并进行SSRF攻击，或者nginx是否足够强大以检测此类攻击。
   • 关键引用：
     • "Can’t an attacker spoof an IP and do SSRF? Or is nginx too good at detecting those kinds of attacks?"（攻击者不能伪造IP并进行SSRF攻击吗？或者nginx是否足够强大以检测此类攻击？）