诊断 EC2 实例连接问题：安全组与网络 ACL

当您的 EC2 实例正在运行，但 SSH、RDP 或应用流量超时时，问题通常出在实例周围的网络路径上。诊断 EC2 连接问题，请先检查路由表，然后检查子网网络 ACL，最后检查实例安全组。

理解这些控制机制的层级和功能至关重要。安全组充当实例级别的有状态防火墙，而 NACL 充当子网级别的无状态防火墙。这两个组件中的任何一个配置错误，或者路由路径不正确，都会立即阻止预期的流量，导致令人沮丧的连接超时。

EC2 连接控制的三大支柱

在深入具体配置之前，理解每个组件在通往 EC2 实例的流量路径中所扮演的角色至关重要：

路由表： 根据目标 IP 地址决定网络流量的去向。如果发往互联网或客户端 IP 的流量无法到达正确的子网网关，连接将失败。
网络 ACL (NACL)： 将规则应用于整个子网。它们是无状态的，意味着入站和出站流量都必须被显式允许。它们按顺序处理规则，从编号最小的规则开始，到第一个匹配的规则停止。
安全组 (SG)： 将规则直接应用于 EC2 实例的弹性网络接口 (ENI)。它们是有状态的，意味着如果您允许入站流量，则出站返回流量会自动被允许。

第一个诊断检查应始终确认存在一条路径，使流量能够到达 EC2 实例所在的子网。

对于可从公共互联网访问的实例（例如，通过 SSH/RDP）：

目标： 确保包含公共实例的子网有一条指向互联网网关 (IGW) 的默认路由。
操作： 导航到 VPC 控制台，选择路由表，并检查与您的实例子网关联的路由表。查找类似以下条目：
```
目标：0.0.0.0/0 | 目标：igw-xxxxxxxx
```

虽然安全组是有状态的，但验证出站路径对于返回流量或实例发起连接到外部服务的情况至关重要。

操作： 如果您的实例位于私有子网中，请确保它有一条指向NAT 网关或NAT 实例的路由以访问互联网。如果它在公共子网中，它应将 0.0.0.0/0 路由到 IGW。

提示： 同一 VPC 内子网之间的流量通常使用隐式的 local 路由。如果该流量失败，请在归咎于路由表之前，检查安全组、NACL、主机防火墙以及目标是否允许 ICMP。

NACL 经常被忽视，因为它们在子网级别运行并且是无状态的。一个常见的错误是允许入站流量，但忘记显式允许返回的出站流量。

对于入站连接尝试（例如，端口 22 上的 SSH）：

这是大多数 NACL 连接问题发生的地方。

入站 SSH 访问的示例 NACL 规则：

入站规则：

规则编号	类型	协议	端口范围	源	允许/拒绝
100	SSH	TCP	22	您的客户端 IP/CIDR	允许
*	*	*	*	*	拒绝（默认）

出站规则：

规则编号	类型	协议	端口范围	目标	允许/拒绝
100	自定义 TCP	TCP	1024-65535	您的客户端 IP/CIDR	允许
*	*	*	*	*	拒绝（默认）

警告： NACL 按数字顺序评估规则。如果规则 90 是 拒绝所有，则您后续的规则 100 允许 SSH 将永远不会被命中。确保您的显式允许规则的编号低于任何广泛的拒绝规则，或者依赖最终的隐式拒绝所有规则。

安全组是最后一道防线，直接应用于实例。它们更容易管理，因为它们是有状态的。

验证附加到 EC2 实例的安全组是否允许来自预期源的所需端口上的流量：

由于安全组是有状态的，出站规则通常配置为允许所有流量（所有端口的 0.0.0.0/0）。如果您自定义了出站规则，请确保它们允许响应返回客户端的临时端口范围。

最佳实践： 除非有严格的安全要求，否则将安全组的出站规则保留为默认值：允许所有流量到所有目标。这可以显著简化故障排除，因为您可以隔离 NACL 或路由表问题。

当 EC2 连接失败时，请按以下诊断顺序操作：

通过从广泛的网络层（路由）系统地向下到子网级别（NACL），最后到实例级别（安全组），您可以快速隔离阻塞机制是无状态过滤、有状态过滤还是路由故障。