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

上周四下午3点27分，我正在悠闲地喝着第三杯咖啡，突然钉钉炸了——运维组的报警群疯狂弹出「核心业务服务器连接超时」的告警。这个看似普通的网络故障，最终演变成了一场持续6小时的「IP争夺战」…

一、故障初现：所有外网服务集体失联

第一反应是检查服务器状态，SSH连上去发现内网访问完全正常，但curl ifconfig.me返回的居然是陌生的IP。当时我后颈的汗毛都竖起来了——我们的公网IP被劫持了？！

# 最初的异常现象：
$ ping our-domain.com
PING our-domain.com (203.156.xxx.yyy) 56(84) bytes of data.
From 172.31.16.1 icmp_seq=1 Destination Host Unreachable

二、抽丝剥茧：三层网络排查

先给运营商报障，同时自己开始排查：

1. 物理层：确认光猫指示灯正常，光纤衰减值-23dB在合理范围
2. 数据链路层：MAC地址绑定检查无异常，ARP表未发现欺骗
3. 网络层：traceroute显示请求在运营商第二跳就神秘消失

这时候运营商客服回电：「您的IP段正在被迁移到新机房…」好家伙，割接不通知的？

三、真相浮出：IP地址冲突

通过tcpdump抓包发现更诡异的现象：

18:03:45.771 IP 203.156.xxx.yyy > 114.114.114.114: ICMP echo request
18:03:45.779 IP 203.156.xxx.yyy > 114.114.114.114: ICMP echo reply

同一个IP居然在同时收发数据包！最终在运营商工程师配合下确认：由于配置错误，我们的IP被同时分配给了两个不同客户（包括我们）。

四、应急处理：临时方案与长期防御

临时方案：立即申请新IP并修改DNS解析，同时配置NAT回程路由

长期防御：

• 与运营商签订SLA时明确要求变更通知流程
• 部署IPAM系统监控IP使用状态
• 关键业务配置多线路BGP接入

五、经验总结：网络工程师的生存法则

这次事件给我上了三节课：

1. 永远不要完全信任运营商（即使是中国电信）
2. 核心业务必须有多AZ容灾方案
3. 当出现灵异网络问题时，先喝口水冷静下再排查

现在每次看到那个IP地址，我都会想起那个充满咖啡因和血压飙升的下午。如果你也遇到过类似遭遇，欢迎在评论区分享你的「战斗故事」。