企业官网建设流程全解析

简介：arp-scan-1.9 是一款面向 Linux 平台网络运维与安全测试人员的 IP 冲突检测工具源码包，主要用于扫描局域网内 IP 地址与 MAC 地址的对应关系，快速定位地址冲突、排查非法接入设备，适合具备一定 Linux 命令行基础、需要做网络诊断与资产梳理的工程师使用。压缩包共 57 个文件，约 360KB，以 C 源码与头文件为主体，配合 pcap 抓包样本、dat 测试数据、txt 厂商与 OUI 列表及 README、ChangeLog 等说明文档，覆盖从链路层抓包到厂商指纹识别的完整实现。资源附带 autoreconf、configure、make 等标准构建流程，便于在本地编译安装并直接投入实际网络环境验证。目前已有 1406 人学习下载，读者可借此理解 ARP 扫描原理、掌握冲突 IP 的排查思路，并基于源码二次开发或集成到自有运维脚本中。

1. arp-scan 1.9 拆包：局域网 IP 冲突排查的底层工具

机房搬迁那天，两台设备配了同一个静态 IP，交换机日志只报 MAC 漂移，不告诉你谁跟谁撞了。ping时通时断，ipconfig看不出所以然，这种玄学故障最后是靠arp-scan定位的。它做的事很朴素：在数据链路层发 ARP 请求，把整个网段里谁在线、IP 对应哪个 MAC、厂商是谁，一次性列出来。1.9 这个版本是很多发行版仓库里的长期稳定版，源码包arp-scan-1.9.tar.gz解压后就是一套 autotools 工程，编译出来只有一个主程序和几个辅助脚本。它适合谁？做网络运维、弱电施工、服务器上架、内网资产盘点的人。不适合谁？想扫公网、想绕过交换机隔离的人——ARP 是二层协议，跨不了路由，这是它的边界，也是它精准的原因。下面从编译到实战，把这份源码包拆开讲透。

2. 编译与依赖：从 tar.gz 到可执行文件

2.1 为什么选源码编译而不是直接 apt

多数发行版仓库里确实有arp-scan，但版本往往停在 1.9 或更早，而且仓库包默认不带getopt之外的一些可选特性。拿到arp-scan-1.9.tar.gz自己编译，好处有三个：一是能确认libpcap的链接版本，排查「扫不到包」时心里有底；二是可以改Makefile里的默认网卡和重试次数；三是内网离线机器上，源码包比在线仓库更可控。常见做法是先在能联网的机器上把依赖装好，再把编译产物拷进隔离环境。

依赖清单不复杂，核心就一个libpcap，外加make、gcc、autoconf这套构建工具。Debian/Ubuntu 系和 RHEL 系的包名不一样，下面分开写。

# Debian / Ubuntu 系 sudo apt-get update sudo apt-get install -y build-essential libpcap-dev # RHEL / CentOS / Rocky 系 sudo yum install -y gcc make libpcap-devel # 新版用 dnf sudo dnf install -y gcc make libpcap-devel

build-essential里含gcc、make、libc头文件；libpcap-dev提供pcap.h和链接库。少了libpcap-dev，configure阶段会直接报cannot find pcap，这是最常见的翻车点。RHEL 系注意libpcap-devel而不是libpcap，后者只有运行库没有头文件。

2.2 解压、configure、make 三步走

源码包的标准流程，但每一步都有可调参数。

# 1. 解压 tar -zxvf arp-scan-1.9.tar.gz cd arp-scan-1.9 # 2. 配置，指定安装前缀，避免污染系统目录 ./configure --prefix=/usr/local/arp-scan # 3. 编译并安装 make sudo make install

--prefix把程序装到/usr/local/arp-scan，二进制在bin/下，MAC 厂商库在share/arp-scan/下。这样卸载时直接删目录，不留残渣。configure脚本会自动探测libpcap路径，如果报错找不到，用--with-libpcap=/usr/local显式指定。make阶段如果出现undefined reference to pcap_open_live，说明链接时没找到库，检查libpcap-dev是否真的装上了。

编译完成后验证一下：

/usr/local/arp-scan/bin/arp-scan --version # 正常输出类似：arp-scan 1.9

--version能打印版本号，说明二进制可执行、动态库链接正常。如果报error while loading shared libraries: libpcap.so.1，用ldd看一下依赖，多半是libpcap运行库缺失或路径不对。

2.3 厂商库文件的位置与作用

