把两个地域的内网打通之前：网段规划和路由优先级要先定下来

A 环境和 B 环境都用了 192.168.1.0/24。两边各自跑了两年，相安无事。某天业务要打通，链路建好、隧道起来、路由一对发，运维登上 A 环境的一台机器去 ping B 环境的 192.168.1.20——不通。换一台机器再 ping，通了，但通的压根不是他要的那台，是 B 环境里另一个用途完全不同的业务主机，而且这台机器上的服务端口恰好也开着。

这就是网段撞车最典型的两种表现：要么完全不可达，要么可达但可达错了。第二种比第一种危险得多，因为它是"看起来好的"——监控是绿的，连通性测试是过的，只有业务数据悄悄写到了错的地方。

这篇要讲的，就是在按下"打通"这个按钮之前，必须先定下来的两件事：网段怎么分配，以及多条路由并存时谁说了算。全文的判断只有一句——内网互通是"先规划后施工"的活，不是"连上再优化"的活。

先把结论摆在这里：

• 网段冲突一旦形成，后期改网段的代价比前期规划高一个数量级，因为 IP 会写进配置文件、白名单、证书、DNS 和合作方系统里。
• 补救只有三条路：改网段、做地址映射、做重叠过渡。第一条最干净也最贵，第二条能通但毁掉端到端可观测性，第三条是技术债。
• 地址规划要分层切，每个地域拿一个不连续的大段，并且必须留一段完全空闲的段给未来并入的环境。
• 路由优先级要按"明细压聚合"来设计，跨地域链路默认当备份路径而不是主路径，等价路由在跨地域场景要慎用。
• 禁止非对称回程——去程走 A、回程走 B，状态化设备会直接把包丢掉，ping 全通业务照样断。

两个 192.168.1.0/24 撞在一起，到底发生了什么

先把这个故障讲透，因为后面所有的规划原则都是从它推出来的。

A 环境和 B 环境都用 192.168.1.0/24。打通之后，A 侧一台主机（192.168.1.10）要访问 B 侧的 192.168.1.20。主机查自己的路由表，发现目的地址 192.168.1.20 和自己同在一个 /24 里——三层设备根本不参与，二层直接发 ARP 问"谁是 192.168.1.20"。问的是自己这一侧的网段，答案要么是没有，要么就是 A 侧碰巧也有这个地址的那台机器。于是出现了开头那两种结果。

反过来，如果两侧网段不重叠，比如 A 用 10.16.0.0/12、B 用 10.48.0.0/12，主机查路由表发现目的地址不在本地网段，就把包交给网关，网关再按路由表送到隧道或者互联链路。整个路径是确定的、可追踪的、可收敛的。

所以网段冲突的本质不是"地址不够用"，是路由失去了唯一性。一个目的地址在两套环境里同时存在，转发设备就不知道该把包交给谁。而"先连上"这个思路的毛病在于：连通性测试是在冲突已经存在的前提下做的，测出来的"通"和"不通"都不可信。

为什么"先连上再优化"在网段这件事上不成立

很多团队的计划是：先把链路拉起来，跑通再说，网段问题等遇到再改。这个顺序在其他事情上或许可行，在网段规划上行不通，原因有三个。

第一，IP 地址的扩散范围远超你的想象。一台机器改 IP，要动的东西包括：本机网卡配置、负载均衡后端、数据库连接白名单、应用配置文件里写死的地址、监控系统里的采集目标、DNS 记录、内网证书里的 IP SAN、对端合作方防火墙上的放行条目、甚至某些客户端 App 里硬编码的服务地址。改 IP 不是一个网络变更，是一个跨多个系统的联合变更，每多一个系统，回滚难度翻一倍。

第二，冲突不会立刻全部暴露。打通初期只放行了几个业务，撞车的那几个段可能暂时没被用到。等到半年后业务铺开，某个新上线的服务正好落在冲突段里，那时候这套网已经承载了生产流量，改网段意味着停业务。

第三，"先连上"会产生一种虚假的安全感。链路起来了、ping 通了、验收过了，于是没人再提网段规划这件事。等到第三个地域要接入，旧账一起算。

撞车之后的三条补救路，代价从重到轻怎么排

