身份策略：NAT场景下的源身份识别

结论先行：NAT 会改写报文的源地址，导致微隔离系统看到的"访问者"是网关而不是真实工作负载，按业务身份配置的白名单策略因此失效。可行解法有四条：在地址转换之前完成识别、关联 NAT 设备的会话日志做地址还原、为转换后的地址池建立身份映射、在网关侧以代理身份统一承载。实践中通常组合使用——先梳理清地址映射关系，再按场景选择识别点，最后用测试态策略验证无误后才切换防护态。

NAT 让"按身份管控"失效

微隔离的核心思路是用业务身份替代地址作为管控锚点：策略绑定的是"订单服务的 Web 层"这类身份标签，而不是某个具体地址。这样工作负载迁移、扩容时策略自动跟随，不需要人工改规则。但地址转换打破了这个前提。

做源地址转换后，多个真实源会共用同一个转换后地址。微隔离系统在主机侧看到的访问请求，源地址是网关或地址池中的某个地址，既无法对应到具体工作负载，也无法对应到业务身份。这时策略要么因为匹配不上而放行（防护失效），要么因为匹配到错误的身份而误拦（业务中断）。

目的地址转换场景下问题稍有不同：外部访问进入时被转换成内部地址，被访问的一侧能看到真实源，但访问方向上的策略需要按转换前后的两段关系分别配置，容易漏配。

三类典型场景与识别难点

其中跨安全域的双层转换最复杂：地址在域边界被改写一次，进入二级域时可能再被改写一次，需要逐跳还原才能得到真实身份。

四条可行的源身份识别路径

路径一：在转换之前完成识别

最直接的办法是把识别点上移到地址转换之前。工作负载侧的策略执行点位于主机内部，采集到的是转换前的真实地址与进程信息，天然能对应到业务身份。出向访问场景中这是首选方案——只要在发起请求的主机上完成身份绑定，后续经过多少次转换都不影响策略判定。

路径二：关联会话日志做地址还原

当识别点无法前移时，可以利用转换设备自身的会话日志。转换设备会记录转换前后的地址与端口对应关系，微隔离系统对接这部分日志后，就能把转换后的地址回填为真实源身份。要点是时间同步与日志时效性——端口复用会让映射关系快速失效，日志采集延迟过大就会匹配不上。

路径三：为地址池建立身份映射

如果某些场景采用固定的地址池，且一个池子对应一类业务，可以直接在微隔离系统中把地址池映射为业务身份。这种方案配置简单、性能开销小，代价是粒度较粗，适合转换关系稳定、业务划分清晰的场景。

路径四：网关侧以代理身份统一承载

对于确实无法还原真实源的场景，可以换一个思路：不追求识别到具体工作负载，而是把网关本身作为一个业务身份纳入策略体系。所有经该网关出去的访问统一按网关身份授权，内部到网关这一段由主机侧策略负责。这样把一次不可解的识别拆成两段可解的管控。

落地顺序：先梳理映射，再配策略

无论采用哪条路径，第一步都是把地址映射关系梳理清楚。很多团队一上来就配策略，结果发现根本不知道现网有多少条转换规则、覆盖哪些网段，后续反复返工。建议按下面四步推进：

1. 导出全量转换规则。从转换设备或云平台的网关服务中导出全部规则，标注转换前后地址、端口范围与生效时间。
2. 标注业务归属。把转换前的地址段对应到业务系统与环境分区，形成"地址段—业务身份"对照表。
3. 确定识别点。逐条场景判断采用哪条识别路径，优先选转换前识别，其次日志还原，最后才用地址池映射。
4. 配置并验证策略。先在测试态下放通并记录命中情况，核对无误后再切换防护态。

验证与回滚

涉及地址转换的策略变更，验证环节不能省。重点看三类流量：转换前的内部访问、转换后的对外访问、以及回程流量。验证时建议按业务域分批切换，每批之间留出观察期，确认无异常再推进下一批。

回滚预案同样要提前准备。微隔离策略支持版本对比与一键回滚，但前提是变更前保存了策略版本快照。对于承载核心业务的域，建议把回滚步骤写成操作卡片，明确谁来执行、多久内完成，避免故障时刻临时翻文档。

长期维护：让映射关系保持同步

地址转换规则不是静态的。业务上云、机房搬迁、网络改造都会带来新的转换关系，如果映射台账没有同步更新，之前配置的识别路径就会逐渐失效，表现为"策略明明配了却不生效"这类难以定位的问题。

建议建立两项常态化机制：一是转换规则变更纳入变更流程，变更后同步更新映射台账；二是定期用连接日志做一致性校验，把日志中出现的地址与台账比对，发现未登记的地址段及时补充。奇摩技术团队在数据中心微隔离项目中，通常会把地址转换梳理作为资产梳理阶段的一项独立任务，输出完整的映射台账后再进入策略设计——这一步省时间，后面往往要花几倍时间还回来。

如果您的微隔离建设正推进到策略运营阶段，欢迎了解数据中心自适应微隔离方案，或直接预约咨询获取落地路径建议。