主页 / computer / 问题 / 1632340
Accepted
Huud Rych
Asked: 2021-03-11 10:25:41 +0800 CST

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

  • 772

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

我已经设置了一个 Windows Server VM ( 192.168.28.47/27 ) 和一个防火墙 VM NIC ( 192.168.1.21/24 )，这是 VMware Workstation vmnet0 上的一个桥接接口。

我在防火墙的 LAN 和 WAN 接口上都有一个允许所有流量的规则。由于某种原因，该规则似乎不起作用。服务器虚拟机收到来自 8.8.8.8 的 ping 回复，但无法访问 Internet。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

局域网上用于服务器 VM 的 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，我读到的是Multicast DNS和239.255.255.250。

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

防火墙新手，所以我肯定错过了一些东西。

firewall mdns

1 个回答

  1. Best Answer

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

    从第一个数据包跟踪：

    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

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

    IP 192.168.28.47.mdns > 224.0.0.251.mdns: 0 A (QM)？谷歌本地。(30)
    IP 192.168.28.47.mdns > 224.0.0.251.mdns: 0 AAAA (QM)？谷歌本地。(30)

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

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

    • 1

相关问题