2. VPC网络基础与诊断对象建模
在开始排查任何 AWS 网络问题之前，必须先回答一个更基础的问题：一个数据包从源到目的地，究竟会经过哪些对象？如果对 VPC 内部组成与交互关系没有清晰模型，故障诊断就会退化为“到处乱查”。本节的目标是把 VPC 拆解成可诊断的对象集合，并建立两条主线：一条是网络路径模型（包怎么走），另一条是故障域模型（问题可能出在哪一层）。
一、VPC 的组成对象与职责边界
VPC 本身是一个逻辑隔离的虚拟网络，它由若干可独立配置的对象共同构成。理解每个对象的职责，是定位故障的前提。
- VPC：定义地址空间（CIDR，例如 10.0.0.0/16），是所有子网、路由表、网关的容器，也是隔离边界。
- 子网（Subnet）：VPC CIDR 的细分（如 10.0.1.0/24），绑定在某个可用区。子网决定资源的 IP 归属，并决定它是公有还是私有——但注意，“公有/私有”不是子网自身的属性，而是由路由表决定的。
- 路由表（Route Table）：决定子网内流量“下一跳去哪”。每个子网关联一张路由表，路由表包含本地路由（local）、网关路由、对等连接路由等。
- 网关：Internet Gateway（IGW）提供公网双向访问；NAT Gateway 让私有子网单向访问公网；Virtual Private Gateway / Transit Gateway 连接混合云或多 VPC。
- 安全组（Security Group）：作用于弹性网卡（ENI）的有状态虚拟防火墙，只支持允许规则，返回流量自动放行。
- 网络 ACL（NACL）：作用于子网的无状态防火墙，支持允许和拒绝规则，入站和出站需分别显式放行。
这里有一个诊断中极易混淆的关键点：安全组是有状态的，NACL 是无状态的。这意味着如果 NACL 只放行了入站 443 而没有放行出站的高位端口（1024–65535），TCP 三次握手会失败，而安全组不会出现这种问题。排查时若发现“安全组看起来没问题但连接仍不通”，应优先怀疑 NACL 的出站规则。
二、网络路径模型：一个包要经过哪些关卡
把上述对象串起来，就得到一条完整的判定链。以“公网客户端访问 EC2 上的 HTTPS 服务”为例，数据包依次经过：
- IGW 进入 VPC；
- 命中子网关联的路由表，确认目标子网可达；
- 进入子网边界时，先经过 NACL 入站规则；
- 到达 ENI 时，经过 安全组入站规则；
- 到达实例；
- 返回流量按相反顺序：安全组自动放行（有状态），但 NACL 出站规则必须显式允许。
这条链上的每一环都是一个独立的故障域。诊断的核心方法就是：沿路径逐跳验证，而不是同时怀疑所有对象。
三、故障域模型：把“可能出错的地方”结构化
路径模型回答“包怎么走”，故障域模型回答“哪里可能断”。两者结合，才能形成可操作的诊断策略。基于上面的路径，可以把 VPC 网络故障划分为五个层次：
| 故障域 | 典型症状 | 首选验证手段 |
|---|---|---|
| 路由层 | 目标不可达、超时 | 检查子网关联路由表、目标 CIDR 匹配 |
| 网关层 | 公网不通、私有子网无法出网 | 确认 IGW 已附加、NAT 位于公有子网且有 EIP |
| NACL 层 | 入站通但返回失败、间歇性丢包 | 核对入站与出站规则、临时端口范围 |
| 安全组层 | 连接被拒绝、特定端口不通 | 检查入站规则源、协议、端口 |
| 实例层 | 端口未监听、进程异常 | 实例内 ss/netstat、服务日志 |
这个分层模型的价值在于：它把“网络不通”这个模糊问题，转化为一组可独立验证的假设。例如，如果从公网访问超时，但同子网内实例互访正常，那么路由层和 NACL 层大概率没问题，应重点检查 IGW 附加状态和安全组入站规则。
四、用 Reachability Analyzer 验证路径模型
AWS 提供的 Reachability Analyzer 正是基于上述路径模型工作的。它接收源（如 ENI、IGW）和目标（如 ENI、IP），自动沿路径逐跳分析，并明确指出在哪一跳被阻断。例如，一次典型分析可能返回：
Path: igw-0abc123 → subnet-0def456 → eni-0ghi789
Status: NOT REACHABLE
Blocking component: sg-0jkl012 (Security Group)
Reason: Inbound rule does not allow TCP 443 from 0.0.0.0/0这类输出直接对应故障域模型中的某一层，极大缩短了定位时间。但要注意：Reachability Analyzer 只分析配置层面的可达性，它不会检测实例内部服务是否监听，也不会检测操作系统防火墙。因此它验证的是“路径是否被 AWS 配置阻断”，而不是“服务是否真的可用”。
五、常见误区与诊断纪律
- 把子网当成防火墙：子网本身不过滤流量，过滤发生在 NACL 和安全组。
- 忽略 NACL 的无状态性：只放行入站而忘记出站临时端口，是返回流量失败的常见原因。
- 同时修改多个对象：一次只改一个变量，否则无法判断是哪个改动生效。
- 只看安全组不看路由：安全组允许不代表路由可达，两者是“与”关系。