如果现在已经是既成事实——两套环境已经在跑，网段确实撞了，那只有三条路可以走。这三条路没有一条是"免费的"，选哪条取决于你能接受哪种代价。

第一条：改网段，代价最大但最干净

把其中一套环境整体迁到新的网段。这条路的代价是前面说的那个联合变更：改配置、改白名单、改 DNS、改监控、改证书、通知合作方。一套中等规模的环境（几百台机器、几十个服务）做完整的网段迁移，通常需要按业务线分批停服窗口推进，周期以周计。

但它换来的东西也是唯一的：端到端的地址唯一性。日志里的源 IP 是真的，链路追踪里的跳是真的，安全策略可以写到主机级别，出了问题 traceroute 一把就能定位。这是唯一不留技术债的方案。

什么时候该咬牙走这条？两套环境的规模都还不大、业务停机窗口能申请下来、而且未来还会有第三个第四个地域接入的时候。越早改越便宜，这是我在这个问题上最确定的一个判断。

第二条：做地址映射（NAT），能通但会毁掉可观测性

在互联边界上做地址转换：A 侧访问 B 侧时，把目的地址映射成一段"过渡地址"；或者把 A 侧的源地址映射成另一段。这样两边看到的地址都不冲突，包能通。

代价藏在细节里，而且是长期的：

• 日志里的源 IP 失真。B 侧的访问日志看到的不是 A 侧真实主机地址，而是映射后的地址。出了安全事件要溯源，得再查一遍映射表。一旦映射是多对一（端口复用），溯源基本做不了。
• 安全策略难写。原来"只允许 10.16.3.0/24 访问数据库 3306"这条规则，在映射之后要改成对映射后地址放行，而映射后的地址可能同时代表多个真实来源，粒度被稀释。
• 端到端追踪断裂。分布式链路追踪、APM、服务网格的拓扑图，都是基于真实 IP 做关联分析的。中间做了一次地址转换，调用链会在边界处断成两截。
• 应用兼容性。有些协议会在 payload 里携带自己的 IP 地址（FTP、SIP、某些 RPC 框架的服务注册），单纯的三层地址转换处理不了这些，需要 ALG 或者应用层配合。
• 多了一处状态化设备。会话表有容量上限，有老化时间，有单点。跨地域链路本来就有带宽和时延约束，再挂一个有状态设备上去，扩容时要重新评估。

这条路适合什么场景？临时打通、明确知道这个状态只会持续几个月、且被打通的业务对可观测性要求不高——比如一次性的数据迁移、一次性的历史数据同步。把它当成永久方案，就是给自己埋雷。

第三条：重叠过渡方案，短期止痛长期欠债

第三类是各种"先让它跑起来"的过渡手法：给重叠的段做双向地址映射、只在边界网关上做主机级的静态映射、或者干脆只对冲突段做策略路由把流量强行牵引。100.64.0.0/10（RFC 6598 定义的共享地址空间）经常被拿来当过渡映射池用，就因为它不大可能被业务环境本身占用。

这类方案的问题是它会沉淀下来。过渡方案上线三个月，没人记得它是过渡方案；上线一年，它变成了"核心链路的一部分"，文档里写着"不要动这段配置，动了会断"。技术债的特征就是这样——不是它不能用，是它挡住了后面所有更合理的改动。

如果不得不用过渡方案，至少做两件事：在文档里写明退役时间和责任人，以及把过渡地址段和正式业务地址段严格分开（正式规划里绝不使用 100.64.0.0/10），这样将来收债的时候有明确的边界。

一套能撑到第五个地域的地址规划怎么切

规划的目标不是"够用"，是"未来加东西的时候不用推倒重来"。具体做法可以拆成四条原则。

原则一：按地域—环境—业务三层切，不要一路 /24 平铺

最常见也是最糟糕的做法：需要一段就申请一个 /24，用完了再申请下一个，最后手上攒了三十个零散的 /24，彼此之间没有规律。这种规划在只有两个地域的时候还能凑合，一旦要做路由聚合——比如"把地域 A 的所有段一次性发布给地域 B"——你会发现这三十个 /24 根本聚不成一条路由，只能一条一条发。路由条目数涨上去，排障和管控都变难。

