Intel E810 SR-IOV VF Spoofcheck 防伪造测试-KVM3

前言

在云计算与虚拟化场景中，网络安全是重中之重。通过 SR-IOV 技术将 VF（虚拟功能）直通给虚拟机，虽然能带来接近物理网卡的极致性能，但也引入了 MAC 地址伪造的风险。为此，网卡硬件提供了 Spoofcheck（反欺骗） 功能。本文将基于超聚变服务器与 Intel E810 25G 网卡，详细记录 VF Spoofcheck 功能的验证全过程，并分享测试中遇到的"硬件静默丢包"避坑经验。

测试环境与拓扑说明

硬件平台：超聚变 V7/V8 服务器，Intel E810-XXV 25G 网卡
宿主机 OS：Ubuntu 22.04.3 Server
虚拟机 OS：Ubuntu 22.04.3 Desktop
网络模式 ：macvtap (type='direct') 或 hostdev 直通模式

测试拓扑 ：

两台宿主机（A1, A2）通过交换机互联（或同宿主机下两个 VM 通过同 PF 下不同 VF 内部交换），分别创建虚拟机 VM-A 和 VM-B。

VM-A (发送端)：IP 192.168.5.50，绑定 VF-A。
VM-B (接收端)：IP 192.168.5.60，绑定 VF-B。

🛠️ 测试准备

宿主机创建 VF 并挂载（见前面文章）：

在 A1 和 A2 上分别创建 VF（示例） echo 1 > /sys/class/net/ens3f0/device/sriov_numvfs # 确认 VF 状态（默认 spoof checking on） ip link show ens3f0 | grep -i vf
虚拟机内安装测试工具 ：

在 VM-A 内安装 scapy 用于伪造报文发包：
复制代码
```
sudo apt update && sudo apt install -y python3-scapy tcpdump
```
验证基础连通性 ：

在 VM-A 内 ping 192.168.5.60，确保两端通过 VF 网络正常互通。

实战步骤

步骤 1：关闭 Spoofcheck（伪造报文应放行）

1. 在宿主机 A1 上关闭 VF 的反欺骗功能：

复制代码

# 注意：vf 后面的 0 是 VF 的索引号
ip link set dev ens3f0 vf 0 spoofchk off
ip link show dev ens3f0 | grep "vf 0"
# 预期看到 "spoof checking off"

2. 在 VM-B（接收端）开启抓包：

复制代码

sudo tcpdump -i enp5s0 -nn -e icmp

3. 在 VM-A（发送端）用 Scapy 构造伪造报文并发送：

复制代码

sudo python3 - <<'EOF'
from scapy.all import Ether, IP, ICMP, sendp
# 伪造源 MAC 为 00:11:22:33:44:55，目的 MAC 为 VM-B 的 VF MAC
pkt = Ether(src="00:11:22:33:44:55", dst="52:54:00:aa:01:02") / IP(src="192.168.5.50", dst="192.168.5.60") / ICMP()
# 注意替换 iface 为 VM-A 内部的 VF 网卡名，如 ens7
sendp(pkt, iface="ens7", count=5)
EOF

预期结果 ：VM-B 的 tcpdump 成功抓取到源 MAC 为 00:11:22:33:44:55 的 ICMP 报文。

步骤 2：开启 Spoofcheck（伪造报文应被丢弃）

1. 在宿主机 A1 上开启 VF 的反欺骗功能：

复制代码

ip link set dev ens3f0 vf 0 spoofchk on

2. 保持 VM-B 抓包，在 VM-A 内再次执行上述 Scapy 发包脚本。

预期结果 ：VM-B 的 tcpdump 抓不到任何伪造报文。伪造包在到达 A1 的网卡芯片时，被硬件直接丢弃。

步骤 3：解绑与重绑 VF，验证属性持久化

1. 解绑验证：

在宿主机 A1 上关闭 VM-A 并解绑 VF，查看状态：

复制代码

virsh destroy VM-A
virsh detach-interface VM-A --type direct --mac 52:54:00:aa:02:01 --config
ip link show dev ens3f0 | grep "vf 0"
# 预期结果：状态依然保持 "spoof checking on"

2. 重绑验证：

重新绑定并启动 VM-A，再次查看状态，预期依然保持 on，证明硬件属性不受虚拟机生命周期影响。

深度避坑：为什么 ethtool 计数器和 dmesg 毫无反应？

在测试过程中，很多工程师会习惯性地去宿主机执行 ethtool -S ens3f0 | grep tx_errors 或 dmesg 查看丢包统计，结果发现计数器根本没有增加，日志也没有报错。

这不是 Spoofcheck 没生效，而是 Intel E810 的驱动/硬件特性！

静默丢弃 (Silent Drop)：E810 网卡的反欺骗拦截发生在底层硬件流水线中，对于违规报文，硬件采取的是"静默丢弃"策略，不会触发内核级别的报错机制。
寄存器映射缺陷 ：E810 硬件没有实现专门统计 VF 发送丢弃的独立寄存器。当 spoofchk on 时丢的包，底层会计入 PF 的 tx_errors。但目前在 BC-Linux 内核（5.10 版本）自带的 ice 驱动中，并没有将这个 PF 级别的错误计数正确映射到 VF 的 tx_dropped 统计中，导致你在 ip -s link show 里看到的 dropped 永远是 0。

结论：在当前的 ice 驱动版本下，切勿以计数器或内核日志作为验证依据 。最准确、最直接的验证方式，就是接收端（VM-B）的抓包对比。抓到了就是放行，抓不到就是被拦截，简单粗暴且绝对有效。

测试总结

通过上述流程，完美验证了 Intel E810 网卡 SR-IOV VF 的 Spoofcheck 功能：

关闭状态下：允许伪造 MAC 发送报文，存在安全风险。
开启状态下：硬件底层成功拦截伪造报文，保障虚拟机网络安全。
属性持久化：VF 的解绑与重新绑定，均不会重置 Spoofcheck 状态。

希望这篇关于 E810 网卡 SR-IOV 防欺骗测试的踩坑实录，能给正在做虚拟化网络安全测试的你带来帮助！如有问题，欢迎在评论区交流探讨。

Intel E810 SR-IOV VF Spoofcheck 防伪造测试-KVM3

前言

测试环境与拓扑说明

🛠️ 测试准备

在 A1 和 A2 上分别创建 VF（示例） echo 1 > /sys/class/net/ens3f0/device/sriov_numvfs # 确认 VF 状态（默认 spoof checking on） ip link show ens3f0 | grep -i vf

实战步骤

步骤 1：关闭 Spoofcheck（伪造报文应放行）

步骤 2：开启 Spoofcheck（伪造报文应被丢弃）

步骤 3：解绑与重绑 VF，验证属性持久化

深度避坑：为什么 ethtool 计数器和 dmesg 毫无反应？

测试总结