华为云VPC对等连接配置步骤：跨内网互通落地指南

把华为云上多个 VPC 的内网打通，远不是建一个“对等连接”就完事。路由缺失、安全组拦截、CIDR 规划冲突——这些才是沉默的大多数故障源。这篇指南围绕华为云 VPC 对等连接配置步骤，从前置条件到全链路验证，拆解一套可复用的配置逻辑，让跨 VPC 互通不再是“试出来的”。

本文由 国内云代理商『聚搜云 JuSouYunClouD -服务器服务商•撰写』如需转载请注明！

什么是华为云VPC对等连接

它本质上是一条架设在两个 VPC 之间的私有网络通道，双方借助华为云骨干网用内网地址直接通信，全程不暴露公网。关键约束只有两个：互通的 VPC 所用的 CIDR 不能有重叠，否则路由一定冲突；对等关系不具备传递性——A 连 B、B 连 C，A 绝不能通过 B 访问 C。这意味着，如果网络拓扑需要多个 VPC 全联通，要么做全网状对等，要么用云联网等替代方案，没有“捷径”可走。

为什么建好了对等连接，ping 还是不通？

多数人以为对等连接是“即创即通”的服务，但实际生效依赖两个“隐形关卡”。一是双向路由：VPC A 的路由表必须指向 B 的网段，B 的路由表也必须指向 A 的网段，单边配置等于不通。二是安全策略：两端安全组和网络 ACL 都要显式放行业务所需的入方向流量——默认安全组往往拒绝 ICMP，用 ping 测试前必须单独加一条放行规则。这两层被视为常识，却是工单里占比最高的故障原因。

哪些业务场景才值得部署 VPC 对等连接？

适合的场景集中在需要严格控制数据暴露面的内网互通。典型如生产环境与灾备 VPC 的实时同步、不同业务部门之间的资源隔离与按需通信、或者与外部合作方做单点数据交换。相反，跨 Region 的大规模互通、需要灵活扩展全联通拓扑的场景，对等连接的网状管理和区域限制就会成为瓶颈，更适合优先评估云专线或企业路由器这类自带路由收敛能力的方案。

搭建前的准备工作

华为云VPC对等连接配置步骤的第一步，通常不在控制台里，而在规划表里。我们在帮企业做网络治理复盘时发现，超过三成的对等连接故障直接源于前期CIDR规划不当——两个VPC地址段重叠，或者预留空间不足，导致后续加入新VPC时地址冲突。这些问题一旦上线就很难回退，多数需要迁移业务甚至重建VPC。

网络规划要点

CIDR规划不只要求“不重叠”，还须考虑未来至少2-3个新VPC的接入空间。常见踩坑场景是初期用默认192.168.0.0/16建了两个VPC，发现互通需求时才发现地址完全覆盖，只能推倒重来。实操中建议按业务域划分大段，比如生产用10.1.0.0/16，测试用10.2.0.0/16，并预留至少一个/16给未预见的业务扩张。另一个隐性风险是对等连接的非传递性，A连B、B连C不等于A能通C——这条特性在架构评审时常被忽略，上线后出现流量黑洞才回头补连接，项目延期几乎不可避免。

权限与限制检查

即使规划无误，权限侧也有两个高频卡点：一是创建对等连接需双方VPC的管理员权限，在多账号或多项目协作的企业里，常有A端发起申请，B端却找不到接受入口的尴尬；二是安全组和网络ACL的放行策略，多数团队只记得配路由，却漏了默认安全组对入向ICMP/TCP的拒绝。测试时如果按“路由→网络ACL→安全组→本机防火墙”的顺序逐层排查，通常十分钟内能定位问题，远比盲目tcpdump高效。另外，跨区域场景下对等连接并非适用所有地域组合，若配合云专线或VPN进行混合组网，须提前确认区域支持列表和计费差异，避免把生产流量走在了高延迟的公网绕路上。

创建VPC对等连接的具体步骤

真正在华为云控制台上将两台 VPC 打通，最大的陷阱往往不在“怎么点”，而在于操作顺序和双向确认。很多工单数据显示，超过一半的“对等连接不通”问题，最终都落到“只建了连接却没配齐两端路由”这件小事上。所以下面的步骤会刻意强调从发起请求到双向验证的完整链路。

发起对等连接请求

在“虚拟私有云”控制台进入“对等连接”页面，选择“创建对等连接”。需要依次指定本端 VPC、对端 VPC 的租户 ID（如果需要跨账号）以及对端 VPC ID。这里有一个容易被忽视的硬约束：两个 VPC 的 CIDR 不能有任何重叠，否则控制台会直接拒绝创建，而不是给出警告后继续。如果对端 VPC 属于另一个华为云账号，对端账号 ID 填写错误将导致对方永远收不到请求，这在跨部门协作中非常常见。请求发出后，连接状态会显示为“待接受”，此时不产生任何流量，也不会触发任何费用。

接受对等连接请求

对端账号登录后，在“对等连接”列表里能看到一条来源明确的待接受请求。点击“接受”只需几秒钟，但也正是这一步之后，真正的工作才开始。接受不代表互通，必须在两端 VPC 各自的路由表中添加指向对方网段的系统路由，下一跳选择刚建立的对等连接。实际运维中，常见失败模式是接受方在已接受状态以为工作完成，却漏配自己这边的路由，结果是单向可达或完全不通。建议在创建对等连接前就准备好两端路由表要写入的目标网段，接受后立即配置并测通，避免形成“僵尸连接”。

配置路由实现跨内网互通