正确的切法是自上而下：

• 顶层按地域切大块。每个地域拿一个 /12 或者 /13，地域之间不连续。10.0.0.0/8 一共能切出 16 个 /12，够绝大多数企业用到第五个甚至第八个地域。
• 地域内按环境切。生产、预发、测试各拿一块，比如生产 /13、预发 /14、剩余留给测试和容器。环境之间要能一句话说清楚边界，因为跨环境的访问策略通常不一样。
• 环境内按业务线切 /16，业务内按应用切 /24。这样"地域 A 的生产环境"可以聚合成一条或两条路由发布出去，而"地域 A 生产的订单服务"又能单独拎出来做明细放行。

每个地域拿不连续的大段，这一点很重要。连续的段在合并路由时容易被人手滑写成一条超大的聚合路由（比如把 10.16.0.0/12 和 10.48.0.0/12 一路聚成 10.0.0.0/8），一旦聚合粒度失控，原本"只允许 A 的订单段访问 B 的数据库"这条策略，就变成了"整个 10 段都能访问"。

原则二：容器网段必须一起规划，它是最大的隐藏冲突源

主机网段规划得再整齐，容器网段没规划，照样撞。而且容器网段撞车更隐蔽——节点之间能通，Pod 之间不通，或者跨集群的 Service 互通时行为诡异。

几个常见的默认值要特别注意：Calico 默认 Pod 网段是 192.168.0.0/16，Flannel 常见默认 10.244.0.0/16，Kubernetes Service CIDR 常见默认 10.96.0.0/12。这些默认值如果两边都没改，打通的时候几乎必然撞。

容器网段规划有三条要注意：Pod CIDR 要给足（容器扩缩容频繁，地址消耗比物理机快得多）；Service CIDR 是虚拟地址，不参与跨地域路由，不要把它发布出去；跨地域访问容器服务，应该走 Ingress 或者网关，而不是直接路由到 Pod 段。

原则三：留一段完全空闲的段，这是规划里最值钱的一行

预留空闲段的价值，体现在三种时刻：公司并购进来一套完整的环境、业务要开新的地域、临时要建一套和现有环境隔离的测试或容灾环境。

为什么"预留"优于"按需分配"？因为按需分配的前提是"你现在知道未来要什么"，而这个前提从来不成立。等你需要新段的时候才发现 10.0.0.0/8 已经被切得零零散散，新并入的环境只能要么挤进某个夹缝里（破坏聚合）、要么做地址映射（回到上一条的坑）。预留的代价是规划时"浪费"了几个段，收益是未来并入时不用重做整套规划——这个交换在任何一家还会增长的公司都是划算的。

预留要留连续且足够大的块，建议不少于一个 /10（64 个 /16），并且明确写进文档："此段未分配，任何人都不得使用，动用需评审"。没有这条约束，预留段会在半年内被某个"临时用一下"的需求吃掉。

原则四：把容易漏掉的段一次性列全

盘点网段时，下面这些段经常被漏掉，然后成为打通时的暗雷：容器 Pod 与 Service 段、负载均衡与中间件（消息队列、缓存、注册中心）的网段、VPN 与远程接入的地址池、带外管理与 IPMI 段、监控系统采集端段、数据库只读副本与备份节点段、云上 VPC 的辅助网段、以及合作方对接时对方放行的地址段。漏掉任何一类，都可能在打通后表现为"部分业务通、部分业务不通"，而这类故障排查起来最费时间。

下面这张表是一套示例草案，覆盖两个地域加一个自建机房的场景。所有网段均为示例，实际规划需按你自己的地址库存与业务结构来定。

这张表里真正值钱的是最后两行。前面十行解决的是"现在能不能通"，最后两行解决的是"半年后加东西时会不会重做"。

路由优先级：明细压聚合，跨地域链路别当主路走

网段规划解决"地址唯一"，路由规则解决"包走哪条路"。多路由来源并存时，如果优先级没定死，就会出现那种最难查的故障——连上了，但流量走了不该走的路。

最长前缀匹配是硬件行为，配置层面盖不住