arp-scan能把 MAC 解析成厂商名，靠的是ieee-oui.txt这个 OUI 库。安装后它在share/arp-scan/下。如果扫描结果里厂商列全是Unknown，八成是这个文件没找到。用--ouifile显式指定路径即可：

arp-scan --ouifile=/usr/local/arp-scan/share/arp-scan/ieee-oui.txt --localnet

这个库是静态的，新厂商加入后需要更新文件。1.9 自带的库有年头了，扫到新设备显示Unknown很正常，不影响 IP 和 MAC 的对应关系判断。排查 IP 冲突时，厂商名只是辅助，MAC 才是关键。

3. 实战扫描：定位 IP 冲突与资产盘点

3.1 基本扫描命令与输出解读

最常用的就是扫本地网段。--localnet让工具自动读取网卡配置，算出网段和掩码，不用手写 CIDR。

# 扫描本地网段，-I 指定网卡 sudo arp-scan -I eth0 --localnet # 输出示例 # 192.168.1.1 00:11:22:33:44:55 TP-LINK TECHNOLOGIES CO.,LTD. # 192.168.1.100 aa:bb:cc:dd:ee:ff Intel Corporate # 192.168.1.100 11:22:33:44:55:66 Unknown

注意第三、四行：同一个 IP192.168.1.100出现了两个不同 MAC。这就是 IP 冲突的铁证。ARP 协议本身没有冲突检测机制，谁后应答谁覆盖，所以arp-scan连续发多个请求时，两个设备都会回，结果里就出现重复 IP。看到重复 IP，直接拿两个 MAC 去交换机上查端口，定位物理位置。

-I指定网卡是必须的，多网卡机器上不指定会走默认路由网卡，扫错网段。--localnet等价于--interface=eth0加自动网段计算，但显式写-I更稳。

3.2 用 --retry 和 --timeout 提高冲突检出率

默认只发一次请求，冲突设备如果刚好没回，就漏了。排查冲突时把重试次数拉高。

# 重试 5 次，每次超时 500ms，间隔 100ms sudo arp-scan -I eth0 --localnet --retry=5 --timeout=500 --interval=100

--retry=5表示每个 IP 发 5 个 ARP 请求；--timeout=500是单次等待回复的毫秒数；--interval=100是请求之间的间隔毫秒。这三个参数配合，能把偶发应答的设备也逼出来。代价是扫描变慢，一个 /24 网段大概多花十几秒。我一般排查冲突时用--retry=3，日常盘点用默认值。

参数怎么改有讲究：网段里设备多、交换机负载高，--timeout要加大到 1000，否则正常设备也来不及回；网段干净、只想快速盘点，--retry=1就够。没有万能值，看现场。

3.3 指定网段与排除网关

不想扫全网段，或者要跳过网关和已知服务器，用 CIDR 加排除。

# 只扫 192.168.1.0/24，排除网关 .1 和服务器 .10 sudo arp-scan -I eth0 192.168.1.0/24 --exclude=192.168.1.1,192.168.1.10

--exclude接受逗号分隔的 IP 或 CIDR。排除网关的意义在于：网关 MAC 你早就知道，混在结果里干扰判断。资产盘点时，把已知的打印机、AP、服务器排除，剩下的就是「意外在线」的设备，往往能揪出私接的路由器或未登记的终端。

网段写法支持192.168.1.0/24和192.168.1.1-192.168.1.254两种。前者更常用，后者适合非连续地址段。注意arp-scan不做路由，指定网段必须是本机网卡直连的，跨网段扫不到，这是二层工具的硬边界。

3.4 把结果导出成表格做资产台账

扫描结果直接重定向就能存文件，配合awk整理成 CSV。

sudo arp-scan -I eth0 --localnet --retry=3 \ | grep -E '^[0-9]' \ | awk '{print $1","$2","$3}' > arp_scan_$(date +%F).csv

grep -E '^[0-9]'过滤掉表头和空行，只留数据行；awk取前三列拼成IP,MAC,厂商的 CSV。文件名带日期，方便按天对比。资产盘点时，把连续几天的 CSV 做 diff，新出现的 MAC 就是新接入设备，消失的就是下线设备。这个土办法在中小网络里比专业网管软件还快。

提示：arp-scan需要 root 权限，因为要打开原始套接字。用sudo或setcap cap_net_raw+ep给二进制授权，后者能免 sudo，但要注意安全边界。

4. 避坑与排查：扫不到、扫不全、结果乱

4.1 现象：一条结果都没有，命令秒退

