为什么我们在 VPC 中需要私有子网? [英] Why do we need private subnet in VPC?

问题描述

AWS VPC 配置中有 4 种场景.但是让我们看看这两个:

There are 4 scenarios in AWS VPC configure. But let's look at these two:

• 场景 1:1 个公共子网.
• 场景 2:1 个公共子网和 1 个私有子网.

由于在公共子网中启动的任何实例都没有 EIP(除非已分配)，因此它已经无法从 Internet 寻址.然后:

Since any instance launched in public subnet does not have EIP (unless it's assigned), it is already not addressable from the Internet. Then:

• 为什么需要私有子网?
• 私有子网和公共子网之间究竟有什么区别?

推荐答案

更新: 2015 年 12 月下旬，AWS 宣布一项新功能，VPC 的托管 NAT 网关.此可选服务为私有子网中的 VPC 实例提供了一种访问 Internet 的替代机制，以前，常见的解决方案是 VPC 内公共子网上的 EC2 实例，充当NAT 实例"，提供网络地址转换(从技术上讲，端口地址转换)用于其他私有子网中的实例，允许这些机器使用 NAT 实例的公共 IP 地址进行出站 Internet 访问.

Update: in late December, 2015, AWS announced a new feature, a Managed NAT Gateway for VPC. This optional service provides an alternative mechanism for VPC instances in a private subnet to access the Internet, where previously, the common solution was an EC2 instance on a public subnet within the VPC, functioning as a "NAT instance," providing network address translation (technically, port address translation) for instances in other, private subnets, allowing those machines to use the NAT instance's public IP address for their outbound Internet access.

新的托管 NAT 服务并没有从根本上改变以下信息的适用性，但在接下来的内容中没有解决这个选项.NAT 实例仍可按所述使用，或者可以提供托管 NAT 网关服务.即将推出此答案的扩展版本，其中包含有关 NAT 网关及其与 NAT 实例的比较的更多信息，因为这些都与 VPC 中的私有/公共子网范例相关.

The new managed NAT service does not fundamentally change the applicability of the following information, but this option is not addressed in the content that follows. A NAT instance can still be used as described, or the Managed NAT Gateway service can be provisioned, instead. An expanded version of this answer integrating more information about NAT Gateway and how it compares to a NAT instance will be forthcoming, as these are both relevant to the private/public subnet paradigm in VPC.

请注意，互联网网关和NAT网关是两个不同的功能.所有具有 Internet 访问权限的 VPC 配置都将具有一个 Internet 网关虚拟对象.

Note that the Internet Gateway and NAT Gateway are two different features. All VPC configurations with Internet access will have an Internet Gateway virtual object.

要了解 Amazon VPC 中私有"和公共"子网之间的区别，需要了解 IP 路由和网络地址转换 (NAT) 的一般工作方式，以及它们如何在 VPC 中具体实施.

To understand the distinction between "private" and "public" subnets in Amazon VPC requires an understanding of how IP routing and network address translation (NAT) work in general, and how it they are specifically implemented in VPC.

VPC 中公共子网和私有子网之间的核心区别是由该子网在 VPC 路由表中的默认路由定义的.

反过来，此配置决定了在特定子网上的实例上使用或不使用公共 IP 地址的有效性.

This configuration, in turn, dictates the validity of using, or not using, public IP addresses on instances on that particular subnet.

每个子网只有一个默认路由，它只能是以下两种情况之一:

Each subnet has exactly one default route, which can be only one of two things:

• VPC 的互联网网关"对象，如果是公共"子网，或
• NAT 设备——即，NAT 网关或 EC2 实例，在私有"子网的情况下，执行NAT 实例"角色.

对于没有公共 IP 地址的实例，Internet 网关不会进行任何网络地址转换，因此没有公共 IP 地址的实例无法向外连接到 Internet -- 执行诸如下载软件更新之类的操作，或访问其他 AWS 资源，如 S3¹ 和 SQS——如果其 VPC 子网上的默认路由是 Internet 网关对象.因此，如果您是公共"子网上的一个实例，那么您需要一个公共 IP 地址，以便执行服务器通常需要做的大量事情.

The Internet Gateway does not do any network address translation for instances without public IP addresses so an instance without a public IP address cannot connect outward to the Internet -- to do things like downloading software updates, or accessing other AWS resources like S3¹ and SQS -- if the default route on its VPC subnet is the Internet Gateway object. So, if you are an instance on a "public" subnet, then you need a public IP address in order to do a significant number of things that servers commonly need to do.

对于只有私有 IP 地址的实例，还有另一种出站访问 Internet 的方式.这是网络地址转换的地方²和一个 NAT 实例进来.

For instances with only a private IP address, there's an alternate way of outbound access to the Internet. This is where Network Address Translation² and a NAT instance come in.

私有子网上的机器可以访问互联网，因为私有子网上的默认路由不是 VPC互联网网关"对象——它是一个配置为 NAT 实例的 EC2 实例.

The machines on a private subnet can access the Internet because the default route on a private subnet is not the VPC "Internet Gateway" object -- it is an EC2 instance configured as a NAT instance.

NAT 实例是公共子网上的实例，具有公共 IP 和特定配置.有一些预先构建的 AMI 可以执行此操作，您也可以构建自己的 AMI.

A NAT instance is an instance on a public subnet with a public IP, and specific configuration. There are AMIs that are pre-built to do this, or your can build your own.

当私有地址机器向外发送流量时，流量由VPC发送到NAT实例，NAT实例将数据包上的源IP地址(私有机器的私有IP地址)替换为自己的公网IP地址，将流量发送到 Internet，接受响应数据包，并将它们转发回原始机器的私有地址.(它也可能重写源端口，在任何情况下，它都会记住映射，因此它知道哪个内部机器应该接收响应数据包).NAT 实例不允许任何意外"入站流量到达私有实例，除非它经过专门配置.

When the private-addressed machines send traffic outward, the traffic is sent, by VPC, to the NAT instance, which replaces the source IP address on the packet (the private machine's private IP address) with its own public IP address, sends the traffic out to the Internet, accepts the response packets, and forwards them back to the private address of the originating machine. (It may also rewrite the source port, and in any case, it remembers the mappings so it knows which internal machine should receive the response packets). A NAT instance does not allow any "unexpected" inbound traffic to reach the private instances, unless it's been specifically configured to do so.

因此，当从私有子网访问外部 Internet 资源时，流量会遍历 NAT 实例，并且在目的地看来是源自 NAT 实例的公共 IP 地址......因此响应流量返回到NAT 实例.分配给 NAT 实例的安全组和分配给私有实例的安全组都不需要配置为允许"此响应流量，因为安全组是有状态的.他们意识到响应流量与内部发起的会话相关，因此它被自动允许.意外流量当然会被拒绝，除非安全组配置为允许.

Thus, when accessing external Internet resource from a private subnet, the traffic traverses the NAT instance, and appears to the destination to have originated from the public IP address of the NAT instance... so the response traffic comes back to the NAT instance. Neither the security group assigned to the NAT instance nor the security group assigned to the private instance need to be configured to "allow" this response traffic, because security groups are stateful. They realize the response traffic is correlated to sessions originated internally, so it is automatically allowed. Unexpected traffic is, of course, denied unless the security group is configured to permit it.

与传统 IP 路由不同，默认网关位于同一子网中，它在 VPC 中的工作方式不同:任何给定私有子网的 NAT 实例始终位于不同子网中，而其他子网始终是公共子网子网，因为 NAT 实例需要有一个公有的外部 IP，它的默认网关必须是 VPC 的Internet 网关"对象.

Unlike conventional IP routing, where your default gateway is on your same subnet, the way it works in VPC is different: the NAT instance for any given private subnet is always on a different subnet, and that other subnet is always a public subnet, because the NAT instance needs to have a public external IP, and its default gateway has to be the VPC "Internet Gateway" object.

同样...您不能在私有子网上部署具有公共 IP 的实例.它不起作用，因为私有子网上的默认路由(根据定义)是一个 NAT 实例(它对流量执行 NAT)，而不是 Internet 网关对象(它没有).来自 Internet 的入站流量将访问实例的公共 IP，但回复将尝试通过 NAT 实例向外路由，这将丢弃流量(因为它将由对它不知道的连接的回复组成，因此它们'将被视为无效)或将重写回复流量以使用其自己的公共 IP 地址，这将不起作用，因为外部源不会接受来自 IP 地址的回复，而不是他们试图与之发起通信的 IP 地址.

Similarly... you cannot deploy an instance with a public IP on a private subnet. It doesn't work, because the default route on a private subnet is (by definition) a NAT instance (which performs NAT on the traffic), and not the Internet Gateway object (which doesn't). Inbound traffic from the Internet would hit the public IP of the instance, but the replies would try to route outward through the NAT instance, which would either drop the traffic (since it would be composed of replies to connections it's not aware of, so they'd be deemed invalid) or would rewrite the reply traffic to use its own public IP address, which wouldn't work since the external origin would not accept replies that came from an IP address other than the one they were trying to initiate communications with.

从本质上讲，私人"和公共"名称实际上并不是关于互联网的可访问性或不可访问性.它们是关于将分配给该子网上的实例的地址类型，这是相关的，因为需要转换或避免转换这些 IP 地址以进行 Internet 交互.

In essence, then, the "private" and "public" designations are not really about accessibility or inaccessibility from the Internet. They are about the kinds of addresses that will be assigned to the instances on that subnet, which is relevant because of the need to translate -- or avoid translating -- those IP addresses for Internet interactions.

由于 VPC 具有从所有 VPC 子网到所有其他 VPC 子网的隐式路由，因此默认路由在内部 VPC 流量中不起作用.具有私有 IP 地址的实例将从"其私有 IP 地址连接到 VPC 中的其他私有 IP 地址，而不是从"其公共 IP 地址(如果有的话)……只要目标地址是另一个私有地址VPC 内.

Since VPC has implicit routes from all VPC subnets to all other VPC subnets, the default route does not play a role in internal VPC traffic. Instances with private IP addresses will connect to other private IP addresses in the VPC "from" their private IP address, not "from" their public IP address (if they have one)... as long as the destination address is another private address within the VPC.

如果您的具有私有 IP 地址的实例在任何情况下都不需要发起出站 Internet 流量，那么它们在技术上可以部署在公共"子网上，并且仍然无法从 Internet 访问……但在这种情况下配置，它们不可能向 Internet 发起出站流量，其中包括与其他 AWS 基础设施服务的连接，同样，如 S3¹ 或 SQS.

If your instances with private IP addresses never, under any circumstances, need to originate outbound Internet traffic, then they technically could be deployed on a "public" subnet and would still still be inaccessible from the Internet... but under such a configuration, it is impossible for them to originate outbound traffic towards the Internet, which includes connections with other AWS infrastructure services, again, like S3¹ or SQS.

^{1.关于 S3，特别是说总是需要互联网访问是一种过于简单化的说法，随着 VPC 的功能不断增长和演变，它的范围可能会随着时间的推移而扩大并扩展到其他 AWS 服务.有一个相对较新的概念，称为 VPC Endpoint 允许您的实例，包括那些只有私有 IP 地址的，从 VPC 内的选定子网直接访问 S3，不接触互联网"，也不使用 NAT 实例或 NAT 网关，但这确实需要额外的配置，并且只能用于访问内部的存储桶与您的 VPC 相同的 AWS 区域.默认情况下，S3——在撰写本文时，是唯一公开了创建 VPC 端点功能的服务——只能通过 Internet 从 VPC 内部访问.当您创建 VPC 终端节点时，这会创建一个前缀列表 (pl-xxxxxxxx)，您可以在 VPC 路由表中使用该列表将绑定到该特定 AWS 服务的流量通过虚拟"VPC 端点"对象.它还解决了针对特定实例限制对 S3 的出站访问的问题，因为前缀列表可用于出站安全组，而不是目标 IP 地址或块——并且 S3 VPC 端点可以服从额外的策略声明，根据需要限制从内部访问存储桶.}

^{1. Regarding S3, specifically, to say that Internet access is always required is an oversimplification that will likely grow in scope over time and spread to other AWS services, as the capabilities of VPC continue to grow and evolve. There is a relatively new concept called a VPC Endpoint that allows your instances, including those with only private IP addresses, to directly access S3 from selected subnets within the VPC, without touching "the Internet," and without using a NAT instance or NAT gateway, but this does require additional configuration, and is only usable to access buckets within the same AWS region as your VPC. By default, S3 -- which is, as of this writing, the only service that has exposed the capability of creating VPC endpoints -- is only accessible from inside VPC via the Internet. When you create a VPC endpoint, this creates a prefix list (pl-xxxxxxxx) that you can use in your VPC route tables to send traffic bound for that particular AWS service direct to the service via the virtual "VPC Endpoint" object. It also solves a problem of restricting outbound access to S3 for particular instance, because the prefix list can be used in outbound security groups, in place of a destination IP address or block -- and an S3 VPC endpoint can be subject to additional policy statements, restricting bucket access from inside, as desired.}

^{2.如文档中所述，此处实际讨论的是端口和网络地址转换.虽然在技术上有点不精确，但将组合操作称为NAT"是很常见的.这有点类似于我们中的许多人在实际表示TLS"时倾向于说SSL"的方式.我们知道我们在说什么，但我们没有使用最正确的词来描述它."注意我们在本文档中使用术语 NAT 来遵循常见的 IT 实践，尽管 NAT 设备的实际作用是地址转换和端口地址转换 (PAT)."}

这篇关于为什么我们在 VPC 中需要私有子网?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！