第一条要刻在脑子里的规则：转发时永远选掩码最长的那条路由。路由表里同时有 10.0.0.0/8（指向跨地域链路）和 10.16.3.0/24（指向本地），目的地址 10.16.3.5 一定走 /24 那条，跟这条路由是谁配的、什么时候配的、优先级数值写了多少，都没有关系。

这条规则的好处是：只要你在本地保留了明细路由，跨地域链路上的聚合路由就不会把本地流量劫走。坏处是反过来也成立——如果你在对端发布了一条比本地更长的明细路由（比如某个 /28），本地流量就会被吸引到跨地域链路去。所以发布路由这件事要收口，不能随便发。

不同来源的路由，优先级数值不一样

最长前缀匹配只在掩码长度不同时起作用。当两条路由掩码一样长（比如都是 /24）但来源不同，就比"管理距离"或者"路由优先级"——这是厂商给不同路由来源预设的信任等级。

以华为 VRP 体系的常见取值为例：直连路由 0、OSPF 内部路由 10、静态路由 60、RIP 100、BGP 255，数值越小越优先。思科体系的取值是另一套（直连 0、静态 1、eBGP 20、OSPF 110、iBGP 200）。不同厂商、甚至同一厂商不同产品线的取值都可能不同，实施前必须查你手上这台设备的文档，不要凭记忆套数字。

这里有个实操坑：很多人用静态路由做跨地域备份路径，又跑动态路由协议学明细路由。如果静态路由的掩码和动态学到的路由掩码一样长，而静态路由的优先级数值更小，那么备份路径会一直压着主路径走，故障切换根本不会发生。正确的做法是让备份路径的掩码更短、或者显式调整它的优先级数值，并且用实际断链演练验证一次。

等价路由在跨地域场景要慎用

等价路由（ECMP）是个好东西：多条同优先级、同开销的路由并存，设备按哈希把流量分摊到多条链路上，带宽能叠加。在同城、同机房、链路特性一致的场景里，它几乎是标配。

跨地域场景不一样。两条跨地域链路的时延通常不相等，哈希分流会把同一个 TCP 连接或者同一对通信主体的流量分到不同时延的链路上，结果是乱序和抖动——对数据库同步、对实时消息、对任何有状态的长连接，这比带宽不够还难受。所以跨地域互联我倾向于主备而不是负载分担：主路径走本地域内闭环，跨地域链路作为备份路径，只在主路径失效时接管。

主备要配三件事：切换的检测方式（链路探测还是路由收敛）、切换后的回切策略、以及防止链路抖动导致频繁切换的抑制机制。少了抑制机制，一条质量不稳定的链路会让路由在几秒钟内来回翻，业务表现为间歇性断流，比彻底断了更难定位。

一张示例的路由优先级顺序

把上面的规则落到一套可执行的顺序上，大致是这样（示例草案）：

• 第一档：直连路由。本地 VLAN、本地 VPC 子网，天然最高优先级。
• 第二档：本地域明细路由。/24、/20 级别，来自本地动态路由协议或本地静态配置。
• 第三档：跨地域学到的明细路由。只限于白名单里明确要互通的那些段，掩码不短于 /24。
• 第四档：跨地域聚合路由。/16 或 /12，只作为兜底，承载"规划里暂时没细分但确实要通"的流量，且要经过评审。
• 第五档：默认路由。指向公网出口，明确不允许承载内网流量——内网流量走默认路由，是很多"能通但很慢"或者"时通时不通"故障的根因。

配套的约束是：只向对端发布明细段，绝不发布聚合段。这一条看起来保守，实际能挡掉大部分越权访问和路由劫持。

非对称回程：ping 全通，业务还是断

这是打通之后最常见的"诡异故障"，值得单独讲。

现象是这样的：A 侧 ping B 侧通，B 侧 ping A 侧也通，单向的连通性测试全绿。但业务就是建立不了连接，或者连接建立了马上断。

原因是去程和回程走了不同的路径。A 发往 B 的包走了跨地域链路甲，B 回给 A 的包走了另一条路径乙。如果路径乙上有状态化设备——防火墙、NAT 网关、有状态负载均衡——这台设备在正向流量经过时没建立会话，回程的包到了它这里就成了"莫名其妙的包"，直接丢掉。