原因：网卡名写错，或者--localnet算出的网段和实际不符。多网卡机器上，eth0可能叫ens33、enp3s0。用ip addr确认网卡名和网段。

解决：先ip addr看网卡，再用-I指定正确网卡。如果--localnet算错，直接写 CIDR，比如arp-scan -I ens33 10.0.0.0/24。还有一种情况是虚拟机网卡处于 NAT 模式，二层被虚拟化层隔离，扫不到宿主机网段，换成桥接模式再试。

4.2 现象：只扫到自己，其他设备全不在

原因：交换机开启了端口隔离，或者本机在 VLAN 里，其他设备在别的 VLAN。ARP 是广播，跨不了 VLAN。

解决：确认本机 VLAN 和要扫的设备是否同段。同 VLAN 内还扫不到，检查交换机是否禁了广播或做了 ARP 抑制。这种环境下arp-scan无能为力，得换三层扫描工具，但那就不是二层冲突排查的范畴了。

4.3 现象：同一个 IP 反复出现，但 MAC 只有一个

原因：不是冲突，是--retry设太高，同一个设备回了多次，工具没去重。1.9 默认会去重，但某些参数组合下会重复打印。

解决：加--plain输出纯文本，或者用sort -u去重。判断冲突要看 MAC 是否不同，MAC 相同就是重复应答，不是冲突。

4.4 现象：厂商列全是 Unknown

原因：OUI 库路径不对，或者库太旧不认新厂商。

解决：用--ouifile指定路径。库太旧无解，只能更新ieee-oui.txt，但 1.9 的格式对更新文件有要求，直接下最新版可能不兼容。排查冲突时忽略厂商列，只看 IP 和 MAC。

4.5 现象：扫描导致网络短暂卡顿

原因：--retry和--interval设得太激进，大量 ARP 广播冲击交换机。

解决：生产网段扫描避开业务高峰，--interval不低于 50ms，--retry不超过 3。大网段分片扫，别一次扫 /16。血泪经验：有次在核心网段用--retry=10扫，交换机 CPU 直接飙到 80%，被运维追着问。

5. 进阶技巧：用 arp-scan 做冲突自动告警

排查冲突靠人眼看重复 IP 效率低，写个脚本定时扫、自动比对、发现冲突就告警，才是长久之计。下面这个 bash 脚本每 5 分钟扫一次，把结果和上一次比对，同一 IP 出现不同 MAC 就打印告警。

#!/bin/bash # arp_conflict_watch.sh - 定时检测 IP 冲突 IFACE="eth0" NET="192.168.1.0/24" TMP="/tmp/arp_scan_now.txt" PREV="/tmp/arp_scan_prev.txt" # 扫描并只保留 IP 和 MAC 两列 sudo arp-scan -I "$IFACE" "$NET" --retry=2 --timeout=500 \ | grep -E '^[0-9]' | awk '{print $1, $2}' | sort > "$TMP" # 找出同一 IP 对应多个 MAC 的情况 awk '{print $1}' "$TMP" | uniq -d | while read ip; do macs=$(grep "^$ip " "$TMP" | awk '{print $2}' | sort -u | tr '\n' ' ') echo "[冲突] $ip 对应多个 MAC: $macs" done # 与上一次结果比对，发现 MAC 变化的 IP if [ -f "$PREV" ]; then diff "$PREV" "$TMP" | grep '^[<>]' | while read line; do echo "[变化] $line" done fi cp "$TMP" "$PREV"

脚本逻辑分两层：第一层用uniq -d找出重复 IP，再列出它对应的所有 MAC，这是实时冲突检测；第二层用diff对比前后两次扫描，MAC 变化的 IP 说明设备换了或者被顶替，这是历史追踪。--retry=2和--timeout=500是折中值，兼顾检出率和速度。

把这个脚本丢进crontab，每 5 分钟跑一次，输出重定向到日志文件，再用logrotate切割。告警可以接邮件或 webhook，但那是另一个话题了。关键点是：arp-scan的输出格式稳定，awk和uniq就能处理，不需要上重型监控。

验证脚本是否有效，可以手动制造一次冲突：找两台机器临时配同一个 IP，跑脚本，看是否打印[冲突]。我习惯在每次改完网络配置后，先跑一遍这个脚本确认没有意外冲突，再收工。从那以后，机房再没出现过「时通时断」的玄学故障——因为冲突在发生后的 5 分钟内就被抓出来了。希望帮到你。

本文还有配套的精品资源，点击获取