我在 Raspberry Pi 上使用 unbound。我尝试使用 dnsmasq 来查看是否是应用程序,但它也不起作用。我用 wireshark 看到我的查询从我的计算机发送到树莓派,但没有任何东西到达服务器。我在服务器上运行 tcpdump 并监控 unbound 的详细:5 日志,但 unbound 不知道通过 LAN 的查询,但是当我在服务器上挖掘 mollevi.test @localhost 时,答案是正确的。我尝试使用我的 tailscale vpn,我临时关闭了 LAN 中的所有防火墙,并在 LAN 和移动数据(与 tailscale 一起使用)中尝试了 Linux 和 Windows 客户端(不是 VM)。我可以使用每个提到的设置在每个方向 ping 端口 80,但 unbound 的日志中仍然没有关于非 @localhost 的查询的任何信息。Dnsmasq 做了同样的事情,但如果有办法的话,我想使用 unbound。以下是我的配置:

server:
verbosity: 5
interface: 0.0.0.0
port: 53
do-ip4: yes
do-ip6: no
do-udp: yes
do-tcp: yes
access-control: 192.168.1.0/24 allow
root-hints: "/etc/unbound/root.hints"

local-zone: "mollevi.test." static
local-data: "mollevi.test. 10800 IN A 127.0.0.1"
logfile: "/etc/unbound/unbound.log"

当我使用 tailscale 时,我添加了access-control: 100.64.0.0/10 allow

sudo netstat -ptuln | grep :53 – 我稍微改变了配置并禁用了 ipv6,但这里是更新。

tcp 0 0 pi.lan.ip.address:53 0.0.0.0:* LISTEN  27927/unbound
udp 0 0 pi.lan.ip.address:53 0.0.0.0:* 27927/unbound

这发生在 Windows 机器上:

PS> nslookup mollevi.test pi.lan.addr.ess
DNS request timed out.
    timeout was 2 seconds.
Server:  UnKnown
Address:  pi.lan.addr.ess

DNS request timed out.
    timeout was 2 seconds.
DNS request timed out.
    timeout was 2 seconds.
DNS request timed out.
    timeout was 2 seconds.
DNS request timed out.
    timeout was 2 seconds.
*** Request to UnKnown timed-out

总结:

  1. Windows/Linux -> netstat/dig -> wireshark(客户端->服务器) ☑ -> Raspberry PI -> tcpdump☑ -> unbound.log☒ -> wireshark(服务器->客户端) ☒ -> 请求超时
  2. Raspberry -> dig mollevi.test @lan.ip.addr.ess -> 正确答案

谢谢您的任何建议。

2

  • 您能否显示sudo netstat -ptuln | grep :53– 只是为了验证端口 53 上正在监听的内容 – 另外,既然您设置了,do-ip6: yes您不应该还包括吗?另外,从您的 Windows 机器interface: ::0添加输出nslookup mollevi.test pi.ip.addr.ess


    – 


  • @JaromandaX 谢谢,这很有用,我更新了帖子。


    – 



最佳答案
1

您是否已使用 IPTables 和/或 UFW 允许来自端口 53 的传入流量?

sudo iptables -I INPUT -p udp --dport 53 -j ACCEPT
sudo iptables -I INPUT -p tcp --dport 53 -j ACCEPT
# if UFW is enabled on your Raspberry 
sudo ufw allow in 53
sudo ufw allow out 53

1

  • 是的。我允许主防火墙后面的所有设备流量,以排除防火墙取消预期通信的可能性。但这并没有改变意外行为。


    –