Zapret项目网络连接故障排查：从IPv6异常到ARP风暴的解决之路

问题现象分析

在升级Zapret项目至1.6.1版本后，用户遭遇了典型的网络连接异常：通过路由器（无论有线还是无线）无法访问互联网，而直接连接ISP线路则工作正常。故障表现为：

1. 网络连接短暂恢复（1-2分钟）后中断
2. 系统网络状态显示"已连接"但实际无数据传输
3. 网络协议栈异常切换到IPv6-only模式
4. 最终发展为APIPA地址分配（169.254.x.x）

技术背景解析

IPv6与DHCP交互异常

当网络适配器异常切换到IPv6-only模式时，会出现以下典型特征：

• 仅有link-local IPv6地址（fe80::/10）
• 出现fec0::/10范围的DNS服务器（站点本地地址，已弃用）
• IPv4地址完全丢失

这种现象通常表明DHCPv4协商过程被中断，可能是由于：

1. 防火墙规则阻断了DHCP报文
2. 网络堆栈配置损坏
3. 驱动程序兼容性问题

ARP风暴的产生机理

后期出现的ARP请求风暴表明网络中存在二层通信故障：

• 主机无法正确识别网关MAC地址
• 持续发送ARP探测请求
• 导致网络带宽被广播报文占用
• 可能由损坏的NDP（邻居发现协议）缓存引起

系统化解决方案

第一阶段：基础网络重置

1. 驱动程序更新：

   • 升级Realtek PCIe GbE控制器驱动至最新版（10.73.815.2024）
   • 执行干净安装（先卸载旧驱动）

2. 网络堆栈重置：

netsh int ip reset
netsh winsock reset
ipconfig /flushdns

3. 协议栈调整：

netsh interface ipv4 set interface * dadtransmits=0 store=persistent

第二阶段：IPv6处理策略

1. 临时禁用IPv6（控制面板→网络适配器属性）
2. 检查路由器DHCPv6/SLAAC配置
3. 验证ICMPv6报文过滤规则

第三阶段：ARP问题根治

1. 使用Wireshark捕获ARP流量
2. 分析异常ARP请求模式
3. 重置网络适配器硬件配置（设备管理器→卸载设备→扫描硬件改动）

经验总结

1. 版本升级注意事项：

   • 网络过滤工具更新可能影响底层协议栈
   • 建议在非生产环境先测试新版本

2. 故障诊断方法论：

   • 从物理层逐步向上排查（电缆→MAC→IP→传输层）
   • 对比正常/异常状态的网络配置差异
   • 善用协议分析工具（Wireshark）

3. 预防性维护建议：

   • 定期导出网络配置备份
   • 建立网络状态基准线
   • 考虑使用虚拟化环境测试网络变更

该案例展示了网络过滤工具与系统协议栈深度交互可能引发的复杂问题，强调了对网络各层协议的理解在故障诊断中的重要性。通过系统化的排查方法，最终定位并解决了由ARP风暴引起的网络中断问题。