AWS与Azure新建S2S VPN的跨VPC流量路由问题排查求助

你好呀！从你的描述来看，VPN隧道已经连通且有流量跑起来，说明基础的S2S VPN链路是没问题的，问题大概率出在路由转发、权限配置这几块，我给你梳理几个重点排查方向，你可以挨个验证：

• 先盯紧AWS的VPC对等连接

  • 检查EC2所在VPC的路由表：有没有添加路由条目，把Azure子网段（比如10.3.0.0/16，根据你提供的VM IP推测）的流量指向VPC对等连接；同时，VPN网关所在VPC的路由表，也要有把EC2子网段（10.0.0.0/24）的流量发去对等连接的条目。
  • 确认对等连接的状态和配置：两边VPC的对等连接必须已经互相接受，另外可以检查下是否开启了跨VPC的访问权限（比如允许双方的子网互相访问），别在对等连接的配置上卡壳。

• 检查BGP路由的宣告与学习

  • 登录AWS控制台看Virtual Private Gateway（VPG）的路由配置：确认是否把EC2所在的10.0.0.0/24网段通过BGP宣告给了Azure的VPN网关，只有Azure那边学到这个路由，才知道要把对应流量发去VPN隧道。
  • 去Azure那边验证：在VPN网关的BGP路由页面，查看已接收的路由条目，确认10.0.0.0/24是否在列表里；如果没学到，就得回头检查AWS这边的BGP宣告配置。

• 安全组与本地防火墙别漏了

  • EC2实例的安全组：要放行来自10.3.0.0/16网段的入站流量，同时出站规则也要允许发往10.3.0.0/16的流量；同理，Azure VM的网络安全组（NSG）也要放行10.0.0.0/24网段的入站和出站流量。
  • 操作系统层面的防火墙：比如Linux的iptables、Windows的本地防火墙，有可能默认挡住了跨网段的流量，可以临时关闭测试，或者手动添加规则放行对应网段的通信。

• 别忽略VPC的网络ACL

  • 网络ACL是AWS VPC的“第二层防火墙”，容易被忽略。要确认EC2所在VPC的网络ACL，入站和出站都放行10.3.0.0/16的流量；VPN网关所在VPC的网络ACL，也要放行10.0.0.0/24的流量，确保数据包能顺利通过。

另外给你个小技巧：可以在Azure VM上用tracert 10.0.0.150（Windows）或者traceroute 10.0.0.150（Linux）追踪数据包路径，看看卡在了哪一步——是到了AWS VPN网关就停了，还是没出Azure，或者在VPC对等连接那断了，这样能快速缩小排查范围。

备注：内容来源于stack exchange，提问作者Chris