我正在学习 AWS 课程。我想做的是设置一个带有两个 Linux 服务器的 VPC。我已经为 VPC 设置了两个子网。我在每个子网中都放置了一台服务器。想法是，一个子网是公共的，另一个是私有的。
我创建了两个网络 ACL，并将每个子网与其关联。
我可以通过 SSH 从我的机器连接到公共子网中的服务器。当我尝试通过 SSH 从我的机器连接到我的私有子网中的服务器时，我遇到了连接超时。
我不确定我需要在两个网络 ACL 中设置哪些规则才能使 SSH 正常工作。有人能帮忙吗？鉴于我正在学习，我希望能够解释一下为什么要设置规则，而不仅仅是规则应该是什么。
我有一个名为 MyVPC 的 VPC，其 CIDR 为 10.0.0.0/16
我的第一个子网名为 MyVPCSub1 CIDR 为 10.0.1.0/24
我的第二个子网名为 MyVPCSub2 CIDR 为 10.0.2.0/24
我有一个名为 MyInternetRoute 的路由表，与 MyVPCSub1 关联的路由如下：
|Dest |Targ |
|10.0.0.0/16 |local |
|0.0.0.0/0 |igw |
我有一个名为 MyPrivate 的路由表，与 MyVPCSub2 路由相关联，路由如下：
|Dest |Targ |
|10.0.0.0/16 |local |
我有一个名为 MyWeb 的网络 ACL，与 MyVPCSub1 关联，其规则如下：
入站：
| # | Type | Protocol | Ports | Source | A/D
| 99 | HTTP | TCP | 80 | {My IP}/32 | D
| 100 | HTTP | TCP | 80 | 0.0.0.0/0 | A
| 200 | HTTPS| TCP | 443 | 0.0.0.0/0 | A
| 300 | SSH | TCP | 22 | {My IP}/32 | A
| * | ALL | ALL | ALL | 0.0.0.0/0 | D
出站：
| # | Type | Protocol | Ports | Source | A/D
| 50 | ALL | ALL | ALL | 0.0.0.0/0 | A
| 100 | HTTP | TCP | 80 | 0.0.0.0/0 | A
| 200 | HTTPS | TCP | 443 | 0.0.0.0/0 | A
| 300 | Custom | TCP | 1024-65535 | 0.0.0.0/32 | A
| * | ALL | ALL | ALL | 0.0.0.0/0 | D
我有一个名为 MyPrivate 的网络 ACL，与 MyVPCSub2 关联，其规则如下：
入站：
| # | Type | Protocol | Ports | Source | A/D
| 100 | ALL | ALL | ALL | 0.0.0.0/0 | A
| * | ALL | ALL | ALL | 0.0.0.0/0 | D
出站：
| # | Type | Protocol | Ports | Source | A/D
| 100 | ALL | ALL | ALL | 0.0.0.0/0 | A
| * | ALL | ALL | ALL | 0.0.0.0/0 | D
答案1
首先要定义一些术语的含义。
NACLS - 网络访问控制列表，是一种状态较少的在子网级别应用的数据包过滤器。“无状态”方面很重要，这意味着您需要明确进入和离开子网的所有流量。例如，使用“全状态”规则方法（这是 AWS 中的安全组所应用的），您只需为 SSH 指定 TCP/22 的入站流量，它就会自动允许出站流量。使用 NACLS 则不是这种情况，您需要在每个方向指定一条规则以允许流量通过。
安全组织 - 这些是国家团体满的可以应用于 VPC 中一个或多个实例的规则。请注意，它们适用于实例级别。安全组可以与传统的全状态防火墙进行比较，但由于它应用于单个实例级别，因此您可以将实例彼此隔离，即使在同一子网中也是如此。而且由于它们是全状态的，如果您想允许流量进入服务器（例如 SSH 的 TCP/22），您不必担心创建相应的出站规则，平台会自动处理，因此它们更容易管理 - 这也意味着出错的可能性更小。
有一张很好的表格对这两者进行了比较：VPC 安全性比较
该页面上还有一个漂亮的图表，显示了根据流向对流量应用的顺序...请查看。
那么就子网而言，我们有：
公共子网 - 用 AWS 术语来说，这只是一个附加了路由表的子网，该路由表通过附加的 Internet 网关具有 0.0.0.0/0 路由
私有子网-这是相反的，即它没有通过连接的 Internet 网关获得 0.0.0.0/0 路由。请注意，它仍然可以通过您环境中的 NAT 网关或类似代理获得 0.0.0.0/0 路由，只是不是直接的。
问题是，当您拥有 NACLS 和安全组时，您会使用哪一个。AWS 将 NACL 描述为“VPC 的可选安全层”。而且，一般来说，安全组确实足够了，它们更灵活，并提供相同的保护。但根据我的经验，有些典型情况我会使用 NACLS：
- 已知不良行为者的黑洞 - 如果您受到来自特定 IP 范围的攻击，一个简单的方法就是添加一个 NACL 来完全阻止 IP / 子网源。
- 作为将控制权委托给团队的一种方式 - 安全团队应用广泛的 NACL 配置（例如，仅允许来自受信任的公司网络的流量），然后允许操作/开发团队配置自己的安全组规则。这样，即使工程师试图将其实例上的安全组开放到互联网进行测试，NACL 也会阻止它。您可以使用 IAM 来限制谁可以修改 NACL，但授予团队访问权限以控制其他所有内容，它可以很好地防止大型环境中出现配置错误。
AWS 还针对此处提供的多种配置场景提供了一些指导：为您的 VPC 推荐的网络 ACL 规则
不过，我的指导意见是，安全组通常提供适当的保护，更易于理解和配置，并且在应用方面更灵活、更细粒度。NACL 确实为您提供了额外的支持，以应对人为错误或更高级的配置，但对于基本用途，它们通常不使用。因此，我猜想为什么 AWS 将它们称为“可选”。
我会保留 NACL 的默认配置（允许所有进出流量），而暂时专注于安全组，因为使用 NACL 作为第二层只会增加额外的复杂性，而这在您的场景中可能不是必需的。从学习的角度来看，最好知道它们存在、它们是无状态的、它们适用于子网级别、它们在路由决策之后、在进入子网的流量的安全组之前应用。
关于你的具体情况，因为你正在使用 NACL，所以你需要记住它们是状态的较少的。因此，所有进出子网的流量都需要考虑 - 这是安全组更容易使用的主要原因。因此，对于您的情况，您需要：
- 从你的 IP 通过 TCP/22 进入你的公共服务器的流量 - 是的 - 规则 #300 入站
- 从您的公共服务器的高端口返回流量以返回 SSH 流量 - 是的 - 规则 #50 出站（但不是规则 #300 - 见下文）
- 从您的公有子网出站到您的私有子网的流量通过 TCP/22 传输 - 是的 - 规则 #50 出站
- 来自公有子网的私有子网入站流量 - 是的 - 规则 #100 入站
- 将流量从您的私有服务器返回到私有子网上的公共服务器 - 是的 - 规则 #100 出站
- 将流量从您的私人服务器返回到民众子网 - 啊 - 不，没有规则允许高端口（ssh 客户端在公共服务器上用于启动与私有端口的连接的临时端口）从私有服务器返回。
您需要在出站公共子网 ACL 上添加一条规则（例如规则 #300）（但请注意，源 IP 的格式略有错误 - 见下文），但在入站时，使用私有子网的源。然后假设您的安全组配置正确，那么您应该一切顺利。
希望有所帮助。
补充一下 - 根据另一个答案 - 公共子网出站规则集上的规则 #300 格式错误。它应该是 0.0.0.0/0 而不是 0.0.0.0/32，但是就您而言，您没有命中该规则，因为规则 #50 先命中，并且无论如何都允许所有流量 - 因此，虽然它不起作用，但它实际上并没有导致您的问题。
答案2
ACL 是无状态的。
您的“公共”子网可能阻止了来自私有子网的 SSH 连接的返回路径。您还需要为入站端的所有端口设置与出站端相同的规则，尽管您可以将其限制在子网范围 10.0.2.0/24 内。
编辑后添加：此外，0.0.0.0/32 的出站规则是错误的。除非您的 IP 正好是 0.0.0.0，否则它将不起作用。