非对称回程在跨地域场景特别容易发生，因为两端的路由策略往往由不同人配置、甚至是不同时期配置的。一边改了 metric，另一边没跟着改，路由就歪了。

排查方法很朴素：做双向 traceroute。从 A 到 B 打一次，从 B 到 A 打一次，把两跳路径打印出来比对。两边路径不互为镜像，或者中间出现的设备对不上，就是非对称。单做一次单向 traceroute 是发现不了的，这也是这类故障经常拖很久的原因。

预防比排查重要。定路由规则的时候就把"回程对称"写成一条硬约束：两端发布对端明细路由的掩码长度要一致、优先级数值要对称、metric 要对称，并且每次变更后用双向 traceroute 验收。

放行清单与禁止清单：跨地域链路不是万能通道

打通之后最容易失控的不是网络，是安全边界。网段规划好了、路由也对了，但如果流量白名单没划清楚，这套网会在半年内变成"什么流量都在跨地域跑"的状态，然后带宽和时延问题一起爆发。

建议放行的流量

• 运维管理流量。堡垒机、跳板机到各地域主机的 SSH/RDP，来源限定到管理段。这是跨地域互通最正当的用途。
• 数据同步与复制。数据库主从复制、对象存储跨地域复制、消息队列的异地消费。这类流量通常可以限速、可以断点续传，对时延抖动容忍度较高。
• 备份与归档。备份流量最好有独立的带宽配额和调度窗口，避免和在线业务抢带宽。
• 监控与日志汇聚。采集端向汇聚端上报，量不大但要求稳定，建议单独一条策略。
• 统一认证与目录服务。LDAP、统一身份认证的查询流量，通常是小包高频，对时延敏感，要确保走最短路径。

建议禁止的流量

• 东西向业务调用。服务 A 调服务 B 这种内部 RPC，应该在本地域内闭环。跨地域做服务间调用，等于把一次内网调用变成一次跨地域往返，接口响应时间直接加上几十毫秒，而且这个延迟会沿着调用链放大。
• 容器集群内的东西向流量。Pod 之间的通信不该跨地域，跨集群访问走网关。
• 广播与组播。广播域止于三层，组播默认也不跨三层转发，需要额外配置组播路由，而且跨地域组播的运维复杂度很高。设计时就不要依赖它。
• 批量计算的中间数据。离线任务的中间结果、临时文件传输，要么本地处理要么走对象存储，不要占跨地域带宽。
• 对时延敏感的同步调用。如果业务上确实需要跨地域读数据，更好的做法是本地放一份只读副本，而不是每次跨地域去读。

打通之后安全组的收敛范围会被放大

这条单独拎出来，因为它是"打通"这个动作最直接的副作用。

打通之前，"源地址 10.0.0.0/8 放行 3306"这条规则的实际生效范围，只是你自己这一个环境里的机器，因为其他地址段根本到不了你这里。打通之后，同样这条规则，生效范围变成了两套甚至三套环境的全部机器。规则的文本一个字没改，实际权限翻了好几倍。

所以打通的同时要做一次安全策略收敛：把所有 /8、/16 粒度的放行规则过一遍，能收到 /24 就收到 /24，能限定端口就限定端口，能加双向约束就加双向约束（只放行入向不够，出向也要看）。这件事不做，等于打通的瞬间把安全边界悄悄放宽了。

顺带提一句 MTU：跨地域隧道会引入额外的封装开销，实际可用 MTU 会变小，表现为小包通、大包不通或者某些应用卡住。这一条本批另有专文展开，这里只提醒你在验证清单里加上"大包测试"这一项。

打通的顺序：从单网段单向开始，别一上来就全量

前面所有东西都定下来之后，才轮到施工。施工顺序建议如下，每一步都有明确的验收标准，不通过就停在那里。

第一步：盘点，盘到"配置文件里的硬编码"这一层

把两侧所有在用网段列成一张清单，包括：VPC 与子网、容器 Pod 与 Service 段、负载均衡与中间件段、VPN 地址池、带外管理段、监控采集端段、数据库白名单里的地址、DNS 记录、内网证书里的 IP SAN、应用配置文件里写死的 IP、以及合作方侧放行的地址段。