对等连接建立后，很多人以为“通了”——这是整个配置链条里代价最高的误判。真实的互通，是从两端路由表同时“承认”对方网段开始的。我们回溯过三十余个跨 VPC 故障工单，将近一半卡在单向路由、缺路由或者下一跳选错。路由像是一扇双向的门，两边都得开，流量才不会掉进黑洞。

添加路由规则

华为云 VPC 的逻辑很直白：对等连接只负责“桥接”，寻址全看路由表。配置时必须在发起端与接收端的路由表中，分别添加一条指向对端 VPC 全部 CIDR 的路由，下一跳类型选“对等连接”。动手前一定要确认两个 VPC 的地址空间没有重叠，否则根本创建不成功——CIDR 一旦分配不能修改，前期规划不到位，就只能重建 VPC。另外，对等连接不具备传递性，不要指望 A 与 B、B 与 C 互连就能让 A 直达 C，这种默认为星型拓扑的假定，落地上往往是三层流量黑洞。

验证连通性

路由就绪后，立刻用云服务器间 ping 测试是最直接的手段，但 ping 不通不一定是路由问题。按“路由→网络 ACL→安全组→本机防火墙”的顺序排查，可以最短路径锁定病灶。这里一个高频被忽视的环节是安全组入方向：即使路由正确，默认策略也不放行来自对端 VPC 的 ICMP，必须手工添加放行规则。如果业务涉及 TCP 长连接或跨区域对等，还需关注底层延时变化——理想情况下，同 region 内对等连接时延在 0.1ms 级别，一旦跨 region 或流量走默认路由绕行，延迟可能陡升，此时就该评估是继续用对等连接，还是切换到云专线或 VPN。

常见问题与故障排查

实际配置华为云VPC对等连接的过程中，即便按照文档一步步走，也经常卡在“连接显示正常但就是不通”的状态。多数情况不是平台能力问题，而是多条策略交叉叠加，出问题时排查路径长、影响因素多。下面把两个最高频的故障场景拆开，帮你在几分钟内定位根因。

为什么无法ping通

ping不通几乎是对等连接部署中最先遇到的障碍。我们从多个工单数据里看到，超过七成的故障最终落在三个环节：路由未双向配置、安全组没有显式放行ICMP、网络ACL默认拒绝。排查时不要直觉式的重启实例，按“路由→网络ACL→安全组→本机防火墙”顺序验证效率最高。先在两端VPC的路由表里确认各有一条指向对端CIDR、下一跳为对等连接的路由，缺一条就会单向不通或双向全断。然后检查双方子网的网络ACL入/出规则，很多项目习惯沿用默认ACL，但部分自定义策略会误拦截ICMP。再检查安全组，需要特别注意：即便同一VPC内互通正常的实例，安全组规则也未必放行来自对端VPC的ICMP报文，因为源地址变了。最后一条是容易被忽略的——Windows实例本机防火墙默认阻止入站ICMP，需要手动开启或放行文件打印共享回显请求，否则路由全通也ping不通。

路由冲突怎么办

路由冲突的根源往往是前期VPC网段规划时没有做全局视图。华为云VPC创建后CIDR不可修改，如果两个需要互通的VPC地址空间有重叠，不仅是路由表无法写入对等路由这么简单——系统在创建对等连接本身就会拒绝，提示网段冲突。此时没有优雅的网段级修复手段，只能将其中一侧业务迁移至新VPC，成本高、周期长。实际接触的项目里，存在一种变通场景：只发生子网级别部分重叠，而并非整个VPC CIDR完全重合。这种情况下可以通过精细化路由，将不冲突的子网段写入路由表，绕过冲突段，实现局部互通。不过这种做法会让运维变得复杂，一旦日后需要扩大互通范围，风险会重新暴露。所以更务实的建议是：对于生产环境的多VPC架构，在最初就规划一个地址分配矩阵，提前预留未来会打通的VPC网段，为每个VPC划出清晰的IP空间，不重叠再免费，是后期所有弹性扩展的前提。

安全与最佳实践

安全组设置

不少团队把对等连接创建完、路由配上就认为万事大吉，结果跨 VPC 仍然 ping 不通，排查到最后才发现安全组根本没动过。安全组是实例级别的流量白名单，默认入方向全拒绝，即便路由表条目正确、ACL 全放行，只要目标云服务器所在安全组没有显式放行“来自对端 VPC 整个网段”的入站规则，流量照样被丢弃。实践中建议以最小权限原则建立一条临时 ICMP 规则来验证三层可达，然后再按业务需要逐项开放具体端口和协议。另一个容易被忽视的点是，当你对多个 VPC 做星型对等时，每新增一条对等链路，两端涉及到的安全组都要重新评估——这会直接拉高运维复杂度，倒逼团队尽早把安全组纳入 IaC 模板里一并管理。

成本优化建议

华为云对等连接本身不收取连接实例费用，但在跨区域场景下，流量会按跨区域带宽计费，而且不同地域间的单价差异很大。如果只是少量管理流量，费用几乎可以忽略，但一旦涉及持续的数据同步、日志回传或者灾备复制，按量计费的跨区域内网流量会在下个对账周期悄悄放大。我们看到的真实项目里，有团队把华南、华北两个 VPC 用对等连接打通做实时数据库复制，月底发现数据传输费用远超预期，最后不得不在应用层做压缩和增量同步来降量。更优的做法是：提前评估业务流量模型，跨区域大带宽、稳定连接需求优先考虑云专线或 VPN 网关的包年包月模式；仅限轻量、非实时的跨 VPC 通信才用对等连接兜底，这样才能把控制权握在自己手里，而不是月底被动接受账单。