已配置NAT Gateway与Internet Gateway的AWS VPC无法访问互联网

架构老林

2026-11-1

NAT网关部署路由环路导致的互联网访问故障

核心根因

你当前的配置存在NAT网关部署的典型路由逻辑错误，所有公网访问异常都可以被这个根因解释：

你将NAT Gateway、EC2实例、Client VPN承载流量全部部署在同一个10.0.0.0/24子网中，且为这个唯一子网关联的路由表，将所有公网流量（0.0.0.0/0）指向了本子网内的NAT Gateway
按照AWS VPC的路由规则，NAT Gateway本身需要从所在子网的路由表获取公网转发路径，正常逻辑下承载NAT Gateway的子网必须为公有子网，即该子网路由表的0.0.0.0/0目标必须指向已附加的Internet Gateway
你当前的配置相当于让NAT Gateway自身的公网出口流量，被路由重新指回自身，形成无限路由环路：
1. EC2发起的公网流量按照路由指向NAT Gateway的10.0.0.95
2. NAT Gateway收到流量准备做源地址转换后转发到公网时，根据所在子网的路由表，判定所有公网流量需要转发给NAT Gateway自己
3. 流量在NAT Gateway和所在子网路由之间循环，根本无法到达Internet Gateway

Reachability Analyzer输出的所有误导性报错，本质都是路由环路衍生的结果：因为流量根本没有抵达IGW的有效路径，分析工具顺着断链的路径反向推导，才会提示“没有到IGW的可用路由”“源地址没有公网IP”“IGW收到伪造源地址流量”这类提示。

你观察到的另外两个异常现象，是独立原因叠加导致的：

你尝试ping NAT Gateway的私有IP10.0.0.95无响应，属于AWS托管服务的正常设计：NAT Gateway本身不支持任何入站流量，包括同子网的ICMP ping、SSH连接等，这类探测行为不会收到响应，不属于配置故障
你连入Client VPN后本地设备无法访问互联网，是VPN配置和路由环路共同导致的：配置Client VPN Endpoint时，大概率给VPN关联的目标网络添加了0.0.0.0/0的默认路由，且没有启用分流隧道（Split Tunnel），会把本地设备的所有互联网流量全部导入VPC；因为VPC侧本身存在路由环路，被导入的流量同样无法完成公网转发，直接导致本地设备断网

拆分现有单段子网，修正NAT Gateway所在子网的路由逻辑：
- 保留当前10.0.0.0/24子网作为公有子网，将其关联的路由表修改为两条条目：
  - 10.0.0.0/24 → local（VPC默认本地路由，无需修改）
  - 0.0.0.0/0 → igw-xxxx（指向已附加的Internet Gateway）
- 新建单独的私有子网，比如使用10.0.1.0/24作为私有子网，将EC2实例从现有10.0.0.0/24子网迁移（可通过创建AMI重新启动实例的方式迁移，避免改动现有IP关联的安全规则）
为私有子网创建专属路由表，关联到新建的10.0.1.0/24私有子网，配置路由条目：
- 10.0.0.0/16 → local
- 0.0.0.0/0 → nat-xxxx（指向绑定了弹性公网IP的NAT Gateway）
调整Client VPN Endpoint的路由配置：
- 给Client VPN的关联路由表添加VPC内网段的路由条目（比如10.0.0.0/8覆盖所有VPC内网地址）
- 不要给Client VPN添加0.0.0.0/0的默认路由，启用分流隧道模式，保证本地设备的互联网流量不会被导入VPC
连通性验证：
- 从EC2实例执行ping 8.8.8.8、curl amazon.com验证公网访问能力
- 从连入Client VPN的本地设备执行ICMP测试，确认EC2实例的私有IP连通性
- 重新运行Reachability Analyzer，选择源为私有子网内的EC2，目标为任意公网IP，应返回可连通的结果

确认NAT Gateway绑定的弹性公网IP没有被关联到其他资源，且弹性IP状态为已分配、已关联
确认Network ACL的规则方向正确：入站允许从NAT Gateway返回的已建立流量，出站允许发起的公网流量，你当前配置的全放行规则本身没有问题，但要避免规则方向写反
不要将NAT Gateway部署在指向自身的路由子网内，这是AWS新用户最常踩的路由环路坑，官方文档的多子网架构示例默认大家会拆分公有/私有子网，单子网测试场景下很容易被忽略

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