盘点要做的第二件事是找冲突：把两侧清单做一次交集，凡是重叠的段全部标红。第三件事是预估未来——把"明年可能并入的公司""下半年可能开的地域"也写进清单，因为它们决定了预留段要留多大。

第二步：定地址规划，写成文档并评审

按前面的分层原则切分，输出一张像上文那样的规划表，明确写出哪些段是已分配、哪些是预留、哪些禁止跨地域。这份文档需要架构、网络、安全、运维几方一起评审，因为每个人知道的信息不一样——运维知道哪些配置文件里写死了 IP，安全知道哪些白名单改不动。

第三步：定路由规则与优先级

输出一张路由优先级顺序表，明确：不同来源路由的优先级数值、哪些段以什么掩码发布给对端、主备路径如何切换、回程对称怎么保证。这张表要在变更之前就定稿，而不是边配边想。

第四步：定义互通白名单，默认拒绝

按"放行清单/禁止清单"输出策略表，粒度到"源段 + 目的段 + 端口 + 协议"。默认拒绝，逐条放行。这一步的输出可以直接翻译成安全组和 ACL 规则。

第五步：小范围打通验证，先单网段单向

第一次打通，只放一个网段、只放一个方向。比如只放行"A 侧订单段访问 B 侧数据库 3306"，B 侧主动访问 A 侧一律不放。这样做的理由是：单向放行能立刻暴露回程路径问题，单网段能把故障面限制在最小范围。

验收要做五项：

• 双向 traceroute，确认去程回程路径对称、跳数符合预期。
• 指定端口的连通性测试（telnet 或者 nc 测真实端口），不要只测 ICMP——ICMP 通不代表业务端口通，安全组可能只放行了 ICMP。
• 大包测试，验证 MTU 是否满足（ping 时指定不分片和大包长）。
• 长连接观察，建一个连接放着不关，观察 24 到 72 小时，看会话是否稳定、有没有被中间设备老化掉。
• 日志核对，看对端日志里记录的源 IP 是不是真实地址——如果做了地址映射，这一步会立刻暴露出来。

第六步：按业务线放量，每次放量重复一次验收

不要一次性把所有白名单全开。按业务线一批一批加，每加一批，重复第五步的验收。批量上线的诱惑很大，但一旦出问题，你无法定位是哪一条规则引起的。

第七步：留回滚方案，而且回滚不能依赖改网段

回滚方案要能在变更窗口内完成：撤回对端路由发布、撤回收敛后的安全组规则、把流量导回原路径。关键要求是回滚路径里不能有"改 IP"这个动作——如果需要改 IP 才能回滚，说明这个方案本身就是失败的。变更窗口里同时改两套系统的 IP，风险不可控。

两地域 + 一个机房的网段与路由草案

下面是一套假设场景的完整草案，用来把前面的原则串起来。以下为典型部署思路，并非特指某一真实客户。

假设某公司现有三个点：地域 A（承载主站与订单业务，云上 VPC）、地域 B（承载数据与离线计算，云上 VPC）、一个自建托管机房（承载历史系统与部分物理机）。现在要把三者内网打通。

网段分配草案

沿用前文的规划表：地域 A 生产 10.16.0.0/13、预发测试 10.24.0.0/14、容器 Pod 10.30.0.0/16 与 Service 10.31.0.0/20；地域 B 生产 10.48.0.0/13、预发测试 10.56.0.0/14、容器 Pod 10.62.0.0/16；托管机房 10.80.0.0/14；全局管理段 10.200.0.0/16；VPN 地址池 10.201.0.0/20；预留 10.128.0.0/10 不动；过渡映射池 100.64.0.0/10 在过渡期专用。

这里有个细节值得说：托管机房只给了 /14，比两个云上地域小。这是有意的——物理机数量增长慢、扩缩容不频繁，给小一点；云上和容器环境扩缩容频繁，给大一点。按增长速度分配，而不是按现状平均分配。

路由优先级草案

