我看到的实现是通过摆弄接入点上的 MAC 转发表来完成的。由于接入点只是充当网桥，因此非常适合此类任务。在交换层，它已经收集了所有听到的（有时称为学习的）MAC 以及可以在哪个接口上找到它。

逻辑看起来像这样：

1. 接入点通过无线接口接收数据包
2. 桥接子系统检查目标 MAC 的数据包
3. 如果目标 MAC 在无线接口的学习交换表中 -> DROP
4. 否则通过有线接口转发数据包

由于网络桥接的工作方式，我认为这很难欺骗接入点将数据包转发给客户端，尽管是隔离的。您最好的选择是尝试直接与其他客户端对话，就好像您在使用 ad-hoc 网络一样。

无线客户端隔离，它是如何工作的以及它是如何被绕过的：

当您与接入点（AP/路由器）建立无线 (wpa/wpa2-aes/tkip) 连接时，会创建 2 个密钥，一个用于单播流量的唯一密钥和一个用于广播流量的共享密钥，该密钥与每台连接的 PC 共享，称为 GTK。

当您向 AP 发送数据时，它会使用您的单播密钥进行加密。然后 AP 对此进行解密并使用广播 GTK 将数据发送到无线网络上的下一个系统。

当您在 AP 上启用客户端隔离时，它会停止使用 GTK 发送数据。因为每个人都建立了一个唯一的单播密钥与你发送数据，将不再能够看到彼此的数据。

绕过这一点需要更多的努力和理解。知道 ARP 流量仍然使用 GTK 通过网络广播，以便 DHCP 可以维护客户端。

如果 ARP 表因客户端条目上的广播 MAC 而中毒，您将强制客户端系统在发送数据时使用广播 GTK。如果客户端系统被欺骗使用 GTK 发送数据，现在可以看到它，您将绕过客户端隔离。

因此，如果您使用带有 bradcast mac 的客户端 ip 设置本地静态 ARP 条目，您的本地系统将在与该客户端通信时认为它正在发送广播流量，并使用 GTK 允许客户端查看您的流量。

DHCP 修复中毒的 ARP 条目大约需要两分钟，因此您必须编写一个流式传输中毒/假 ARP 的程序以保持可见性。

我承认一些高级 AP 具有需要高级策略的 arp 控制和第 2 层隔离，但我们不是在谈论那些人在谈论你的 SOHO。

干杯。