☰

防火墙日志显示查询回复给 mdns

tag-icon • tag-icon firewall mdns opnsense
防火墙日志显示查询回复给 mdns

此设置来自 VMware Workstation 中的网络 (192.168.29.0/27)，如下所示 网络图

我已经设置了一个 Windows Server VM（192.168.28.47/27) 以及防火墙虚拟机网卡 (192.168.1.21/24)，即桥接VMware Workstation 的 vmnet0 上的接口。

我有一个全部流量允许防火墙的 LAN 和 WAN 接口上都存在规则。由于某种原因，该规则似乎不起作用。服务器虚拟机收到来自 8.8.8.8 的 ping 回复，但无法访问互联网。NAT 接口192.168.47.140，NAT 网关是192.168.47.2。我关闭了防火墙并测试，服务器可以正常访问互联网。

WAN 上没有任何主机的 tcpdump

root@firewallwm:~ # tcpdump -i em1 -n
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on em1, link-type EN10MB (Ethernet), capture size 262144 bytes
17:53:05.670752 IP 192.168.47.140.27089 > 188.165.3.28.123: NTPv4, Client, length 48
17:53:07.652383 IP 192.168.47.140.10811 > 188.125.64.7.123: NTPv4, Client, length 48
17:53:07.673695 IP 188.125.64.7.123 > 192.168.47.140.10811: NTPv4, Server, length 48
17:53:08.624653 IP 192.168.47.140.28314 > 91.209.0.17.123: NTPv4, Client, length 48
17:53:08.672014 IP 91.209.0.17.123 > 192.168.47.140.28314: NTPv4, Server, length 48
17:53:09.680357 IP 192.168.47.140.44852 > 80.237.128.148.123: NTPv4, Client, length 48
17:53:09.680434 IP 192.168.47.140.58287 > 162.159.200.123.123: NTPv4, Client, length 48
17:53:09.698470 IP 162.159.200.123.123 > 192.168.47.140.58287: NTPv4, Server, length 48
17:53:09.720681 IP 80.237.128.148.123 > 192.168.47.140.44852: NTPv4, Server, length 48
17:53:12.633164 IP 192.168.47.140.59261 > 94.199.173.123.123: NTPv4, Client, length 48
17:53:12.671315 IP 94.199.173.123.123 > 192.168.47.140.59261: NTPv4, Server, length 48
17:53:54.738729 IP6 fe80::20c:29ff:fee8:8d15.546 > ff02::1:2.547: dhcp6 solicit
17:58:48.516746 IP 192.168.47.1.64045 > 239.255.255.250.1900: UDP, length 173
17:58:49.517887 IP 192.168.47.1.64045 > 239.255.255.250.1900: UDP, length 173
17:58:50.520981 IP 192.168.47.1.64045 > 239.255.255.250.1900: UDP, length 173
17:58:51.522420 IP 192.168.47.1.64045 > 239.255.255.250.1900: UDP, length 173

服务器虚拟机 LAN 上的 tcpdump

