AWS为用户提供了一个虚拟的数据中心,用户可以将EC2 instance、RDS(Amazon Relational Database Service)、EMR Clusters等资源部署到这个虚拟的数据中心。不仅如此,这些资源还需要同internet进行通讯。
Amazon VPC 允许用户在 Amazon Web Services (AWS) 云中预置出一个逻辑隔离的部分,让用户在自己定义的虚拟网络中启动 AWS 资源。用户可以完全掌控这个虚拟网络环境,包括选择自己的 IP 地址范围、创建子网以及配置路由表和网络网关。
VPC 概念和基础知识
FundamentalIP 地址范围
根据RFC 1918,为了解决IPV4地址将要耗尽和ISP(Internet Service Provider)路由负荷即将过载的问题,人们提出了一个方案:一个ISP从地址注册组织获得一个地址块,然后根据每个客户的要求将块内的地址分配给客户。到许多客户的路由将会被聚合起来,对其他服务提供商呈现为一个单一的路由。
在企业内部使用IP的主机在企业内部无多义,而根据其在企业之间是否可能有多义的IP地址,可以将主机分为“私有的”和“公开的”。
因特网域名分配组织IANA组织(Internet Assigned Numbers Authority)保留了以下三个IP地址块用于私有网络。
10.0.0.0 - 10.255.255.255 (10/8比特前缀)
172.16.0.0 - 172.31.255.255 (172.16/12比特前缀)
192.168.0.0 - 192.168.255.255 (192.168/16比特前缀)
我们把第一块称为“24-比特块”,第二块称为“20-比特块”,第三块称为“16-比特块”注意(在前面的CIDR 记号中),第一块地址就是一个A类网络号,第二块地址是16个连续的B类网络号集合,第三块地址是256个连续的C类网络号集合。
假设,一个私有网络172.31.0.0/16,那么可以将这个私有网络的IP分为两部分,“172.32”是网络号,后16位是主机号。这个私有网络中的IP地址范围不会和Internet中的IP冲突。但是,要尽量避免和其他VPC中的私有IP地址范围产生冲突。
AWS推荐 /16 的IPv4 CIDR block(例如172.31.0.0/16)。
在VPC中建立subnet
Subnet为每个AZ建立一个subnet,这样,如果一个AZ的 subnet出现了问题,就不会影响到其他subnet:172.32.0.0/24,172.32.0.1/24,172.32.0.2/24。
Routing in a VPC
每个VPC都有一个route table,用于告诉系统如何对package进行路由。每个VPC都有一个default table,用于描述package如何在VPC内部进行通讯。用户可以为subnet创建不同的route table。
VPC 内部
通过default table完成
和Internet
和 internet 通讯的三要素:
- 某种形式的connection
- route to internet
- public address
从这张图上可以看到,VPC是如何实现三要素的。
首先,VPC 通过 internet gateway和internet建立连接。在图里是个“门”的形状,不过最新的图里面是这样的图标:
Internet Gateway
其次,VPC提供了两个route表。一个是igw_id,部署在共有subnet上,用与将目的地址不是本subnet的package发送到internet gateway,以实现同internet的通讯,该网关允许来自internet的请求;另一个route表是Nat_gw_id,部署在私有subnet上,指向NAT gateway,这是一张单向表,只允许从VPC内部访问internet的request(Outbound internet access)通过,不允许internet到VPC内部的request通过。这里为了让私有subnet能够和internet gateway 通讯,引入了一个新的网关,NAT gateway,其图标为:
NAT Gateway
最后,在launch上面的subnet的时候,为其制定了一个公有IP,即198.51.100.3。
网络安全
Security Group(SG)
首先有一点值得强调,Security Group是Stateful
的,如果一个入站(inbound)的traffic是被允许通过的,那么其对应的出站(outbound)的response也必然被允许通过。
具体来说,在下图中共有7个实例,其中4个被标成了黄色,表示需要和internet 通讯的web sever;另外3个被标成了蓝色,表示不需要和外部通讯的backend server。为黄色的实例建立Security Group MyWebServer
,为蓝色的实例建立Security Group MyBackendServer
,这样可以允许来自任意地址的traffic访问MyWebServer
内的实例,而只允许来自MyWebServer
访问MyBackendServer
内的实例。
Network Access Control List(NACL)
NACL也是VPC的一种安全机制,但是和Security Group 有一些不同之处:
Security Groups vs NACLFlow logs
在VPC中,日志有以下几种级别:
- instance level
- subnet level
- VPC level
如以下图所示,VPC将日志信息发送到AWS 的 Bucket 和 Cloud Watch 组件上,进一步用于可视化、问题排查、流量分析。这里,流量分析
仅涉及package的描述信息,而不涉及package的payload信息。
这里又多了三个新的图标:
Flow Logs
Bucket
CloudWatch
最后,让我们简单看一下VPC flow logs的格式:
Format
这条日志描述了以下信息:
接受从共有地址210.21.226.2的ssh入站package。
Connectivity Options for VPCs
VPC主要涉及两类连接:
- Connecting to other VPCs
-
Connecting to your on-premises networks
VPC conections
Connecting to other VPCs
VPC之间的连接有两种形式,VPC peering 和 Transit gateway。
- 首先,来看VPC peering。
VPC peering 是指在两个VPC之间建立连接,使得他们之间可以相互通讯,就好像在同一个私有网络内一样。VPC Peering 可以跨AWS region,也可以跨 AWS 账户。
VPC Peering 有其自身的局限性,它无法在两个重叠的CIDR block间建立连接。 而且它是1对1的关系,也就是说下图所示的关系是不可能的:
VPC peering必须以以下方式建立连接:
1:1 relationship
- 接下来,再看 Transit gateway
在Peering模式下,必须在任意两个VPC之间建立连接。如果有很多VPC,这项工作将变得异常繁重。这个时候,就需要引入Transit Gateway 模式了。
Transit gateway 将多个VPC之间的连接关系集中管理,且这些VPC可以来自不同的账户,尽管他们必须和Transit gateway在同一region。
Transit gateway- 比较 Peering 和 Transit gateway
Connect to on-premises networks
有两种方法在 VPC 和 on-premises 之间建立网络连接:AWS VPN 和 AWS Direct Connection。
summaryAWS VPN
为了建立AWS VPN,首先需要在 on_premise 端建立Customer gateway,并为其配置路由;在VPC端,建立 Virtual private gateway。之后,为这两个 gateway 建立两个独立的IPSec tunnel,之所以需要两个IPSec tunnel,是为了保证通讯的高可用性(HA)。最后,如果没有用动态的路由协议(例如 BGP),那么就需要更新VPC内的路由表,告诉 VPC 如何到达on-premise。
AWS VPN
看起来不错,但是 AWS VPN 毕竟是运行在 internet 上的,有一定的不确定性,而 Direct Connect 就可以解决这个问题。
Direct Connect
在AWS上,不仅有VPC,还有各种各样的service,这些service是在VPC之外的。我们希望从on_premise访问VPC的同时,也能访问到这些service。为此,就需要 AWS Direct Connect Location 的帮助。AWS Direct Connect Location 被发布到website上,可以根据data center的位置就近选择。这是一种物理上的专线,在On_Premise端,建立private virtual interface(VLAN),用于访问VPC;同时建立一条public virtual(VLAN),用于访问service。
location这里引入了两个新的图标:
Direct-Connect VPN gateway
在网上还找到了一张清楚些的图,以供参考:
image.png
多个VPC
也可以让 On_Premise network 连接多个VPC:
一种方式是建立一个Private virtual interface (VLAN),然后通过Direct Gateway 同多个VPC建立连接:
Multiple VPCs
另一种方式是通过AWS VPC。在没有 transit gateway的时候,需要为每个VPC建立一个AWS VPC connection:
on_premise network to multiple VPC without transit gateway
而有了 transit gateway , 事情变得更加简单,通过一个 transit gateway,就可以建立从 On_Premise 到所有VPCs的连接:
on_premise network to multiple VPC transit gateway
Route 53
AWS DNS
Route 53
VPC endpoints
在VPC之外,AWS的公有地址空间内还有很多服务,我们可以通过direct connect 和 virtual interface,从On_Premise network 去访问这些资源。但是如何在VPC内部访问这些资源呢?可以通过 IGW, NAT devices的方式访问,但是如果你觉得那样做比较麻烦(因为需要public IP),可以选择 endpoint 的方式实现。
-
通过IGW 访问
IGW
有两种方式:gateway endpoint 和 interface endpoint。
gateway endpoint
在route table上,可以配置一个指向AWS service的路由目标,这个gateway就是所谓的gateway endpoint。这里没有public IP,只需要private IP 就可以完成设置。
gateway endpoint Endpoint
interface endpoint
通过interface endpoint,不需要任何路由,就你所访问的AWS service好像在VPC内部一样。
Interface endpoint
这里,有一个新的图标PrivateLink。PrivateLink是interface endpoint得以实现的关键。通过PrivateLink,你可以将你的AWS Service 分享给千千万万个VPC。为此,你需要将被分享的Service放在一个 Network LoadBalancer 后面,使得该服务可以作为一个 endpoint service 被其他VPC访问。其他的VPC可以订阅你的Service,并在他的VPC创建endpoint代表你的Service,通过本地地址的endpoint访问你的Service。
PrivateLink
Interface endpoint
参考资料
AWS 2019 summit 视频地址:https://aws.amazon.com/cn/vpc/?vpc-blogs.sort-by=item.additionalFields.createdDate&vpc-blogs.sort-order=desc
演讲者:Perry Wald and Tom Adamski
参考读书笔记:https://blog.csdn.net/Jerry7810/article/details/103581167
网友评论