那个被占用的公网IP：一次惊心动魄的网络故障排查实录

大家好，我是33blog的运维老司机。今天要分享的是上周处理的一个真实案例——我们的公网IP突然被神秘占用，导致整个业务中断。整个过程就像侦探破案一样刺激，现在回想起来还觉得肾上腺素飙升。

1. 警报响起：服务突然失联

周二凌晨2:15，手机突然被PagerDuty的警报震醒——核心API服务全部超时。睡眼惺忪地连上VPN，发现更诡异的现象：

• 从内网访问一切正常
• 公网curl返回”Connection refused”
• 安全组规则确认无误

当时我的第一反应是：”见鬼了，难道云厂商又出幺蛾子？”

2. 抽丝剥茧：发现IP冲突

用tcpdump抓包时发现了个奇怪现象：

# 在目标服务器执行
sudo tcpdump -i eth0 host 203.0.113.45
# 结果居然看到来自其他MAC地址的ARP响应！

这时候才意识到问题的严重性——我们的公网IP203.0.113.45（示例IP）被别的设备占用了！赶紧用nmap扫描确认：

nmap -Pn -p 22,80,443 203.0.113.45
# 返回结果居然显示开着MySQL端口？！

3. 真相大白：虚拟机克隆惹的祸

联系云厂商技术支持后，发现是隔壁业务组的骚操作：

1. 他们克隆了带固定IP的虚拟机模板
2. 新实例启动时没有释放旧IP
3. 两台机器在ARP层打架

最讽刺的是，占用我们IP的居然是公司内部测试环境…（此处应有捂脸表情）

4. 应急处理：快速恢复方案

在等他们修复的同时，我们做了个临时方案：

# 在受影响服务器执行
arp -s 203.0.113.45 00:11:22:33:44:55  # 强制绑定正确MAC
echo 1 > /proc/sys/net/ipv4/conf/eth0/arp_ignore

这个临时方案让服务恢复了80%的访问，至少能撑到早上上班时间。

5. 经验总结：血的教训

这次事故教会我们几个重要经验：

• IPAM系统很重要：现在全公司强制使用IP地址管理系统
• 克隆虚拟机要小心：新制定了虚拟机克隆规范流程
• 监控要全面：新增了ARP异常监控项

最后说句掏心窝的话：运维这行，永远不要相信”巧合”。每个离奇故障背后，肯定有个让人哭笑不得的人为因素。大家有什么奇葩故障经历，欢迎在评论区分享~