引言
某天，接到用户反馈：总部（奇安信防火墙）与分部（飞塔防火墙）之间的IPSec隧道访问异常卡顿，带宽不足10Mbps，且CPU和内存占用均正常。问题看似简单，但排查过程却意外揭示了工程师的一个“历史遗留操作”——debugging调试日志未关闭。
本文将详细还原排错过程，并总结技术经验。
一、故障现象与初步分析
用户描述
网络架构：总部（奇安信）与分部（飞塔）通过IPSec隧道互联。
问题表现：内网访问卡顿，带宽骤降至10Mbps以下，但防火墙资源占用“正常”。
初步验证
带宽测试：使用 iperf3 测试隧道吞吐量，确认带宽瓶颈。
流量统计：检查两端防火墙接口流量（如 show interface），发现低流量高延迟。
关键疑问：为何资源占用正常，但性能极差？
二、深度排查：从隧道到系统
- IPSec隧道状态检查
目标：确认隧道协商正常，无配置冲突。
操作步骤：
bash
奇安信防火墙
show isakmp proposal # 查看IKE阶段1状态
show ipsec sa # 查看IPSec阶段2状态
飞塔防火墙
diagnose vpn ike gateway list
diagnose vpn tunnel list
结果：隧道状态均为 UP，但流量统计显示低吞吐量。
- 配置一致性验证
比对参数：
IKE版本、加密算法（AES256）、哈希算法（SHA256）、DH组、PFS组、SA生存时间。
NAT-T是否启用（UDP 4500端口开放）。
结论：两端配置完全一致，排除参数问题。
- 网络路径与性能排查
MTU问题：
bash
ping -s 1472 <对端公网IP> # 测试MTU是否导致分片（1472+28=1500）
结果：无分片丢包，排除MTU问题。
接口拥塞：检查WAN口带宽利用率，确认无外部流量拥塞。
三、突破口：系统日志与隐藏的I/O瓶颈
- 资源监控的盲区
表象：CPU和内存占用率均低于30%，看似正常。
深层分析：
使用 show process cpu 查看进程详情，发现 debugd 进程（调试守护进程）的 I/O等待时间占比极高。
真相：调试日志持续写入磁盘，导致I/O队列阻塞，影响数据包转发效率。
- 日志中的“海量调试信息”
关键命令：
bash
show log buffer | include DEBUG # 过滤调试日志
发现：日志中持续输出IPSec隧道报文细节（如 IPSec packet debugging is on）。
- 历史配置的致命遗留
回溯配置变更：
bash
show configuration history | include debug # 查询历史调试命令
真相浮现：3个月前某次故障排查后，工程师未关闭 debugging ipsec packet 命令。
四、故障解决与验证
- 关闭调试功能
操作命令：
bash
undo debugging ipsec packet # 关闭IPSec调试
undo debugging ike packet # 关闭IKE调试
undebug all # 关闭debug调试
clear log buffer # 清空日志缓存
- 效果验证
带宽恢复：iperf3 测试带宽恢复至100Mbps+。
隧道稳定性：show ipsec sa 显示无频繁重建。
五、经验总结与避坑指南
- 根本原因
调试日志功能未关闭 → 高频磁盘I/O阻塞 → 隧道吞吐量暴跌。 - 技术启示录
调试功能是双刃剑：
务必在排查后 立即关闭调试命令（尤其是生产环境）。
日志级别建议长期设置为 warning 或 error。
监控需全面：
除CPU/内存外，I/O等待时间、磁盘队列深度需纳入监控指标。
配置审计常态化：
定期使用 show configuration history 检查遗留调试命令。
- 写给工程师的“防坑”Tips
善用备注：在配置中添加注释，标明调试命令的用途和关闭时限。
自动化检查：通过脚本定期扫描配置中的 debug 关键字。
性能瓶颈思维：当资源占用正常但性能低下时，优先怀疑I/O或网络队列问题。
结语
此次故障的排查，揭示了“看似正常”的系统指标背后可能隐藏的深层问题。调试日志的遗忘关闭如同一颗“定时炸弹”，最终通过I/O瓶颈“引爆”性能。
希望本文能为同行提供参考，在未来的运维中少走弯路！
**技术无小事，细节定成败。