尧图网站建设 
简介Netdiscover是一款开源的ARP网络扫描工具主要面向网络管理员与安全测试人员用于在无线网络或缺乏DHCP的环境中快速发现活跃设备、获取IP与MAC地址并推测网络拓扑。这份源码包为netdiscover-0.3-pre-beta7共包含39个文件以C语言源代码与头文件为主辅以configure、Makefile等自动构建脚本及规格说明文档整体仅359KB适合希望研究其实现原理或自行编译定制的中高级用户。目前已有262人学习下载。通过阅读源码可掌握ARP请求-响应机制在真实工具中的落地写法理解无线网络探测的常见思路同时可借助其识别隐藏无线网络的能力配合nmap、ettercap等工具开展更全面的网络评估与安全审计。压缩包内附有README、ChangeLog、TODO等文档便于快速上手和追踪开发历史是一份兼具学习价值与实战价值的开源软件资料。1. 为什么有了Nmap我还会在工具箱里留一个 Netdiscover给客户做网络资产盘点的时候我吃过一次亏拿 Nmap 去扫一个 50 台设备的办公网-sn探活结果只有 30 台。排查到最后发现一部分打印机和 IP 电话对 ICMP 和 TCP 探测直接装死但它们在网络上明明活得好好的。后来换上 Netdiscover 这个开源 ARP Scanner同一网段几乎没有漏网。原因不玄学三层探测可以被设备策略忽略而二层 ARP 是任何 IP 协议栈都无法拒绝的应答机制。Netdiscover 解决的问题很具体快速摸清一个局域网里有谁在线、它们的 MAC 地址属于哪个厂商以及哪些 IP 正在被占用。它适合网络运维做资产梳理、安全审计做接入发现、以及排查 IP 冲突这类日常破事。接下来我把原理、安装、参数和坑一次讲完照着跑就能用。2. ARP 扫描原理二层发现为什么比三层探测稳2.1 一条 ARP 请求怎么把整个网段变成可见的ARP 的完整流程是主机 A 要向主机 B 发数据但只知道 B 的 IP不知道 B 的 MAC。于是 A 在本地广播域里发一条「谁的 IP 是 192.168.1.20请把你的 MAC 告诉我」的请求目标主机 B 收到后回一条单播「我的 IP 是 192.168.1.20我的 MAC 是 xx:xx:xx:xx:xx:xx」。A 把这条映射写进自己的 ARP 缓存表后续通信直接按缓存发不再广播。Netdiscover 的主动模式就是把这个过程放大向网段里每一个可能的 IP 都发一次 ARP 请求谁回应就把谁记下来。关键点在于这个请求是二层的不经过路由器也不依赖目标主机开放任何 TCP/UDP 端口。哪怕目标机器的防火墙把 ICMP、TCP 探针全丢了它也无法拦掉自己网卡协议栈对 ARP 请求的自动应答。这就是 Netdiscover 在局域网发现场景里比三层扫描稳的核心原因。实际抓包看更直观。在网段里跑一次主动扫描用 Wireshark 或者 tcpdump 在另一台机器上监听会看到连续不断的 ARP 请求sudo tcpdump -i eth0 -n arp输出里每一个who-has请求都对应 Netdiscover 发出的探测每一个reply就是一台存活主机的自曝。扫描器本身不需要装任何客户端目标机器也不需要装任何软件这是这类二层发现工具最大的价值。2.2 主动模式与被动模式一个撒网一个蹲点Netdiscover 有两种工作模式适合完全不同的场景。主动模式是默认行为指定一个 IP 范围然后向该范围内每个地址发 ARP 请求。它的优点是快一个 /24 网段几秒内就能出结果缺点是会产生明显的广播流量。在一个 254 个地址的网段里每一轮扫描就会产生 254 条 ARP 请求如果边上还挂着网络监控设备这些请求会被如实记录下来这是后续被安全团队找上门的主要原因。被动模式是加-p参数此时 Netdiscover 不再发包而是把网卡设为混杂模式静静监听网络里已有的 ARP 请求和应答。办公楼里任何一台设备开机、访问网关、找打印机都会发出 ARP 流量Netdiscover 把这些对话全部记录下来照样能还原出活跃主机清单。它的优点是零打扰适合在敏感网络、生产网段里做摸底缺点是需要等网络里没人说话它就什么都没收获。刚到一个陌生网络我的习惯是先被动听半分钟看有多少设备在自主通信再决定要不要主动扫一轮。被动模式的结果往往比主动模式更接近真实使用状态因为那本来就是业务流量的一部分。2.3 Netdiscover 和 Nmap 的定位差异什么时候用谁Nmap 也可以发 ARP 扫描nmap -sn -PR 192.168.1.0/24就是纯 ARP 探测。那为什么还要单独装 Netdiscover两者的设计目标是完全相反的。对比项NetdiscoverNmap -sn -PR扫描机制固定发 ARP 请求聚焦 MAC 层ARP 为主必要时混合 ICMP/TCP 探活界面形态实时刷新的终端表看到设备一台台出现等全部跑完输出列表厂商识别内置 OUI 表直接标出设备厂商默认不做厂商标注被动模式支持-p参数即可不支持靠其他工具配合长时间监听可以持续跑适合盯接入变化一轮跑完就结束不适合驻留可脚本化输出格式简单配合 awk 方便需要-oG等额外参数才能解析Netdiscover 更像一个持续工作的网段监听器而不是一次性扫描器。Nmap 的价值在于端口、服务和漏洞探测那是 Netdiscover 完全不具备的能力。我的分工方式先用 Netdiscover 搞清楚「网段里有哪些设备」再对感兴趣的 IP 用 Nmap 做「这些设备开了什么端口、跑了什么服务」。Netdiscover 当前站Nmap 接棒干细活。2.4 选型理由为什么二层发现比三层探测稳三层探测常用的手段是发 ICMP Echo 请求或者对常见端口发 TCP SYN 包。这两种方式都会遇到同一个问题目标设备不一定理会。打印机节能状态下可能不响应 pingWindows 防火墙默认拦截 ICMP某些工控设备对陌生连接直接无视。但这些设备的 IP 协议栈为了能正常通信必须随时响应 ARP。这不是应用层行为而是网卡驱动和内核协议栈的固有问题关不掉。选了 Netdiscover 还有一个实际收益它能识别网卡厂商。通过 MAC 地址前三位OUI对照 IEEE 分配的厂商表Netdiscover 会标出谁家的设备、大概率是路由器还是网卡。在一个混乱的办公网里看到一长串Apple、Dell、Cisco比面对一串十六进制 MAC 地址直观太多。这也是很多运维愿意留它的原因——不只是扫 IP而是在给整张网做画像。3. 安装与依赖三种装法从 apt 到源码编译的完整路径3.1 Debian/Ubuntuapt 装上之后先跑一次自检在 Debian 系发行版上装 Netdiscover 是最省事的一条路软件源里直接有编译好的二进制包。装完先别急着扫描先确认厂商库文件有没有正确安装否则后面扫出一堆 Unknown 你会以为网络出问题了。sudo apt update sudo apt install -y netdiscover netdiscover -h安装过程本身没有什么需要解释的netdiscover -h用来确认命令已经被放进 PATH 里。需要注意的一点是不同版本的 Debian/Ubuntu 对 Netdiscover 的打包情况不太一样某些 LTS 版本源里的版本可能偏老功能上没有区别但输出格式可能有微小差异。如果你在脚本里解析 Netdiscover 的输出建议以实际环境的输出为准不要拿网上别人的解析脚本直接套。自检厂商库的常见做法是执行netdiscover -L该命令会列出内置的 MAC 厂商映射表并退出。如果命令报错或者列出的是空表说明 OUI 数据文件在安装时没有正确落位后面所有扫描结果都会变成一堆 Unknown MAC 地址毫无可用性。3.2 从源码编译安装解决依赖问题的完整路径如果你的发行版软件源里没有 Netdiscover或者你需要一个较新版本自带的功能就得走源码编译。Netdiscover 的构建依赖主要有 libpcap 和 libnet前者负责抓包后者负责构造和发送 ARP 报文。两个库缺一个编译到一半就会报头文件找不到的错误。# 安装编译工具链和依赖开发包 sudo apt install -y build-essential autoconf automake libpcap-dev libnet-dev # 从 GitHub 找到 netdiscover 的开源仓库并克隆到本地 git clone https://github.com/你的仓库/netdiscover.git cd netdiscover # 源码包如果没有直接带 configure 脚本先自动生成 autoreconf -i ./configure make sudo make install这里的逻辑顺序不能乱。libpcap-dev和libnet-dev提供的是编译时需要的头文件如果先执行./configure再装依赖配置脚本会检测不到库函数导致生成错误的 Makefile。autoreconf -i是从 Git 仓库拉下来的源码常见步骤它根据 configure.ac 和 Makefile.am 生成 configure 脚本从官方 release 包解压的源码通常已经带好了 configure可以直接跳过这步。编译完成后netdiscover默认安装到/usr/local/bin/。如果你的 PATH 里没有这个目录跑命令时会提示 command not found但明明编译成功了。这种情况直接用全路径执行/usr/local/bin/netdiscover -h或者执行sudo ldconfig刷新动态链接库缓存后再试。真遇到这个问题说明系统在编译时找到了库但运行时没找到多半是 libnet 的 .so 文件装到了非默认路径。3.3 Fedora/RHEL 系EPEL 源没有就打两手准备RHEL 系的软件源默认不带 Netdiscover常见的做法是先启用 EPEL 仓库再尝试安装。EPEL 里有没有这个包取决于仓库的维护状态不同版本差异很大所以装之前先搜索确认。# 启用 EPEL 仓库后搜索是否存在该包 sudo dnf install -y epel-release sudo dnf search netdiscover # 如果搜索有结果直接安装没结果就回到源码编译路径 sudo dnf install -y netdiscoverdnf search这一步很多人会跳过结果装了半天提示 Nothing to do。先搜再装能省掉这个无用功。另外RHEL 系源码编译时依赖包名跟 Debian 系不一样对应关系大致是libpcap-devel和libnet-devel而不是-dev后缀。编译前把这俩装上后面./configure才不会被卡住。至于 libnet 本身某些 RHEL 版本没有现成的 RPM 包需要从源码单独编译那就要先去解决 libnet 的构建依赖再回来编译 Netdiscover。3.4 root 权限和混杂模式提前把运行环境弄好Netdiscover 的两类操作都对权限有硬性要求。发 ARP 请求需要直接操作 raw socket抓包需要把网卡切到混杂模式这两件事普通用户都做不了。所以在使用文档里你看到的所有扫描命令几乎都带着sudo这是设计如此不是装样子。被动模式对网卡有一个额外要求混杂模式需要手动开启或者依赖工具自己调用。如果网卡没有正确进入混杂模式被动模式只能收到发往本机的包ARP 广播请求能收到一部分但应答和别人的单播就会漏掉结果严重偏少。手动开启的方式是sudo ip link set dev eth0 promisc on扫描结束后可以把混杂模式关掉避免网卡持续接收无关流量增加负载。执行完netdiscover -p后用ip link show eth0查看网卡状态确认没有停留在 promisc 模式。这一步虽然不影响扫描结果但在干净的生产网里开着混杂模式本身就会触发安全告警扫描完随手关掉是个习惯问题。4. 主动扫描实操用一条命令跑通整个网段的主机发现4.1 最小成型命令扫描一个网段需要哪些参数Netdiscover 最核心的用法是主动模式加一个目标网段以下命令扫当前网卡所在的所有 IPsudo netdiscover -i eth0 -r 192.168.1.0/24-i指定用哪块物理网卡发包-r指定扫描范围。这两个参数建议每次扫描都显式写出来。不写-i时工具会自动选一块接口在有多块网卡的机器上自动选择的结果常常不是你想要的不写-r时扫描范围为空命令不会执行。命令跑起来后终端会进入一个实时刷新的表格界面每一行是一台设备从左到右依次是 IP 地址、MAC 地址、厂商名、响应计数。你会看到设备一行一行往上添而不是等全部扫完才一次性输出。这是 Netdiscover 和 Nmap 交互方式上最大的区别对排查问题很有帮助哪台设备没有回应你能当场看到它是没响应还是还在等。如果要扫描多个互不连续的网段把多个范围一次性传给-r参数中间用逗号分隔即可。例如-r 192.168.1.0/24,10.10.0.0/24会按顺序扫两个网段。这个写法比分两次跑省事也便于把结果统一落进一份日志里。4.2 必调参数表轮次、延迟、输出格式一次说清主动扫描不是跑一轮就结束默认情况下 Netdiscover 会持续发送 ARP 请求并不断刷新设备表除非手动 CtrlC 终止。实际使用中通常不想让它无限跑需要限制轮次和节奏。直接扫整个网段之前先看这几个参数参数作用典型值-c指定扫描轮数跑完自动退出-c 3-t等待 ARP 响应的时间影响一轮扫描耗时-t 100-s每条 ARP 请求之间的间隔控制发包速率-s 10-P扫描结束后打印结果并退出与-c搭配使用-r指定扫描的 IP 范围192.168.1.0/24-l从文件读取 IP 范围列表适合批量场景-l ip_list.txt-p进入被动监听模式不发包单独使用-m指定自定义 MAC 厂商表文件-m /path/to/oui.txt一个比较稳妥的组合是sudo netdiscover -i eth0 -r 192.168.1.0/24 -c 3 -t 100 -P-c 3让扫描只跑三轮-t 100把每轮等待时间控制在 100 毫秒左右-P在扫描结束时打印汇总结果。这个组合的优点是行为可预期无论网段里有多少设备命令都会在几秒内结束不会一直驻留刷屏适合在维护窗口里快速摸底。-s参数的典型应用场景是在办公网做长时间驻留扫描。把间隔调大发包速率降低对现有网络的冲击就小。默认的快速扫描在生产网里可能会引发交换机端口安全策略的告警把-s调到 100 毫秒以上扫描行为的可观测性就会下降很多不是完全不可见但不再是让人一眼警觉的扫描风暴。4.3 把实时扫描结果存成资产清单解析与格式化Netdiscover 实时界面的数据不便于直接做后续处理需要让它输出成纯文本再交给脚本处理。-P参数输出的汇总格式相对规整直接重定向到文件就能留档sudo netdiscover -i eth0 -r 192.168.1.0/24 -c 3 -P scan_result.log # 从日志中提取所有 IP 和 MAC按设备去重 awk {print $1, $2} scan_result.log | sort -uawk里的列号依赖实际输出的空格分隔格式不同版本可能有细微差别。第一次跑完建议先head看一下原始输出长什么样再调整列号。提取出来的 IP-MAC 对可以直接作为资产清单的原始素材。如果想要更结构化的数据把输出处理成 CSV 也方便后续导入表格工具体系sudo netdiscover -i eth0 -r 192.168.1.0/24 -c 3 -P | awk NR2 {gsub(/^ | $/, ); print $1 , $2 , $3} assets.csv这个命令的NR2是跳过表头gsub去掉行首行尾的多余空格避免 CSV 字段里夹着制表符。字段分别是 IP、MAC、厂商。这个 CSV 可以直接拿去和之前盘点过的资产表做比对找出新增设备也可以之后丢给自动化脚本实现每轮扫描自动归档。5. 实战避坑网卡选错、AP 隔离和 ARP 广播风暴的翻车记录5.1 现象扫了半天只有网关和本机其他主机全丢第一次在办公楼里跑 Netdiscover我盯着终端看了两分钟列表里只有网关和自己这台机器网络里明明有几十台设备在正常办公。试了加大轮次、调长超时时间结果没变化。换了随身带的笔记本去同一个工位结果立刻变全了。原因办公网多数交换机都没有做端口隔离但无线网络基本都会开 AP 隔离客户端隔离。连 Wi-Fi 的设备只能和网关通信设备之间互相不可见我的笔记本连的是访客 Wi-Fi整个扫描请求只有网关回应其他终端压根收不到所以只有网关的 MAC 会出现。这是交换机和无线控制器层面的设计和 Netdiscover 本身无关。解决扫描二层网络前先确认自己连在哪一层。用有线网线接入办公网核心交换机再扫闭开无线。如果条件不允许插网线至少要先确认当前 Wi-Fi 的 AP 隔离是否开启。另外把笔记本的以太网口接到语音 VLAN、监控 VLAN 这类隔离网段时也会出现同样的现象先ip addr确认自己拿到的 IP 段和要扫描的网段一致。5.2 现象MAC 厂商识别一抓一大把 Unknown扫描出来的设备 IP 和 MAC 都对但第三列厂商信息大面积是 Unknown只有少数几台能认出 Apple、Cisco 之类整张表可用性大打折扣。原因Netdiscover 内置的 OUI 厂商表是打包时固定的造包时间越久落后于新设备的可能越大。尤其近几年联网的智能家居、IoT 设备、新出的手机网卡厂商会申请新的 OUI 段旧表里查不到。这不是扫描器坏了而是数据库版本旧了。解决到 IEEE 官网下载最新的 OUI 数据转换成 Netdiscover 能读的格式后用-m参数指定。# 下载 IEEE 最新的 OUI 记录剥离表头后作为自定义厂商表 wget https://standards-ieee.org/develop/regauth/oui/oui.csv cut -d , -f 2,3 oui.csv | tr -d /usr/local/share/netdiscover/oui.txt sudo netdiscover -i eth0 -r 192.168.1.0/24 -m /usr/local/share/netdiscover/oui.txtcut提取的是注册机构和厂商名的两列tr把 CSV 里的引号清掉让文件格式和 Netdiscover 期望的厂商表格式对齐。定期更新一次一般半年到一年做一次就够电气和电子工程师协会的 OUI 分配频率没有快到需要天天同步。5.3 现象同一个 MAC 在结果里反复跳动IP 忽变做资产盘点时发现扫描结果里同一台打印机一会是 192.168.1.101一会是 192.168.1.108中间还隔着几分钟的间隔搞得资产表没法对。又或者同一个 IP 对应了两个不同的 MAC来回交替出现。原因DHCP 租约到期后设备重新获取地址IP 变了 MAC 没变或者网络里存在两台设备配置了相同的静态 IPWindows 有 IP 冲突检测机制但打印机这类嵌入式设备不会主动避让一台上线把另一台挤掉线。后一种情况的本质是网络里有人工配错不是扫描器的问题。解决别拿一轮快照当唯一结论。用-c固定扫三轮以上对比结果中 MAC 与 IP 的对应关系是否稳定。反复横跳的 IP 要人工介入结合交换机端口信息找到对应物理位置。如果你在结果里看到同一 MAC 出现在多个 IP 下惆怅之余也要知道这往往意味着 DHCP 续租或移动设备漫游无关紧要但同一 IP 在多个 MAC 间来回换基本可以断定是 IP 冲突。5.4 现象主动扫描刚开几秒安全设备报警来了有一次在客户生产网里做资产梳理Netdiscover 刚跑起来没到五秒客户的安全团队就打电话来问是不是有终端在发起异常扫描。全网的网络监控设备把那段 ARP 广播风暴如实记录了下来并触发了告警规则。原因一个 /24 网段的主动扫描一轮就是 254 条 ARP 请求广播哪怕交换机转发再快这也在安全设备眼里是典型的扫描行为特征。Netdiscover 没有做任何速率伪装默认情况下就是高速连续发包网络上任何 IDS、终端安全软件都能识别。这是工具本身的特性不是配置问题。解决先获得授权明确这个动作是否被允许再限速扫描。把-s调大让每个请求之间的间隔拉长扫描行为会从「风暴」变成「涓流」触发告警的概率显著下降。在特别敏感的网络里干脆用被动模式替代主动扫描完全不产生探测流量只会把别人原本就在发送的 ARP 报文记录下来。被动模式的结果可能不如主动模式完整但在不被打扰和拿全数据之间多数时候应该选前者。维护窗口里做主动扫描平时用被动模式长期监听这是我在生产网里的固定做法后面给客户写方案也是这么建议。5.5 现象虚拟机里扫不到物理网段的主机在一台 VMware 虚拟机里跑 Netdiscover扫描结果只有宿主机和同一个虚拟交换机上的其他虚拟机完全看不到物理局域网里的真实设备。同一台机器上的同一块网卡切到物理机系统里跑就一切正常。原因虚拟机默认的 NAT 网络模式下虚拟机在一套独立的私有网段里物理局域网对它不可见。即使改成桥接模式VMware 默认也不会把虚拟网卡收到的所有流量都转发给虚拟机需要在虚拟机设置的「网卡」里勾选「混杂模式」。Netdiscover 的 ARP 请求进入虚拟交换机后被过滤自然什么都扫不到。解决把虚拟机的网络连接改成桥接模式然后在虚拟化平台里允许该虚拟网卡使用混杂模式或者干脆把 Netdiscover 放到一台物理机或物理服务器上跑。虚拟机方案在这个场景下天生劣势因为二层流量经过虚拟交换机会被软件转发逻辑过滤掉一截扫描结果永远不如物理网卡直接抓包完整。我从那次之后就学乖了凡是涉及 ARP 工具的实操能上物理机就不上虚拟机。6. 进阶用法把 Netdiscover 变成无人值守的接入设备告警比单次扫描更有价值的是持续监听。把 Netdiscover 变成一个每隔几分钟跑一次、自动比对设备增量的小巡检比任何商业资产管理软件都直接。#!/bin/bash # device_watch.sh定期扫描、记录、对比新增设备 SCAN_LOG/var/log/netdiscover/devices_$(date %Y%m%d).log TMP_NEW/tmp/netdiscover_new.txt TMP_OLD/tmp/netdiscover_old.txt # 跑一轮短平快扫描结果存到当日文件 sudo netdiscover -i eth0 -r 192.168.1.0/24 -c 3 -P $SCAN_LOG # 提取 MAC 列按你环境的实际列号调整 awk {print $2} $SCAN_LOG | sort -u $TMP_NEW # 如果存在历史快照diff 出新增的 MAC if [ -f $TMP_OLD ]; then comm -13 $TMP_OLD $TMP_NEW | while read mac; do echo [$(date)] 发现新接入设备: $mac /var/log/netdiscover/new_devices.log done fi # 更新历史快照等下一轮比较 cp $TMP_NEW $TMP_OLD这套脚本的核心思想是用comm拿新旧两份 MAC 列表做差集新增项就是新接入设备的证据。把它放进 crontab 里每五分钟执行一次运维人员每天只需要看一份new_devices.log不需要自己盯着终端刷屏。注意awk提取列号时以实际输出为准我的环境里 MAC 在第二列你的版本如果列序不同就调整数字。验证 Netdiscover 有没有漏报可以拿系统自带的 ARP 缓存做交叉检查。主动扫描结束后执行arp -a内核会保留最近一段时间学习到的所有 ARP 映射把这份列表和 Netdiscover 的输出放在一起比对如果系统缓存里有但扫描结果里没有就要检查网卡选型或权限配置。更严谨一点在目标设备上用 tcpdump 抓一段时间的 ARP 流量确认请求确实到达了目标网段过滤条件就是arp协议关键字。再到设备分类这一步把 MAC 厂商字段和业务角色对应起来就能直接产出资产盘点文档。把扫描出的厂商名交给一段 case 判断Dell 标 PC、Cisco 标网络设备、Brother 标打印机输出成带分类的清单。这种分类不保证百分百准确但它能让你在接到「查一台未知设备」这种需求时先有一个大致范围再去交换机上对端口会比直接登录核心交换机一个个翻 MAC 地址表快很多。我现在到任何一个新维护的网络都会先被动听半分钟再决定要不要主动扫然后把巡检脚本装上让它自己跑。这个习惯帮我少翻了不少车希望帮到你。本文还有配套的精品资源点击获取 Netdiscover实战：用ARP扫描快速摸清局域网设备
简介Netdiscover是一款开源的ARP网络扫描工具主要面向网络管理员与安全测试人员用于在无线网络或缺乏DHCP的环境中快速发现活跃设备、获取IP与MAC地址并推测网络拓扑。这份源码包为netdiscover-0.3-pre-beta7共包含39个文件以C语言源代码与头文件为主辅以configure、Makefile等自动构建脚本及规格说明文档整体仅359KB适合希望研究其实现原理或自行编译定制的中高级用户。目前已有262人学习下载。通过阅读源码可掌握ARP请求-响应机制在真实工具中的落地写法理解无线网络探测的常见思路同时可借助其识别隐藏无线网络的能力配合nmap、ettercap等工具开展更全面的网络评估与安全审计。压缩包内附有README、ChangeLog、TODO等文档便于快速上手和追踪开发历史是一份兼具学习价值与实战价值的开源软件资料。1. 为什么有了Nmap我还会在工具箱里留一个 Netdiscover给客户做网络资产盘点的时候我吃过一次亏拿 Nmap 去扫一个 50 台设备的办公网-sn探活结果只有 30 台。排查到最后发现一部分打印机和 IP 电话对 ICMP 和 TCP 探测直接装死但它们在网络上明明活得好好的。后来换上 Netdiscover 这个开源 ARP Scanner同一网段几乎没有漏网。原因不玄学三层探测可以被设备策略忽略而二层 ARP 是任何 IP 协议栈都无法拒绝的应答机制。Netdiscover 解决的问题很具体快速摸清一个局域网里有谁在线、它们的 MAC 地址属于哪个厂商以及哪些 IP 正在被占用。它适合网络运维做资产梳理、安全审计做接入发现、以及排查 IP 冲突这类日常破事。接下来我把原理、安装、参数和坑一次讲完照着跑就能用。2. ARP 扫描原理二层发现为什么比三层探测稳2.1 一条 ARP 请求怎么把整个网段变成可见的ARP 的完整流程是主机 A 要向主机 B 发数据但只知道 B 的 IP不知道 B 的 MAC。于是 A 在本地广播域里发一条「谁的 IP 是 192.168.1.20请把你的 MAC 告诉我」的请求目标主机 B 收到后回一条单播「我的 IP 是 192.168.1.20我的 MAC 是 xx:xx:xx:xx:xx:xx」。A 把这条映射写进自己的 ARP 缓存表后续通信直接按缓存发不再广播。Netdiscover 的主动模式就是把这个过程放大向网段里每一个可能的 IP 都发一次 ARP 请求谁回应就把谁记下来。关键点在于这个请求是二层的不经过路由器也不依赖目标主机开放任何 TCP/UDP 端口。哪怕目标机器的防火墙把 ICMP、TCP 探针全丢了它也无法拦掉自己网卡协议栈对 ARP 请求的自动应答。这就是 Netdiscover 在局域网发现场景里比三层扫描稳的核心原因。实际抓包看更直观。在网段里跑一次主动扫描用 Wireshark 或者 tcpdump 在另一台机器上监听会看到连续不断的 ARP 请求sudo tcpdump -i eth0 -n arp输出里每一个who-has请求都对应 Netdiscover 发出的探测每一个reply就是一台存活主机的自曝。扫描器本身不需要装任何客户端目标机器也不需要装任何软件这是这类二层发现工具最大的价值。2.2 主动模式与被动模式一个撒网一个蹲点Netdiscover 有两种工作模式适合完全不同的场景。主动模式是默认行为指定一个 IP 范围然后向该范围内每个地址发 ARP 请求。它的优点是快一个 /24 网段几秒内就能出结果缺点是会产生明显的广播流量。在一个 254 个地址的网段里每一轮扫描就会产生 254 条 ARP 请求如果边上还挂着网络监控设备这些请求会被如实记录下来这是后续被安全团队找上门的主要原因。被动模式是加-p参数此时 Netdiscover 不再发包而是把网卡设为混杂模式静静监听网络里已有的 ARP 请求和应答。办公楼里任何一台设备开机、访问网关、找打印机都会发出 ARP 流量Netdiscover 把这些对话全部记录下来照样能还原出活跃主机清单。它的优点是零打扰适合在敏感网络、生产网段里做摸底缺点是需要等网络里没人说话它就什么都没收获。刚到一个陌生网络我的习惯是先被动听半分钟看有多少设备在自主通信再决定要不要主动扫一轮。被动模式的结果往往比主动模式更接近真实使用状态因为那本来就是业务流量的一部分。2.3 Netdiscover 和 Nmap 的定位差异什么时候用谁Nmap 也可以发 ARP 扫描nmap -sn -PR 192.168.1.0/24就是纯 ARP 探测。那为什么还要单独装 Netdiscover两者的设计目标是完全相反的。对比项NetdiscoverNmap -sn -PR扫描机制固定发 ARP 请求聚焦 MAC 层ARP 为主必要时混合 ICMP/TCP 探活界面形态实时刷新的终端表看到设备一台台出现等全部跑完输出列表厂商识别内置 OUI 表直接标出设备厂商默认不做厂商标注被动模式支持-p参数即可不支持靠其他工具配合长时间监听可以持续跑适合盯接入变化一轮跑完就结束不适合驻留可脚本化输出格式简单配合 awk 方便需要-oG等额外参数才能解析Netdiscover 更像一个持续工作的网段监听器而不是一次性扫描器。Nmap 的价值在于端口、服务和漏洞探测那是 Netdiscover 完全不具备的能力。我的分工方式先用 Netdiscover 搞清楚「网段里有哪些设备」再对感兴趣的 IP 用 Nmap 做「这些设备开了什么端口、跑了什么服务」。Netdiscover 当前站Nmap 接棒干细活。2.4 选型理由为什么二层发现比三层探测稳三层探测常用的手段是发 ICMP Echo 请求或者对常见端口发 TCP SYN 包。这两种方式都会遇到同一个问题目标设备不一定理会。打印机节能状态下可能不响应 pingWindows 防火墙默认拦截 ICMP某些工控设备对陌生连接直接无视。但这些设备的 IP 协议栈为了能正常通信必须随时响应 ARP。这不是应用层行为而是网卡驱动和内核协议栈的固有问题关不掉。选了 Netdiscover 还有一个实际收益它能识别网卡厂商。通过 MAC 地址前三位OUI对照 IEEE 分配的厂商表Netdiscover 会标出谁家的设备、大概率是路由器还是网卡。在一个混乱的办公网里看到一长串Apple、Dell、Cisco比面对一串十六进制 MAC 地址直观太多。这也是很多运维愿意留它的原因——不只是扫 IP而是在给整张网做画像。3. 安装与依赖三种装法从 apt 到源码编译的完整路径3.1 Debian/Ubuntuapt 装上之后先跑一次自检在 Debian 系发行版上装 Netdiscover 是最省事的一条路软件源里直接有编译好的二进制包。装完先别急着扫描先确认厂商库文件有没有正确安装否则后面扫出一堆 Unknown 你会以为网络出问题了。sudo apt update sudo apt install -y netdiscover netdiscover -h安装过程本身没有什么需要解释的netdiscover -h用来确认命令已经被放进 PATH 里。需要注意的一点是不同版本的 Debian/Ubuntu 对 Netdiscover 的打包情况不太一样某些 LTS 版本源里的版本可能偏老功能上没有区别但输出格式可能有微小差异。如果你在脚本里解析 Netdiscover 的输出建议以实际环境的输出为准不要拿网上别人的解析脚本直接套。自检厂商库的常见做法是执行netdiscover -L该命令会列出内置的 MAC 厂商映射表并退出。如果命令报错或者列出的是空表说明 OUI 数据文件在安装时没有正确落位后面所有扫描结果都会变成一堆 Unknown MAC 地址毫无可用性。3.2 从源码编译安装解决依赖问题的完整路径如果你的发行版软件源里没有 Netdiscover或者你需要一个较新版本自带的功能就得走源码编译。Netdiscover 的构建依赖主要有 libpcap 和 libnet前者负责抓包后者负责构造和发送 ARP 报文。两个库缺一个编译到一半就会报头文件找不到的错误。# 安装编译工具链和依赖开发包 sudo apt install -y build-essential autoconf automake libpcap-dev libnet-dev # 从 GitHub 找到 netdiscover 的开源仓库并克隆到本地 git clone https://github.com/你的仓库/netdiscover.git cd netdiscover # 源码包如果没有直接带 configure 脚本先自动生成 autoreconf -i ./configure make sudo make install这里的逻辑顺序不能乱。libpcap-dev和libnet-dev提供的是编译时需要的头文件如果先执行./configure再装依赖配置脚本会检测不到库函数导致生成错误的 Makefile。autoreconf -i是从 Git 仓库拉下来的源码常见步骤它根据 configure.ac 和 Makefile.am 生成 configure 脚本从官方 release 包解压的源码通常已经带好了 configure可以直接跳过这步。编译完成后netdiscover默认安装到/usr/local/bin/。如果你的 PATH 里没有这个目录跑命令时会提示 command not found但明明编译成功了。这种情况直接用全路径执行/usr/local/bin/netdiscover -h或者执行sudo ldconfig刷新动态链接库缓存后再试。真遇到这个问题说明系统在编译时找到了库但运行时没找到多半是 libnet 的 .so 文件装到了非默认路径。3.3 Fedora/RHEL 系EPEL 源没有就打两手准备RHEL 系的软件源默认不带 Netdiscover常见的做法是先启用 EPEL 仓库再尝试安装。EPEL 里有没有这个包取决于仓库的维护状态不同版本差异很大所以装之前先搜索确认。# 启用 EPEL 仓库后搜索是否存在该包 sudo dnf install -y epel-release sudo dnf search netdiscover # 如果搜索有结果直接安装没结果就回到源码编译路径 sudo dnf install -y netdiscoverdnf search这一步很多人会跳过结果装了半天提示 Nothing to do。先搜再装能省掉这个无用功。另外RHEL 系源码编译时依赖包名跟 Debian 系不一样对应关系大致是libpcap-devel和libnet-devel而不是-dev后缀。编译前把这俩装上后面./configure才不会被卡住。至于 libnet 本身某些 RHEL 版本没有现成的 RPM 包需要从源码单独编译那就要先去解决 libnet 的构建依赖再回来编译 Netdiscover。3.4 root 权限和混杂模式提前把运行环境弄好Netdiscover 的两类操作都对权限有硬性要求。发 ARP 请求需要直接操作 raw socket抓包需要把网卡切到混杂模式这两件事普通用户都做不了。所以在使用文档里你看到的所有扫描命令几乎都带着sudo这是设计如此不是装样子。被动模式对网卡有一个额外要求混杂模式需要手动开启或者依赖工具自己调用。如果网卡没有正确进入混杂模式被动模式只能收到发往本机的包ARP 广播请求能收到一部分但应答和别人的单播就会漏掉结果严重偏少。手动开启的方式是sudo ip link set dev eth0 promisc on扫描结束后可以把混杂模式关掉避免网卡持续接收无关流量增加负载。执行完netdiscover -p后用ip link show eth0查看网卡状态确认没有停留在 promisc 模式。这一步虽然不影响扫描结果但在干净的生产网里开着混杂模式本身就会触发安全告警扫描完随手关掉是个习惯问题。4. 主动扫描实操用一条命令跑通整个网段的主机发现4.1 最小成型命令扫描一个网段需要哪些参数Netdiscover 最核心的用法是主动模式加一个目标网段以下命令扫当前网卡所在的所有 IPsudo netdiscover -i eth0 -r 192.168.1.0/24-i指定用哪块物理网卡发包-r指定扫描范围。这两个参数建议每次扫描都显式写出来。不写-i时工具会自动选一块接口在有多块网卡的机器上自动选择的结果常常不是你想要的不写-r时扫描范围为空命令不会执行。命令跑起来后终端会进入一个实时刷新的表格界面每一行是一台设备从左到右依次是 IP 地址、MAC 地址、厂商名、响应计数。你会看到设备一行一行往上添而不是等全部扫完才一次性输出。这是 Netdiscover 和 Nmap 交互方式上最大的区别对排查问题很有帮助哪台设备没有回应你能当场看到它是没响应还是还在等。如果要扫描多个互不连续的网段把多个范围一次性传给-r参数中间用逗号分隔即可。例如-r 192.168.1.0/24,10.10.0.0/24会按顺序扫两个网段。这个写法比分两次跑省事也便于把结果统一落进一份日志里。4.2 必调参数表轮次、延迟、输出格式一次说清主动扫描不是跑一轮就结束默认情况下 Netdiscover 会持续发送 ARP 请求并不断刷新设备表除非手动 CtrlC 终止。实际使用中通常不想让它无限跑需要限制轮次和节奏。直接扫整个网段之前先看这几个参数参数作用典型值-c指定扫描轮数跑完自动退出-c 3-t等待 ARP 响应的时间影响一轮扫描耗时-t 100-s每条 ARP 请求之间的间隔控制发包速率-s 10-P扫描结束后打印结果并退出与-c搭配使用-r指定扫描的 IP 范围192.168.1.0/24-l从文件读取 IP 范围列表适合批量场景-l ip_list.txt-p进入被动监听模式不发包单独使用-m指定自定义 MAC 厂商表文件-m /path/to/oui.txt一个比较稳妥的组合是sudo netdiscover -i eth0 -r 192.168.1.0/24 -c 3 -t 100 -P-c 3让扫描只跑三轮-t 100把每轮等待时间控制在 100 毫秒左右-P在扫描结束时打印汇总结果。这个组合的优点是行为可预期无论网段里有多少设备命令都会在几秒内结束不会一直驻留刷屏适合在维护窗口里快速摸底。-s参数的典型应用场景是在办公网做长时间驻留扫描。把间隔调大发包速率降低对现有网络的冲击就小。默认的快速扫描在生产网里可能会引发交换机端口安全策略的告警把-s调到 100 毫秒以上扫描行为的可观测性就会下降很多不是完全不可见但不再是让人一眼警觉的扫描风暴。4.3 把实时扫描结果存成资产清单解析与格式化Netdiscover 实时界面的数据不便于直接做后续处理需要让它输出成纯文本再交给脚本处理。-P参数输出的汇总格式相对规整直接重定向到文件就能留档sudo netdiscover -i eth0 -r 192.168.1.0/24 -c 3 -P scan_result.log # 从日志中提取所有 IP 和 MAC按设备去重 awk {print $1, $2} scan_result.log | sort -uawk里的列号依赖实际输出的空格分隔格式不同版本可能有细微差别。第一次跑完建议先head看一下原始输出长什么样再调整列号。提取出来的 IP-MAC 对可以直接作为资产清单的原始素材。如果想要更结构化的数据把输出处理成 CSV 也方便后续导入表格工具体系sudo netdiscover -i eth0 -r 192.168.1.0/24 -c 3 -P | awk NR2 {gsub(/^ | $/, ); print $1 , $2 , $3} assets.csv这个命令的NR2是跳过表头gsub去掉行首行尾的多余空格避免 CSV 字段里夹着制表符。字段分别是 IP、MAC、厂商。这个 CSV 可以直接拿去和之前盘点过的资产表做比对找出新增设备也可以之后丢给自动化脚本实现每轮扫描自动归档。5. 实战避坑网卡选错、AP 隔离和 ARP 广播风暴的翻车记录5.1 现象扫了半天只有网关和本机其他主机全丢第一次在办公楼里跑 Netdiscover我盯着终端看了两分钟列表里只有网关和自己这台机器网络里明明有几十台设备在正常办公。试了加大轮次、调长超时时间结果没变化。换了随身带的笔记本去同一个工位结果立刻变全了。原因办公网多数交换机都没有做端口隔离但无线网络基本都会开 AP 隔离客户端隔离。连 Wi-Fi 的设备只能和网关通信设备之间互相不可见我的笔记本连的是访客 Wi-Fi整个扫描请求只有网关回应其他终端压根收不到所以只有网关的 MAC 会出现。这是交换机和无线控制器层面的设计和 Netdiscover 本身无关。解决扫描二层网络前先确认自己连在哪一层。用有线网线接入办公网核心交换机再扫闭开无线。如果条件不允许插网线至少要先确认当前 Wi-Fi 的 AP 隔离是否开启。另外把笔记本的以太网口接到语音 VLAN、监控 VLAN 这类隔离网段时也会出现同样的现象先ip addr确认自己拿到的 IP 段和要扫描的网段一致。5.2 现象MAC 厂商识别一抓一大把 Unknown扫描出来的设备 IP 和 MAC 都对但第三列厂商信息大面积是 Unknown只有少数几台能认出 Apple、Cisco 之类整张表可用性大打折扣。原因Netdiscover 内置的 OUI 厂商表是打包时固定的造包时间越久落后于新设备的可能越大。尤其近几年联网的智能家居、IoT 设备、新出的手机网卡厂商会申请新的 OUI 段旧表里查不到。这不是扫描器坏了而是数据库版本旧了。解决到 IEEE 官网下载最新的 OUI 数据转换成 Netdiscover 能读的格式后用-m参数指定。# 下载 IEEE 最新的 OUI 记录剥离表头后作为自定义厂商表 wget https://standards-ieee.org/develop/regauth/oui/oui.csv cut -d , -f 2,3 oui.csv | tr -d /usr/local/share/netdiscover/oui.txt sudo netdiscover -i eth0 -r 192.168.1.0/24 -m /usr/local/share/netdiscover/oui.txtcut提取的是注册机构和厂商名的两列tr把 CSV 里的引号清掉让文件格式和 Netdiscover 期望的厂商表格式对齐。定期更新一次一般半年到一年做一次就够电气和电子工程师协会的 OUI 分配频率没有快到需要天天同步。5.3 现象同一个 MAC 在结果里反复跳动IP 忽变做资产盘点时发现扫描结果里同一台打印机一会是 192.168.1.101一会是 192.168.1.108中间还隔着几分钟的间隔搞得资产表没法对。又或者同一个 IP 对应了两个不同的 MAC来回交替出现。原因DHCP 租约到期后设备重新获取地址IP 变了 MAC 没变或者网络里存在两台设备配置了相同的静态 IPWindows 有 IP 冲突检测机制但打印机这类嵌入式设备不会主动避让一台上线把另一台挤掉线。后一种情况的本质是网络里有人工配错不是扫描器的问题。解决别拿一轮快照当唯一结论。用-c固定扫三轮以上对比结果中 MAC 与 IP 的对应关系是否稳定。反复横跳的 IP 要人工介入结合交换机端口信息找到对应物理位置。如果你在结果里看到同一 MAC 出现在多个 IP 下惆怅之余也要知道这往往意味着 DHCP 续租或移动设备漫游无关紧要但同一 IP 在多个 MAC 间来回换基本可以断定是 IP 冲突。5.4 现象主动扫描刚开几秒安全设备报警来了有一次在客户生产网里做资产梳理Netdiscover 刚跑起来没到五秒客户的安全团队就打电话来问是不是有终端在发起异常扫描。全网的网络监控设备把那段 ARP 广播风暴如实记录了下来并触发了告警规则。原因一个 /24 网段的主动扫描一轮就是 254 条 ARP 请求广播哪怕交换机转发再快这也在安全设备眼里是典型的扫描行为特征。Netdiscover 没有做任何速率伪装默认情况下就是高速连续发包网络上任何 IDS、终端安全软件都能识别。这是工具本身的特性不是配置问题。解决先获得授权明确这个动作是否被允许再限速扫描。把-s调大让每个请求之间的间隔拉长扫描行为会从「风暴」变成「涓流」触发告警的概率显著下降。在特别敏感的网络里干脆用被动模式替代主动扫描完全不产生探测流量只会把别人原本就在发送的 ARP 报文记录下来。被动模式的结果可能不如主动模式完整但在不被打扰和拿全数据之间多数时候应该选前者。维护窗口里做主动扫描平时用被动模式长期监听这是我在生产网里的固定做法后面给客户写方案也是这么建议。5.5 现象虚拟机里扫不到物理网段的主机在一台 VMware 虚拟机里跑 Netdiscover扫描结果只有宿主机和同一个虚拟交换机上的其他虚拟机完全看不到物理局域网里的真实设备。同一台机器上的同一块网卡切到物理机系统里跑就一切正常。原因虚拟机默认的 NAT 网络模式下虚拟机在一套独立的私有网段里物理局域网对它不可见。即使改成桥接模式VMware 默认也不会把虚拟网卡收到的所有流量都转发给虚拟机需要在虚拟机设置的「网卡」里勾选「混杂模式」。Netdiscover 的 ARP 请求进入虚拟交换机后被过滤自然什么都扫不到。解决把虚拟机的网络连接改成桥接模式然后在虚拟化平台里允许该虚拟网卡使用混杂模式或者干脆把 Netdiscover 放到一台物理机或物理服务器上跑。虚拟机方案在这个场景下天生劣势因为二层流量经过虚拟交换机会被软件转发逻辑过滤掉一截扫描结果永远不如物理网卡直接抓包完整。我从那次之后就学乖了凡是涉及 ARP 工具的实操能上物理机就不上虚拟机。6. 进阶用法把 Netdiscover 变成无人值守的接入设备告警比单次扫描更有价值的是持续监听。把 Netdiscover 变成一个每隔几分钟跑一次、自动比对设备增量的小巡检比任何商业资产管理软件都直接。#!/bin/bash # device_watch.sh定期扫描、记录、对比新增设备 SCAN_LOG/var/log/netdiscover/devices_$(date %Y%m%d).log TMP_NEW/tmp/netdiscover_new.txt TMP_OLD/tmp/netdiscover_old.txt # 跑一轮短平快扫描结果存到当日文件 sudo netdiscover -i eth0 -r 192.168.1.0/24 -c 3 -P $SCAN_LOG # 提取 MAC 列按你环境的实际列号调整 awk {print $2} $SCAN_LOG | sort -u $TMP_NEW # 如果存在历史快照diff 出新增的 MAC if [ -f $TMP_OLD ]; then comm -13 $TMP_OLD $TMP_NEW | while read mac; do echo [$(date)] 发现新接入设备: $mac /var/log/netdiscover/new_devices.log done fi # 更新历史快照等下一轮比较 cp $TMP_NEW $TMP_OLD这套脚本的核心思想是用comm拿新旧两份 MAC 列表做差集新增项就是新接入设备的证据。把它放进 crontab 里每五分钟执行一次运维人员每天只需要看一份new_devices.log不需要自己盯着终端刷屏。注意awk提取列号时以实际输出为准我的环境里 MAC 在第二列你的版本如果列序不同就调整数字。验证 Netdiscover 有没有漏报可以拿系统自带的 ARP 缓存做交叉检查。主动扫描结束后执行arp -a内核会保留最近一段时间学习到的所有 ARP 映射把这份列表和 Netdiscover 的输出放在一起比对如果系统缓存里有但扫描结果里没有就要检查网卡选型或权限配置。更严谨一点在目标设备上用 tcpdump 抓一段时间的 ARP 流量确认请求确实到达了目标网段过滤条件就是arp协议关键字。再到设备分类这一步把 MAC 厂商字段和业务角色对应起来就能直接产出资产盘点文档。把扫描出的厂商名交给一段 case 判断Dell 标 PC、Cisco 标网络设备、Brother 标打印机输出成带分类的清单。这种分类不保证百分百准确但它能让你在接到「查一台未知设备」这种需求时先有一个大致范围再去交换机上对端口会比直接登录核心交换机一个个翻 MAC 地址表快很多。我现在到任何一个新维护的网络都会先被动听半分钟再决定要不要主动扫然后把巡检脚本装上让它自己跑。这个习惯帮我少翻了不少车希望帮到你。本文还有配套的精品资源点击获取