那个诡异的IP冲突：一次公网IP被占用的排查历险记

大家好，我是33blog的技术博主。今天要分享的是一个真实发生的运维事故——我们的公网IP突然被神秘设备占用，导致服务中断的完整排查过程。这个案例教会我：永远不要对网络问题掉以轻心。

1. 警报响起时的混乱现场

那天凌晨2:15，手机突然被告警短信轰炸。我们的核心API服务全部离线，监控面板一片血红。第一反应是云服务商出了问题，但控制台显示一切正常。

通过VPN连入内网后，我发现了诡异的现象：

$ ping api.33blog.com
PING api.33blog.com (203.0.113.45) 56(84) bytes of data.
From 203.0.113.45 icmp_seq=1 Destination Host Unreachable

更奇怪的是，这个IP居然能ping通，但返回的是”Host Unreachable”，而不是超时。这暗示着——有设备在用这个IP！

2. 网络侦探工作开始

我立刻登录核心交换机，抓取ARP表：

# 在Cisco交换机上
Switch# show arp | include 203.0.113.45
Internet  203.0.113.45     5   00e0.4c68.33a9  ARPA   Vlan100

这个MAC地址不属于我们任何已知设备！更可怕的是，traceroute显示流量在到达边界防火墙前就消失了：

$ traceroute 203.0.113.45
 1  10.0.100.1 (10.0.100.1)  0.512 ms
 2  10.0.0.254 (10.0.0.254)  1.203 ms
 3  * * *

3. 物理层狩猎

拿着MAC地址，我开始了”物理寻宝”：

1. 在接入交换机定位到端口Gig1/0/24
2. 顺着网线找到了一台…打印机？！
3. 打印机配置界面显示它被手动设置了203.0.113.45

原来市场部新买的彩色打印机，供应商工程师”为了方便测试”直接配置了我们的公网IP，而交接时没人告知这个改动！

4. 血泪教训

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

• IPAM系统必须严格：现在我们把所有IP（包括保留IP）都纳入了IP地址管理系统
• 新设备入网流程：增加了供应商设备验收检查表
• ARP监控告警：对核心网段设置了未知MAC地址告警

最后分享一个实用命令，现在已成为我的应急预案标配：

# 快速定位IP冲突
$ arping -D -I eth0 203.0.113.45
ARPING 203.0.113.45 from 0.0.0.0 eth0
Unicast reply from 203.0.113.45 [00:E0:4C:68:33:A9]  0.512ms

这次事件后，公司流传着一个新梗：”当服务挂了，先检查打印机”。希望这个真实案例对你有帮助，欢迎在评论区分享你的奇葩故障经历！