我在使用 VMPlayer 免费版在虚拟设置上使用 Netdiscover 进行渗透测试时遇到了问题。攻击机器位于 VMWare NAT 网络接口上，而目标机器位于 VMWare 主机专用上。我发现 Netdiscover 无法正常工作，因为 VMWare NAT 接口没有用目标机器的 IP/MAC 填充其 ARP 表（Netdiscover 使用 ARP）。从 NAT 到主机专用（http、ping）的所有其他测试协议均正常工作。原始问题位于https://security.stackexchange.com/q/105263/91684。
我查看了 VMWare 文档，但未发现有关如何填充 ARP 的任何明确信息。
这是正常的 VMWare 行为吗，还是我做错了什么？
答案1
网络发现作品......
通过主动发送 arp 请求
Arp 请求不会跨越网关。首先，在 Linux 机器上我们激活IPv4转发，但 IPv4 数据包是 OSI 第 3 层对象，而 ARP 请求是 OSI 第 2 层对象，因此 Linux 内核中没有任何地方有将 ARP 请求转发到另一个接口的指令。
这是确切地你的情况：一旦 ARP 请求到达主机的接口，它将被丢弃，因为需要 MAC 的 IP 与接口的 IP 不匹配。由于上述原因，请求也不会转发到另一个接口。因此，你的主机（正确地）丢弃了 ARP 请求，该请求将得不到答复。这解释了你的设置中 Netdiscover 失败的原因。
上述失败不是由于 VMWare 中不同网络之间没有适当的网关。即使忽略 Linux 服务器无法转发除 IPv4 对象之外的任何内容（IE假设您有非 Linux 网关/路由器），网关最常见的行为是使用以下方式响应远程主机的 ARP 请求他们自己的 MAC 地址，例如以下是远程主机的 ARP 操作换句话说，在远程主机的 MAC 地址与提供的 IP 匹配之前，没有上游 ARP 请求链。上述最小行为（返回本地网关的 MAC 地址）也不常见。
所有这些都可以在 Debian 机器上轻松测试：
sudo apt-get install iputils-arping
sudo arping -f -c 1 -w 5 -I eth0 8.8.8.8
在其他所有操作系统上也会出现类似的情况。你会发现没有收到任何回复。你也可以使用以下traceroute命令查找你自己的一些上游网关的 IP 地址：
sudo arping -f -c 1 -w 5 -I eth0 IP_of_Upstream_Gateway
也将得不到答复。
为了测试Netdiscover你的设置，你必须将所有虚拟机（攻击者和被攻击者）放在同一子网. 然后ARP就可以起作用了。