GCP跨项目重叠子网VPC间内部流量路由方案咨询

场景回顾 #

项目A的VPC A（子网1：10.10.142.0/24）需与项目B、C的VPC（均含子网1：10.10.12.0/24）通信，已排除VPC共享、普通VPC Peering方案，此前尝试NCC分支网络+Private NAT方案在添加项目C后路由失效。

方案一：Cloud VPN + 地址转换 + 静态路由 #

这是最可靠的方案，通过VPN隧道结合源/目标NAT解决重叠子网的路由冲突：

1. 部署Cloud VPN网关

   • 在项目A、B、C各自的VPC中创建Cloud VPN网关（网关需分配公网IP用于建立IPsec隧道，但虚拟机通信仍为内部流量）。
   • 为项目A分别与B、C建立独立的IPsec VPN隧道。

2. 配置地址转换规则

   • 项目A到B的流量：
     • 在VPC A中配置源NAT，将10.10.142.0/24的流量转换为非重叠段（如10.10.202.0/24）后发往B的VPN隧道。
     • 在项目B的VPN隧道上配置目标NAT，将10.10.202.0/24转换回VPC B的10.10.12.0/24；同时反向配置源NAT，将B的10.10.12.0/24转换为10.10.102.0/24，确保回包能路由回A。
   • 项目A到C的流量：
     • 同理，将A的源IP转换为10.10.203.0/24，C的目标IP转换为10.10.103.0/24，反向转换对应调整。

3. 添加静态路由

   • 在VPC A中添加两条静态路由：
     • 目标CIDR 10.10.102.0/24 → 下一跳为到B的VPN隧道
     • 目标CIDR 10.10.103.0/24 → 下一跳为到C的VPN隧道
   • 在项目B、C的VPC中分别添加静态路由，指向对应VPN隧道以回包。

4. 防火墙规则配置

   • 允许转换后的IP段（如10.10.202.0/24与10.10.102.0/24、10.10.203.0/24与10.10.103.0/24）之间的SSH及所需通信端口。

方案二：修复Network Connectivity Center（NCC）配置 #

针对此前NCC方案的路由失效问题，通过独立分支网络+路由映射解决冲突：

1. 创建独立分支网络

   • 为项目B、C分别创建独立的NCC分支网络，各自关联对应的VPC。

2. 配置分支网络的地址映射

   • 对B的分支网络：
     • 源IP转换：将VPC A的10.10.142.0/24映射为10.10.202.0/24
     • 目标IP转换：将VPC B的10.10.12.0/24映射为10.10.102.0/24
   • 对C的分支网络：
     • 源IP转换：将VPC A的10.10.142.0/24映射为10.10.203.0/24
     • 目标IP转换：将VPC C的10.10.12.0/24映射为10.10.103.0/24

3. 添加静态路由

   • 在VPC A中添加两条静态路由：
     • 目标CIDR 10.10.102.0/24 → 下一跳为NCC中心到B分支的连接
     • 目标CIDR 10.10.103.0/24 → 下一跳为NCC中心到C分支的连接

4. 验证路由与防火墙

   • 确保NCC的路由优先级高于默认路由，且各分支的防火墙规则允许转换后的IP段通信。

方案可行性分析：带Private NAT的VPC Peering #

该方案不可行。VPC Peering的建立前提是双方VPC无重叠子网，即使配置Private NAT，Peering本身无法区分两个相同CIDR的目标VPC，会导致路由冲突，与此前NCC遇到的问题本质一致。

内容的提问来源于stack exchange，提问作者def