那个深夜，我们的公网IP神秘失踪了——一次IP冲突排查全记录

上周四凌晨2点17分，我的手机突然疯狂震动。迷迷糊糊抓起来一看，监控系统告警：生产环境VPN突然失联。作为一个经历过多次深夜故障的老运维，我瞬间清醒——这绝对不是什么小问题。

一、故障现象：VPN集体掉线

连上跳板机后，我立即检查了VPN服务器状态：

# 检查OpenVPN服务状态
systemctl status openvpn@server
# 返回结果：Active: active (running)

服务明明在跑，但所有客户端都无法连接。更诡异的是，从内网SSH到这台服务器完全正常。这时候我后背开始发凉——这症状太像IP冲突了。

二、第一反应：ARP侦查

我立刻在核心交换机上抓包，果然发现了异常：

# 在交换机上执行
show arp | include 203.0.113.45
# 返回两个MAC地址：
# 00:1a:4b:xx:xx:xx (我们的服务器)
# 5c:5e:ab:xx:xx:xx (陌生设备)

看到这里我反而松了口气，至少确认不是配置错误。但新的问题来了：这个5c:5e:ab开头的MAC到底是谁？

三、追踪神秘设备

通过MAC地址前三位查询厂商，显示是某国产物联网设备。我们机房根本没有这类设备！这时候我突然想起上个月新来的实习生…

• Step 1: 查询DHCP日志，发现该MAC昨天刚获取过IP
• Step 2: 定位到接入交换机Port 3/12
• Step 3: 冲到机房拔线，VPN瞬间恢复

四、真相大白：实习生的小实验

第二天上班后，果然发现是实习生把测试用的智能摄像头直接插在了办公网络。这个设备被配置了静态IP，恰巧和我们VPN服务器撞车。

血泪教训：新设备接入必须走审批流程！我连夜写了段自动化检测脚本：

#!/usr/bin/env python3
# ARP监控脚本
from scapy.all import *

def arp_monitor(pkt):
    if ARP in pkt and pkt[ARP].op in (1,2): # who-has or is-at
        if pkt[ARP].psrc == '203.0.113.45':
            send_mail_alert(f"IP冲突告警！MAC: {pkt[ARP].hwsrc}")

sniff(prn=arp_monitor, filter="arp", store=0)

五、后续改进措施

这次事故让我们做了三个重要改进：

1. 核心IP段启用IP-MAC绑定
2. 网络接入层开启端口安全
3. 所有实习生设备强制使用10.开头的测试IP段

现在回想起来，虽然折腾到凌晨4点，但这次排查过程确实让我对ARP协议和网络隔离有了更深的理解。下次如果再遇到类似问题，估计半小时内就能搞定了。