root@firewallwm:~ # tcpdump -i em3 host 192.168.28.47
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on em3, link-type EN10MB (Ethernet), capture size 262144 bytes
17:37:05.247138 IP 192.168.28.47 > dns.google: ICMP echo request, id 1, seq 54, length 40
17:37:05.260352 IP dns.google > 192.168.28.47: ICMP echo reply, id 1, seq 54, length 40
17:37:06.269572 IP 192.168.28.47 > dns.google: ICMP echo request, id 1, seq 55, length 40
17:37:06.283080 IP dns.google > 192.168.28.47: ICMP echo reply, id 1, seq 55, length 40
17:37:07.289858 IP 192.168.28.47 > dns.google: ICMP echo request, id 1, seq 56, length 40
17:37:07.298693 IP dns.google > 192.168.28.47: ICMP echo reply, id 1, seq 56, length 40
17:37:08.302397 IP 192.168.28.47 > dns.google: ICMP echo request, id 1, seq 57, length 40
17:37:08.311143 IP dns.google > 192.168.28.47: ICMP echo reply, id 1, seq 57, length 40
17:37:09.866366 ARP, Request who-has firewallwm.vlab.lab (00:0c:29:e8:8d:29 (oui Unknown)) tell 192.168.28.47, length 46
17:37:09.866397 ARP, Reply firewallwm.vlab.lab is-at 00:0c:29:e8:8d:29 (oui Unknown), length 28
17:37:36.493211 IP 192.168.28.47.60468 > 239.255.255.250.1900: UDP, length 173
17:37:37.509653 IP 192.168.28.47.60468 > 239.255.255.250.1900: UDP, length 173
17:37:38.523971 IP 192.168.28.47.60468 > 239.255.255.250.1900: UDP, length 173
17:37:39.540750 IP 192.168.28.47.60468 > 239.255.255.250.1900: UDP, length 173
17:39:36.498026 IP 192.168.28.47.60469 > 239.255.255.250.1900: UDP, length 173
17:39:37.510526 IP 192.168.28.47.60469 > 239.255.255.250.1900: UDP, length 173
17:39:38.512683 IP 192.168.28.47.60469 > 239.255.255.250.1900: UDP, length 173
17:39:39.512937 IP 192.168.28.47.60469 > 239.255.255.250.1900: UDP, length 173
17:39:53.018203 IP 192.168.28.47.netbios-ns > 192.168.28.63.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
17:39:53.027039 IP 192.168.28.47.mdns > 224.0.0.251.mdns: 0 A (QM)? google.local. (30)
17:39:53.032230 IP 192.168.28.47.mdns > 224.0.0.251.mdns: 0 AAAA (QM)? google.local. (30)
17:39:53.033009 IP 192.168.28.47.56963 > 224.0.0.252.5355: UDP, length 24
17:39:53.040405 IP 192.168.28.47.62251 > 224.0.0.252.5355: UDP, length 24
17:39:53.445140 IP 192.168.28.47.56963 > 224.0.0.252.5355: UDP, length 24
17:39:53.460646 IP 192.168.28.47.62251 > 224.0.0.252.5355: UDP, length 24
17:39:53.771373 IP 192.168.28.47.netbios-ns > 192.168.28.63.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
17:39:54.038374 IP 192.168.28.47.mdns > 224.0.0.251.mdns: 0 A (QM)? google.local. (30)
17:39:54.039114 IP 192.168.28.47.mdns > 224.0.0.251.mdns: 0 AAAA (QM)? google.local. (30)
17:39:54.536041 IP 192.168.28.47.netbios-ns > 192.168.28.63.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST

由于某种原因（或设置），来自 WAN 192.168.47.1 的回复将224.0.0.251我读到的是多播 DNS， 和239.255.255.250。

因此有 2 个问题，1) ping 回复是如何从 Google 的 DNS 发出的？！2) 为什么数据包没有到达 WAN 接口。

我是防火墙的新手，所以我肯定遗漏了一些东西。

答案1

我认为您误解了数据包跟踪，这让您提出了错误的问题。让我尝试澄清一些事情：

从第一个数据包跟踪来看：

IP 192.168.47.1.64045 > 239.255.255.250.1900：UDP

这是您的路由器广告 UPnP 服务。此数据包由您的路由器本身创建；此数据包不是从其他地方转发的。

从第二个数据包跟踪来看：

IP 192.168.28.47.60468 > 239.255.255.250.1900：UDP

这是您的 Windows Server VM 尝试执行 UPnP。此数据包由您的 Windows Server VM 创建。此数据包不是从其他地方转发的。

IP 192.168.28.47.mdns > 224.0.0.251.mdns：0 A（QM）？google.local。（30）
IP 192.168.28.47.mdns > 224.0.0.251.mdns：0 AAAA（QM）？google.local。（30）

这看起来像是 Windows Server VM 上的某个程序正在查找主机名“google”。注意：它不是在查找“google.com.”，而是在查找没有点或顶级域的“google”。因此，Windows 正在其配置的所有搜索域中搜索主机名“google”，包括“.local”（多播 DNS）。因此，它通过本地 LAN 上的多播询问“这里有没有名为‘google’的设备”？（它似乎没有得到答案。）

这是不是DNS回答（回复）来自单播 DNS 服务器或本地 mDNS 主机。这是 mDNS询问(请求) 由您的 Windows Server VM 创建。

相关内容