内容摘要：上周五下午，运维老张在机房里对着核心交换机发呆。他刚把办公网段的DHCP租约时间从8小时改成1小时，结果不到半天，内网就炸了——一百多台电脑同时掉线，再上线时IP全变了。排查到最后，发现是有人把一台家

上周五下午，内网运维老张在机房里对着核心交换机发呆。使用他刚把办公网段的公网告DHCP租约时间从8小时改成1小时，结果不到半天，地址的排内网就炸了——一百多台电脑同时掉线，查报再上线时IP全变了。内网排查到最后，使用发现是公网告有人把一台家用路由器带进了办公室，顺手把它的地址的排WAN口接到了墙上的网口上。那台路由器默认的查报LAN网段是192.168.1.0/24，而恰好，内网我们公司内网用的使用也是这个段。更麻烦的公网告是，那台路由器的地址的排DHCP服务没关，它开始向内网广播地址分配信息。查报

这种事儿其实不罕见。很多公司内部网络规划时，直接沿用了公网IP段，比如常见的202.96.x.x或者59.44.x.x。原因很简单，早期建网时没人想过这些地址会真的出现在公网上，或者觉得内网隔离够彻底，用啥不是用。但问题是，当内网设备真的去访问一个公网IP，而这个IP恰好与内网某台服务器的地址相同时，数据包会先被路由到内网那台机器上。你访问的是外网，走的却是内网的路，结果要么超时，要么连到一台你根本不认识的服务器上。

我见过一个真实的案例。一家做跨境电商的小公司，他们的财务系统服务器用的IP是203.66.12.18，这个地址在公网上属于某欧洲云服务商。有一天，财务人员发现系统奇慢无比，每次打开报表都要等半分钟。后来抓包一看，原来系统里某个功能模块会自动调用一个海外API，而那个API的域名解析出来的IP恰好也是203.66.12.18。内网路由优先级高于默认网关，于是所有请求都跑到了财务服务器上，然后被服务器当成无效数据丢弃。就这么一个巧合，让整个财务部门干等了三天。

排查这类问题，最直接的办法就是查路由表。在核心交换机上执行 show ip route 或 tracert 一个公网地址，看第一跳是不是内网设备。如果是，基本就能确认内网存在与目标公网IP重叠的地址。更彻底的做法是扫描全网段，找出所有配置了公网IP的接口。用Nmap扫一下，或者直接写个脚本批量ping，很快就能定位。但说实话，很多小公司根本没有完整的IP资产台账，全靠运维脑子记。一旦换人，这事儿就变成玄学。

最让人头疼的是，有些设备不是固定配置，而是动态获取的。比如上面提到的那台家用路由器，它自己会从公司的主DHCP服务器拿到一个地址，然后它再向下级设备分发另一套地址。这种“套娃”结构，排查起来特别费劲。你得先找到那个路由器，拔掉它的WAN口，再重启核心交换机清理ARP缓存，才能恢复正常。可问题是，你永远不知道办公室里还有多少台这样的设备。今天拔了一台，下个月又有人带一台进来。

解决思路其实不复杂。要么把内网全部改成私有地址段（10.x、172.16-31.x、192.168.x），但这需要全网改造，停机窗口和人力成本都不小。要么在出口防火墙上做NAT映射，把内网那些公网IP地址一对一翻译成别的地址，但这只能解决访问冲突，解决不了内网路由混乱的问题。我个人的建议是，先做一次彻底的IP资产盘点，用工具扫描所有存活主机，标记出那些使用公网IP的设备，然后分批迁移到私有段。这个过程可能持续几个月，但总比哪天财务系统突然连不上银行要强。

最后说个细节。那次处理完老张的麻烦后，我在那台惹事路由器的管理界面里看到它的WAN口IP是10.23.45.6，跟公司服务器段一模一样。我猜那位同事大概是觉得“反正都是IP，插上就能用”，结果差点让整个办公室断网半天。技术问题背后往往都是人的问题，这句话在运维这行，永远不过时。