• 各地域内部：直连路由与本地明细路由优先，跨地域路由一律排在后面。
• A 到 B：仅发布"地域 A 订单段 10.16.3.0/24 → 地域 B 数据库段 10.48.9.0/24 的 3306"这一条明细，掩码 /24，优先级设为低于本地明细的档位。
• B 到 A：发布对称的明细回程路由，掩码与 metric 与去程保持一致，保证回程对称。
• 机房到两地：仅允许备份与同步流量，掩码 /24，且限定时段与带宽配额。
• 兜底：不发布任何 /12 或 /13 级别的聚合路由。真有未规划的段需要互通，走评审后单独加明细。
• 默认路由：明确禁止承载内网段流量，内网段到不了就丢，不允许静默走到公网出口。

实施节奏草案

第一批只打通"地域 A 管理段 → 地域 B 管理段"，单向放行，跑 72 小时看稳定性。第二批打通"地域 A 订单段 → 地域 B 数据库段"，加双向 traceroute 与长连接观察。第三批接入托管机房的备份流量，限定窗口与带宽。容器段全程不跨地域，跨集群访问走网关。

这套草案跑通之后，将来接入第四个地域时，要做的只是从预留段 10.128.0.0/10 里切一块出来、按同样规则加明细路由和白名单——不需要动任何已分配的网段，也不需要重做规划。这就是预留段的价值兑现的时刻。

跨地域内网的带宽、时延、计费，别照抄同城经验

这段讲的是边界。前面讲的所有设计原则都有一个前提：跨地域链路的带宽、时延和计费模型，与同地域内网完全不同。把同城内网的经验直接搬过来，是另一类常见的翻车。

带宽上，同地域内网通常是端口速率级别（1G、10G、25G），而且多数不计流量费。跨地域链路的带宽受实际线路资源约束，通常比内网小一到两个数量级，而且扩容需要提前申请线路资源，不是点一下控制台就能加的。规划时要把跨地域带宽当成稀缺资源来分配，为备份、同步、管理流量分别设配额，别让某一个业务的突发把链路打满。

时延上，跨地域往返时延通常在几十毫秒量级，具体数值取决于实际路由跳数、线路类型与运营商路径。这个数字必须按实际线路核实，不要用经验值做容量设计。同样的两个地域，走不同线路，时延可以差出好几倍。设计接口超时、数据库连接池、分布式锁的持有时间时，都要基于实测值而不是估算值。

计费上，跨地域流量通常按出方向流量计费，或者按带宽端口包月计费，两侧计费口径可能不一致；如果走公网加密隧道，还要额外算公网带宽和 NAT 开销。签约前要把计费口径问清楚：按哪一侧出方向算、有没有免费额度、超了怎么计价。行业里常见的隐藏收费项里，跨地域流量一直排在前几位，就是因为它平时不显眼，出问题的时候已经是按月累计的一笔钱了。

在资源这一侧，一万网络深耕 IDC 19 年（成立于 2007 年），在华南、华东、华北、华西以及中国香港、海外多个节点都有资源，BGP 多线加上 CN2 GIA 回国线路，做多地域服务器部署与组网时，各地域的机器和带宽可以在同一套方案里统筹——这点很实际，因为跨地域组网最怕的就是两侧资源分属不同供应商，出问题时两边工单互相踢皮球。如果需要云上一侧做弹性伸缩，一万云 ¥25 起（起价通常对应最低配置与最短租期，实际成交价需询价）；如果机房一侧要物理机，裸金属 E5-2698v4×2 32G/1T 是 ¥3999 起（官网明示价，以官网实时价为准，海外节点有买 1 送 1 活动）。

要提醒的是：跨地域链路的具体带宽档位、时延承诺与流量单价，都必须按实际线路与签约条款核实，不同节点、不同线路类型的差异很大，不存在一个通用数字。规划阶段留足余量，签约阶段把口径写进合同。

规划阶段最常被追问的七个问题

网段撞了，能不能不改 IP 就打通？

能，代价是把问题换了个形式。做地址映射可以让包通，但换来的是日志源 IP 失真、链路追踪断裂、安全策略粒度变粗、多一处状态化设备。我的判断是：如果这套互联要存在超过半年，或者被打通的业务需要排障和审计，就别省改网段这份成本。真要选映射，也请把它限定在"一次性数据迁移"这类短期场景里。

容器网段要不要和主机网段一起规划？

