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

通过系统诊断三个核心网络控制(安全组、网络 ACL 和 VPC 路由表)来掌握 EC2 连接故障排除。了解有状态安全组与无状态网络 ACL 之间的关键区别,如何检查临时端口规则,并确保正确的路由路径,使您能够快速解决常见的连接故障。

39 浏览量

诊断 EC2 实例连接问题:安全组和网络 ACL

连接 Amazon Elastic Compute Cloud (EC2) 实例是一项基本操作,然而,连接失败是 AWS 用户最常见的故障排除场景之一。当实例似乎运行正常但无法访问时(无论是通过 SSH、RDP 还是应用程序流量),问题几乎总是出在周围的网络安全层。这份综合指南概述了诊断和解决连接问题的系统方法,重点关注三个关键网络控制点:安全组 (SGs)网络访问控制列表 (NACLs)VPC 路由表

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

EC2 连接控制的三大支柱

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

  1. 路由表: 根据其目标 IP 地址确定网络流量的去向。如果发往互联网或您的客户端 IP 的流量无法到达正确的子网网关,连接将失败。
  2. 网络 ACL (NACLs): 将规则应用于整个子网。它们是无状态的,这意味着入站和出站流量都必须明确允许。它们按顺序处理规则,从编号最低的规则到最高的规则,并在第一个匹配项处停止。
  3. 安全组 (SGs): 将规则直接应用于 EC2 实例的弹性网络接口 (ENI)。它们是有状态的,这意味着如果您允许入站流量,则返回的出站流量将自动被允许。

步骤 1:验证 VPC 路由表

第一个诊断检查应始终确认流量存在一条路径,甚至可以到达 EC2 实例所在的子网。

检查入站路由

对于可从公共互联网访问的实例(例如,通过 SSH/RDP):

  • 目标: 确保包含实例的子网具有通往互联网网关 (IGW) 的路由,用于源自 0.0.0.0/0(或您的特定客户端 IP 范围)的流量。
  • 操作: 导航到 VPC 控制台,选择路由表,并检查与您的实例子网关联的路由表。查找如下条目:
    Destination: 0.0.0.0/0 | Target: igw-xxxxxxxx

检查出站路由(针对有状态问题)

尽管安全组是有状态的,但验证出站路径至关重要,特别是对于返回流量或发起与外部服务连接的实例。

  • 操作: 如果您的实例位于私有子网中,请确保它具有通往 NAT 网关NAT 实例的路由以访问互联网。如果它位于公共子网中,它应该将 0.0.0.0/0 路由到 IGW。

提示: 如果您无法从同一 VPC 内的不同子网 ping 通实例,问题几乎肯定是一个配置错误的路由表将流量导向错误的本地网关或 VPC 对等连接。

步骤 2:检查网络 ACL(子网级别)

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

入站规则验证

对于入站连接尝试(例如,端口 22 上的 SSH):

  1. 识别与实例子网关联的 NACL。
  2. 检查入站规则
  3. 确保存在一条允许您正在使用的特定端口和协议的规则(例如,规则 100:类型:SSH (22),协议:TCP,来源:0.0.0.0/0)。

出站规则验证(无状态陷阱)

大多数 NACL 连接问题都发生在此处。

  1. 检查出站规则
  2. 如果您允许入站 SSH(端口 22),实例需要将流量发送回您的客户端,使用高端口(临时端口)范围,通常是 1024-65535
  3. 操作: 确保出站规则明确允许流量到达相关的目标端口范围(如果客户端发起连接,通常是 1024-65535)。

入站 SSH 访问的 NACL 规则集示例:

规则编号 类型 协议 端口范围 来源 允许/拒绝
100 SSH TCP 22 0.0.0.0/0 允许
110 自定义 TCP TCP 1024-65535 0.0.0.0/0 允许
* * * * * 拒绝 (默认)

警告: NACL 按数字顺序评估规则。如果规则 90 是 DENY ALL (拒绝所有),您的后续规则 100 ALLOW SSH (允许 SSH) 将永远不会生效。确保您的明确允许规则的编号低于任何广泛的拒绝规则,或者依赖于最终的隐式拒绝所有规则。

步骤 3:审计安全组(实例级别)

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

入站规则检查

验证附加到 EC2 实例的安全组是否允许流量从预期来源通过所需端口:

  • 对于 SSH (Linux): 允许从您的公共 IP 或 0.0.0.0/0(如果需要)传入TCP 端口 22 的入站规则。
  • 对于 RDP (Windows): 允许从您的公共 IP 或 0.0.0.0/0 传入TCP 端口 3389 的入站规则。
  • 对于 Web 流量: 允许从 0.0.0.0/0 传入TCP 端口 80 和/或 443 的入站规则。

出站规则检查(通常为默认设置)

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

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

总结:连接流检查清单

当 EC2 连接失败时,请遵循以下诊断顺序:

  1. 路由表检查: 流量路径(入站和出站)是否可以到达正确的子网网关(IGW/VPC 对等连接/NAT)?
  2. NACL 检查 (无状态): 流量是否在特定入站端口上明确允许,并且返回流量(通常是高临时端口)是否明确允许出站?
  3. 安全组检查 (有状态): 流量是否在特定入站端口上明确允许?(出站通常应开放)。

通过系统地从广泛的网络层(路由)到子网级别(NACLs),最后到实例级别(SGs)进行排查,您可以快速隔离阻止机制是无状态过滤、有状态过滤还是路由失败。