☰

有人能解释一下这是怎么发生的吗？

tag-icon • tag-icon wireless-networking backtrack arp netdiscover
有人能解释一下这是怎么发生的吗？

netdiscover我在家庭网络上运行时似乎遇到了一些奇怪的结果。从电缆调制解调器到我的扫描仪（跳过一些外围设备），基本布局如下：

电缆调制解调器连接到我们的路由器，该路由器还可用作 DHCP 服务器和主 Wi-Fi AP。

从那里（再次跳过外围设备）连接转到另一个路由器上的 LAN 端口，该路由器已被剥离其路由器角色（DHCP 等）并且仅充当辅助 Wi-Fi AP。

我的笔记本电脑连接到辅助 AP，运行 Windows 7 x64。

我正在netdiscover笔记本电脑上的虚拟机中运行 Backtrack Linux。

虚拟机通过 VirtualBox 适配器连接到我的网络，以“桥接”模式运行。

该网络的地址位于 RFC 1918 地址空间的 10.0.0.0/8 范围内。

于是我netdiscover在 Backtrack VM 上运行了该程序。除了两个地址外，返回的大多数地址都与预期的差不多。

 IP            At MAC Address      Count    Len   MAC Vendor                   
 ----------------------------------------------------------------------------- 
 192.168.2.1     00:17:9a:8f:69:cf    01    060   D-Link Corporation           
 192.168.2.1     00:17:9a:8f:69:d0    01    060   D-Link Corporation

我对这是什么有一个相当可靠的猜测 - 一个 D-Link VoIP 路由器，我们只将其连接（硬线连接到路由器）以用于其 VoIP 功能。IP 地址看起来可能是该设备的出厂默认设置（我将在另一个时间对其进行故障排除）。

我现在想不通的是：为什么 192.168.2.1 的 D-Link 设备能够通过 10.xxx 网络接收并返回 ARP 数据包？

答案1

除非您明确说明要使用的范围，否则netdiscover将扫描常见网络，因此这将包括 192.168.0.0/16。

ARP 请求在第 2 层广播，因此即使 Backtrack PC 与 voip 盒位于不同的 IP 网络上，ARP 请求仍将被看到并回复。请求将采用 ARP 探测的形式，其中不包含要回复的 IP 地址 - 回复在第 2 层发送到发出请求的设备的 mac 地址。

ARP 探测是一种确定 IP 地址当前是否正在使用的方法。设备通常在“声明”IP 地址之前使用它，以确保本地网络上没有其他人正在使用它。但是，它可用于查看本地网络上正在使用哪些地址，并且 netdiscover 似乎可能会使用它。

虽然 arp 探测是第 3 层 IP 协议的一部分，但它在第 2 层运行。数据包看起来有点像这样：

From MAC: <host mac address>, To MAC: ff:ff:ff:ff:ff:ff, Payload: "Is anyone using IP address 192.168.1.1"

因此，目标 mac 是广播 mac 地址 - 全部为 1，它匹配所有地址。因此，任何第 2 层设备（例如交换机）都将从接收数据包的同一广播域中的所有端口广播它。在家用路由器中，这意味着所有 LAN 端口（家用路由器上的 LAN 端口是交换机端口）。如果任何 LAN 端口连接到另一个路由器的 LAN 端口，则 LAN 端口都位于同一个广播域中 - 数据包将从连接到第二个路由器的第一个路由器上的端口广播出去，第二个路由器将看到数据包的目的地是 ff:ff:ff:ff:ff:ff，因此将从自己的 LAN 端口广播它。

这里的重点是，无论 IP 地址如何，第 2 层广播数据包都会被网络上的每个设备看到。

所以每个设备都可以看到它。VoIP 设备看到这是一个 ARP 探测，并且发送者所追踪的 IP 地址与其配置的 IP 地址相匹配，因此会进行回复。

它无法回复原始设备的 IP 地址，因为 ARP 探测的本质是它由尚未拥有 IP 地址的设备使用 - 它用于查看所需的 IP 地址是否已被使用。因此，数据包中发送方 IP 地址通常所在的位置全为零。

因此，ARP 探测答复被发送到发送者的 MAC 地址。

相关内容