必须一起，而且容器段的优先级还要更高一点。因为默认值撞车是常态——Calico 默认 192.168.0.0/16、Flannel 常见 10.244.0.0/16、Service CIDR 常见 10.96.0.0/12，两边都不改就必然撞。而且容器段一旦分配出去，集群已经跑起来之后再改，代价远高于物理机改 IP。建议把 Pod 段和 Service 段都显式写进规划表，Service 段是虚拟地址，明确不发布到互联链路。

打通之后安全组和 ACL 要不要重配？

要，而且要当成打通的必备步骤而不是后续优化。原因是规则的实际生效范围变了：打通之前"10.0.0.0/8 放行"只覆盖你自己这套环境，打通之后它覆盖了对端全部机器。规则文本没变，权限翻了几倍。做法是趁打通这个窗口把所有大粒度的放行规则收一遍，能到 /24 就到 /24，能限端口就限端口，出向和入向都要看。

跨地域流量怎么计费，按哪一侧算？

这个没有统一答案，取决于你用的线路和产品。常见口径是按出方向流量计费，或者按带宽端口包月，两侧口径可能不同；走公网加密隧道的话还要另算公网带宽。签约前必须问清楚三件事：按哪一侧的出方向算、有没有包含在套餐里的免费额度、超出部分怎么计价。别等到月底账单出来才发现口径和自己理解的不一样。

能不能只放行单向？

技术上可以，而且我在验证阶段就建议先单向放行——因为它能立刻暴露回程路径问题。但业务层面要看协议：有返回流量的协议（绝大多数 TCP 应用）如果只放单向，表现为握手能发起但收不到响应。正确的单向放行是"只允许 A 侧主动发起，B 侧响应流量自动放行"，这需要状态化策略支持，不是简单地在 ACL 里只写一条入向规则。

新增第三个地域时要动什么？

如果前面的规划做对了，要动的只有三处：从预留段里切一块给新地域、按同样规则加明细路由、按业务线加白名单。已分配的网段一个都不用动。如果规划没做对——预留段被吃掉了、或者网段是零散 /24 平铺的——那就得重新谈地址分配，这时候你会发现每多一个地域，重做的成本翻一倍。这也是我把"预留空闲段"看得这么重的原因。

回程不对称会造成什么问题，怎么发现？

现象是 ping 双向都通、端口测试也可能通，但业务连接建立不了或者建了就断。原因是去程回程走了不同路径，回程路径上的状态化设备（防火墙、NAT 网关、有状态负载均衡）没有正向会话，直接把回程包丢了。发现方法只有一个可靠手段：从两端各做一次 traceroute，比对路径是否互为镜像。单向 traceroute 看不出来，这也是这类故障经常拖很久的原因。预防靠在路由规则里把"两端掩码长度、优先级、metric 对称"写成硬约束。

这些规则和数字我是怎么核的

文中涉及的网段与路由示例均为规划草案，不是任何真实环境的配置，其中容器网络的默认值（Calico 的 192.168.0.0/16、Flannel 的 10.244.0.0/16、Service CIDR 的 10.96.0.0/12）来自各项目公开文档的常见默认配置，实际以你使用的版本为准；路由优先级数值以厂商文档为准，不同厂商与不同产品系列取值不同，实施前务必核对设备文档；100.64.0.0/10 为 RFC 6598 定义的共享地址空间。

一万网络的节点分布、线路类型、服务基线（7×24 中文工单、平均 5 分钟响应、硬件故障 10 分钟内自动迁移）、裸金属与一万云的起步价格，均取自 https://www.idc10000.net/ 官网相关页面，写作时已按"起价通常对应最低配置与最短租期"的口径标注。跨地域链路的带宽档位、时延表现与流量计费单价需按实际线路与签约条款核实，具体以签约时最新报价与合同为准。

最后再说一次这篇的判断：内网互通这件事，八成的功夫在按下"打通"按钮之前。网段分配要在第一台机器起来之前就定死一套可扩容的规划，并且给未来并购和新地域留出完全空闲的段；路由优先级要写清楚明细压聚合、备份路径的切换条件、以及哪些流量禁止跨地域绕行。这两件事没定就打通，后面每加一个地域，都要把账重算一遍。