更多云服务器知识,尽在hsotol.com
你有没有遇到过这样一个"灵异事件":
某天早上,公司网络突然卡得离谱,连 ping 网关都开始超时,一查监控却啥都没报警。你以为是出口带宽不够了,结果折腾半天才发现,内网有人在"搞事"------ARP 洪泛。
更离谱的是,这种局部广播风暴不容易被传统监控系统抓住。大多数系统工具压根不会把 ARP 当作"异常",而在某些私有云或混合部署环境中,它甚至成了最常见的"幽灵杀手"。
所以问题来了:我们能不能用最简单的方式,实时捕捉 ARP 异常,并立即推送告警?
当然可以,今天我们就用最通用、最实战的方式------Shell 脚本 + 飞书 / 邮件通知,打造一个轻量级的内网 ARP 洪泛监控方案。
为什么 ARP 洪泛这么隐蔽,却又这么致命?
先别急着上脚本,咱们先搞清楚这个现象到底怎么回事。
ARP 是什么?
ARP(Address Resolution Protocol)是局域网中的"问路协议":
- 主机 A 要访问某个 IP,比如 192.168.1.10;
- 它会先发送一个 ARP 请求:请问谁是 192.168.1.10?
- 拥有该 IP 的设备会响应,并告诉它自己的 MAC 地址;
- A 拿到 MAC 后才会发起实际的数据传输。
ARP 洪泛怎么发生的?
- 某台设备中病毒,或者被恶意脚本操控,不停发出 ARP 广播;
- 有时交换机出 bug,也可能出现无意义的 ARP 回环;
- 在虚拟化环境下(比如 KVM/ESXi 里),某些 bridge 桥接口配置错,也可能引起 ARP 风暴;
- 更多时候,是"误配置"导致的:一个 DHCP 客户端不断重复申请但无法绑定 IP,引发 ARP 广播循环。
这种 ARP 风暴有两个特点:
- 广播频率极高(比如每秒几十上百条);
- 系统不报警,因为它们没有形成明显的错误码或阻塞,Ping 也能通,但网络就是慢。
这就是为什么我们必须自己监控ARP 异常。
实现目标:三件事搞定
我们用最纯粹的方式完成以下 3 件事:
- 实时监听 ARP 包数量,判断是否异常;
- 根据设定的阈值触发告警(比如每秒超过 100 个 ARP 包);
- 通过飞书机器人 / 邮件将异常发送出去。
第一步:监听 ARP 包的数量变化
我们用 tcpdump
或 ip -s link
都可以拿到数据,但这里更精准一点,直接用:
bash
tcpdump -i eth0 arp
但是不能一直盯着屏幕看,所以我们得配合 Shell 脚本统计每秒捕获的 ARP 包数量。
示例代码:
bash
#!/bin/bash
# 配置参数
THRESHOLD=100 # 每秒ARP包超过这个数量就报警
INTERFACE="eth0"
LOG_FILE="/tmp/arp_monitor.log"
SLEEP_INTERVAL=1
while true; do
COUNT=$(timeout $SLEEP_INTERVAL tcpdump -n -i $INTERFACE arp 2>/dev/null | wc -l)
echo "$(date): ARP count = $COUNT" >> $LOG_FILE
if [ $COUNT -gt $THRESHOLD ]; then
echo "【ARP异常告警】当前ARP包数量:$COUNT,超过阈值:$THRESHOLD"
bash /opt/notify_feishu.sh "ARP洪泛预警:$COUNT 条/秒 @$(date '+%F %T')"
fi
done
这个脚本每秒捕捉一次当前网卡的 ARP 包数量,如果超过预设值,就调用告警脚本。
第二步:配置飞书告警脚本
飞书的 Webhook 告警非常简单,只需要一个 URL 和一段 JSON 格式的内容。
获取飞书机器人 Webhook:
- 进入飞书群;
- 添加机器人;
- 开启"自定义机器人",复制 Webhook 链接。
示例告警脚本 /opt/notify_feishu.sh
:
bash
#!/bin/bash
ALERT_MSG="$1"
WEBHOOK_URL="https://open.feishu.cn/open-apis/bot/v2/hook/xxxxxxx" # 替换为你的URL
curl -X POST -H "Content-Type: application/json" \
-d "{
\"msg_type\": \"text\",
\"content\": {
\"text\": \"$ALERT_MSG\"
}
}" $WEBHOOK_URL
赋予执行权限:
bash
chmod +x /opt/notify_feishu.sh
现在,每当 ARP 数量超限时,飞书就会收到告警:
css复制编辑ARP洪泛预警:183 条/秒 @2025-07-03 10:58:33
是不是比一堆没用的图表更直接?
第三步:配置邮件告警(可选)
如果你更喜欢 Email:
bash
apt install -y mailutils
echo "$ALERT_MSG" | mail -s "ARP 洪泛预警" your@email.com
可以在主脚本里用条件判断选择飞书或邮件,甚至两者都发。
🧪 验证:如何模拟一次 ARP 洪泛?
在测试环境里,你可以用以下命令"伪造" ARP 包:
bash
while true; do
arping -c 1 -I eth0 192.168.1.1
done
当然,别在正式环境运行,否则你可能会被"请去喝茶"。
🚨 告警防抖机制与日志轮转
每秒都发告警太频繁?加个简单防抖逻辑:
bash
LAST_ALERT_FILE="/tmp/last_alert_time"
NOW=$(date +%s)
LAST=$(cat $LAST_ALERT_FILE 2>/dev/null || echo 0)
if (( NOW - LAST > 60 )); then
bash /opt/notify_feishu.sh "ARP洪泛预警:$COUNT 条/秒"
echo $NOW > $LAST_ALERT_FILE
fi
另外,为了避免日志爆炸,定期轮转日志或写入 logrotate
规则是个好习惯。
📊 进阶玩法:可视化 + Grafana Dashboard?
虽然我们用 shell 脚本搞定了"告警",但如果你想搞点"图",可以结合:
- 将 arp 数量统计结果写入 Prometheus exporter 格式;
- 用 Node Exporter + Textfile Collector 抓取自定义 metric;
- Grafana 显示 ARP 包趋势图;
这样你就能实现------实时图 + 飞书告警 + 日志回溯,运维体验直线上升。
🧠 为什么要自己写脚本,而不用现成的监控平台?
你可能会问:不是有 Zabbix、Prometheus、Open-Falcon 吗?为什么还要自己写脚本?
很简单:
- 大多数平台不采集 ARP;
- ARP 包是局域网层广播,容易被网络设备"过滤";
- 大型监控系统部署周期长、适配难,而脚本 5 分钟就能上线;
- 一台轻量服务器 + 一段脚本,就能对全网ARP异常快速感知,这就是"平民武器"。
结尾提一句(不是套路)
运维不是"全靠工具",而是"灵活工具 + 主动意识"的结合。
ARP 洪泛这种问题看似小众,但一旦发生,对私有云和内网业务打击巨大。而通过这种"小成本高价值"的 Shell 实战,你就能轻松做到事前感知、实时响应、不打无准备之仗。
下次网络变慢的时候,不用再茫然四顾,你会第一时间看脚本日志,而不是等老板来敲你工位。