企业管理 IP 资源时常犯的错误

当每个团队都只能看到自己的计划时，两个合理的请求也可能发生冲突。

地址问题往往始于普通变更：项目创建了一个子网，服务器退役了，客户需要一个固定地址。如果作出这些变更的人看不到彼此的决定，也看不到遗留下来的依赖关系，问题就会不断扩大。

改进管理，首先要找出记录与实际运行网络不一致的地方。以下六类错误值得排查，每一类都有相应的实用检查方法。

1. 把记录当成现实的证明

资源清单可能描述的是预期状态，而设备或云资源实际运行的却是另一套配置。发现扫描则是另一种观察结果，也有自身的覆盖范围和观测时间。两者都不应在没有说明的情况下覆盖对方。

选取一个前缀，对照规划、DHCP 或会话记录、设备配置，以及相关云资源清单。标记不一致之处，留待调查。记录每项事实的来源和最近一次核实的时间。真正有用的改进，是让记录说得清楚，而不只是让仪表板显示更多内容。

2. 在缺少共同背景信息的情况下分配地址

如果两个团队可以从同一个地址池分配地址，却看不到彼此的预留情况，各自维护的电子表格就会带来风险。静态地址本身并不是错误；真正难以管理的是没有负责人、适用范围和变更历史的地址分配。

为地址分配明确路由上下文，并设置可靠的预留步骤。测试并发请求。隔离网络中使用重叠的私有地址段可以是合理的，包括不同 VRF 中的网络；当这些网络需要互通时，才需要关注重叠问题。NetBox 的 VRF 文档提供了如何表示这种隔离关系的具体示例。

3. 因为地址看起来没有活动就将其回收

设备可能不响应 ping。它可能只是暂时离线，也可能服务于每月才运行一次的流程。DNS 记录、合作伙伴访问列表、备用系统和计划中的项目，也可能依赖某个当前流量很少的地址。

询问服务负责人，检查这些依赖关系，并根据服务特点选择适当的时间跨度来复核观测结果。确认退役完成后，保留分配历史，再将资源归还到相应地址池。“未观察到使用”和“可供复用”是不同的状态。

4. 在协议决策上想当然

IPv4、IPv6、双栈和地址转换会带来不同的运维影响。应根据客户可达性、应用支持情况、设备和运营成本作出选择，并在计划采用的设计下同时测试名称解析与连接。

IPv6 地址空间更大，并不意味着无需管理前缀、有效期和依赖关系。地址转换可以支撑真实服务，但也会增加状态管理和故障排查要求。关于必然替代的口号，无法回答你的用户今天究竟能访问什么。

5. 指望资源清单软件独自承担安全保障

地址记录可以帮助确定由哪个团队负责某个系统，但它既不能验证使用者的身份，也不能执行应用访问控制。NIST 的零信任模型清楚说明了，为什么单凭网络位置不能建立信任。

将地址历史与相关身份、会话和安全记录关联起来，并设置适当的访问控制。应让路由监控、DNS 安全和设备防护作为不同功能保持清晰可辨。这样，其中某一项出现故障时，就不容易被看似正常的 IPAM 状态掩盖。

6. 依赖无法替换的记录管理方

一个工具可能把所有信息汇集到同一界面，却让底层关系难以导出。应测试前缀、路由上下文、负责人和变更历史离开该工具后，是否仍然具有明确意义。验证恢复能力，以及管理服务中断期间本地团队能做什么。

Lu Heng 的札记 72也在互联网尺度上讨论了这一问题。必要的协调应保障连续性，以及参与者更换服务商的能力。组织内部需要共同视图，并不能成为对使用者施加不受问责控制的理由。

从一次完整变更开始

跟踪一个请求，从预留到部署，再到最终退役。明确每一步的负责人，检查实际结果，并记录如果出错应如何纠正。复核频率应取决于变更速度及其后果：仅靠一年一次的快照，无法描述每天都在变化的网络。

下一步可以使用 IPAM 工具评估指南，检验拟采用的系统能否改善这套工作流程。