亚马逊AWS官方博客

Tag: Amazon VPC

采用亚马逊云科技Cloud WAN实现区域间网络互连

什么是亚马逊云科技Cloud WAN? 多年来,我们观察到客户使用亚马逊云科技网络的方式发生了变化。客户希望降低网络基础设施的复杂性,以便他们可以专注于核心业务和其他优先事项。 亚马逊云科技Cloud WAN是一个托管的全球广域网服务。通过亚马逊云科技Cloud WAN,客户可以轻松的构建辐射全球的广域网络,从全球任意位置连接客户的数据中心、分支机构、多云,以及多个区域的亚马逊云科技资源,并且通过集中的控制面板和灵活的网络策略进行一站式管理。同时,Cloud WAN还提供一个全球网络视图,可以帮助客户监控部署在全球的不同网络资源,以及这些资源的安全、健康状况、性能等,见图1。 图1 Cloud WAN解决方案 亚马逊云科技目前共有十个区域支持Cloud WAN服务(注:本文发布时,Cloud WAN服务尚在Preview阶段,不建议在生产环境中部署使用)。在这些区域进行跨区域VPC互连就可以利用到Cloud WAN的统一控制平台、区域间自动建立对等连接、路由自动分发等优点。本文将选择Singapore、Frankfurt、N.Virginia三个区的VPC通过Cloud WAN实现互连,并且利用Cloud WAN的Segment功能实现不同应用下的VPC网络访问分隔的效果。 Cloud WAN的控制平台在Network Manager下,为Global界面,因此在配置不同区域的参数时不需要切换到各个区域的控制面板下。Cloud WAN网络核心被称为Core Network,每个区域中的Cloud WAN组件被称为Core Network Edge(CNE),区域互连的核心就是CNE组件间的互连。CNE的Attachment模式有:VPC、VPN和Connect。区域中的VPC通过VPC Attachment模式连接到本区的CNE上,通过CNE间的eBGP路由协议交换VPC网段的路由可达信息。 Cloud WAN支持Network Segment,Segment功能引入了广域网多租户的概念,类似MPLS VPN中为不同的租户或应用构建独立的虚拟网络。利用这个功能,本文为App和DevOps两个应用分别设计两个Segment:cloudwanappseg和cloudwandevopsseg。其中cloudwanappseg跨越Singapore、Frankfurt、N.Virginia三个区域;cloudwandevopsseg跨越N.Virginia和Singapore区域。设计目标:属于同一Segment下的VPC间可以通讯,分属于不同Segment的VPC间无法通讯。 Cloud WAN网络设计和实现步骤 1.      参数设计 在实现Cloud WAN连接时需要事先设计CNE的CIDR网段IP地址以及CNE的BGP ASN,在使用Network Segment的情况下还需要规划好每个Segment的VPC归属,具体参数见表1。 表1 Singapore、Frankfurt、N.Virginia区参数设计 Frankfurt区相关参数: N.Virginia区相关参数 Singapore区相关参数: CNE CIDR: 10.22.22.0/24 CNE BGP ASN: 64532 FKFAppVPC(App Segment) CIDR: 172.30.0.0/16 CNE CIDR: […]

Read More

使用AWS VPC, KMS, Lambda和ElasticSearch 实现安全和加密的数据搜索

安全性是您应用程序的首要任务。安全几乎贯穿了产品研发的每一个环节,作为产品架构设计人员,开发,运维人员,使用系统级别的安全防护手段,可以有效的提高产品的安全性。在本文中,我们将向您介绍如何使用 Amazon VPC,Amazon KMS,Amazon Lambda 以及Amazon OpenSearch(Amazon ElasticSearch) 保护您的数据。

Read More

新 – VPC Reachability Analyzer

您可以完全控制虚拟网络环境,包括选择自己的 IP 地址范围,创建子网,以及配置路由表和网络网关。您还可以轻松自定义 VPC 的网络配置。例如,您可以为可以使用互联网网关访问互联网的 Web 服务器创建公有子网。对安全敏感的后端系统(例如数据库和应用程序服务器)可以放置在没有互联网访问权限的私有子网上。您可以使用多个安全层,例如安全组和网络访问控制列表 (ACL),通过协议、IP 地址和端口号来控制对每个子网实体的访问。

Read More

VPC中NAT的那点事

NAT就在那里 下图 是EC2实例通过IGW(Internet网关) 接入到Internet的示意图。熟悉AWS的读者会知道,这里EC2实例和Internet通信的两个方向上,实际上发生了如下的转换: 从EC2实例发出的前往Internet的IP包,其源地址10.0.0.10在经过IGW时,会被转换为与实例关联的公网地址 54.232.0.1; 从Internet发给54.232.0.1的IP包,经过IGW时其目的地址会转换为ENI对应的内网地址10.0.0.10并被送到 EC2实例; 可以看到,这里Internet网关就是起到实例的内网地址和公网地址一对一的基本 NAT(网络地址转换)的功能。 相比于没有NAT的场景,大部分的应用、软件不需要任何改变就能在基本NAT的场景下继续工作,例如基于HTTP协议的Web应用等;但是对于某些应用,例如FTP、VoIP等,网络地址转换会给应用带来一些意想不到的挑战。今天我们以历史悠久的FTP协议为例,来和大家探讨一下NAT给FTP这样的应用带来什么样的挑战,以及FTP应用和协议又是如何演进去适应它。 被动模式下的FTP 我们重温一下FTP的工作过程。客户端连接服务端TCP 21端口建立命令通道后,输入用户名密码完成登录;随后的每一次数据传输都需要另外建立数据通道进行; 如果数据通道由客户端发起,服务端接受,我们称之为被动模式;反之,如果数据通道由服务端发起,客户端接受,则称之为主动模式。 为简化讨论,我们以被动模式为例。 同一个私网内 我们在EC2实例10.0.0.10上搭建了一台FTP服务器,它监听在21端口。现在我们从同一个VPC里的另外一台EC2上运行FTP客户端;那么整个过程会很顺利。 从Internet访问 现在我们从位于Internet某处的一台PC上运行FTP客户端。 这里连接超时的原因显而易见,FTP服务端发送给客户端的IP地址是服务端的私有地址。位于Internet上的客户端无法建立与位于VPC内部的私有地址10.0.0.10直接通讯。 解决这个问题有多种方法,我们由简单到复杂分别叙述。 增强协议适配NAT FTP协议针对NAT和其他因素,对协议进行了增强,提供了增强版的被动模式EPSV命令[1]。 下面的例子里,服务端不再显式指定IP地址,只提供数据通道的端口号。客户端默认与控制通道相同的IP地址建立数据通道。 可以看到,解决方案很优雅。实际上如果你在阅读本文的时候,绝大部分FTP服务端和客户端都已经实现了EPSV,而且优先使用它,所以FTP应用目前在EC2上是可以称之为开箱即用的。当然这需要客户端和服务端都支持增强的协议才能达成;如果我们不修改协议,能否解决这个问题呢。 放开那协议!我来! 有些时候,修改协议和实现需要多方协调和很长的时间才能完成。在RFC2428标准化之前,一些FTP实现就已经通过修改实现来适配基本NAT,而非修改协议。 以vsftpd为例,它允许通过配置文件vsftpd.conf中的配置项 pasv_address=54.232.0.1 告知服务端,在PASV被动模式下,应当指示客户端连接到配置项指定的IP(而不是服务端的私有IP)来适配基本NAT。 其他的一些常见应用例如VoIP类应用,也有类似的机制去适配基本NAT;例如引入STUN/TURN/ICE等方式[2]适配各种更加复杂的NAT穿越场景;但是针对部署在EC2上的基本NAT环境,也有通过实现上的简单调整,例如开源VoIP应用Asterisk就支持通过在配置文件/etc/asterisk/sip.conf里指定本机的公网地址和本地网段的方式来适配基本NAT。 nat=yes externaddr=54.223.0.1 localnet=10.0.0.0/16 协议和实现我都不想动! 作为一枚任性的读者,如果您既不想动协议也不想动实现,这里笔者给读者介绍一种剑走偏锋的方式,读者若有兴趣,可以轻松愉快的在AWS上试一试,看看能否解决你的应用适配基本NAT。下面是一段shell脚本,当然是运行在Linux操作系统上的。           #从EC2 实例元数据服务获取本实例的公网IP(如有)、私网IP           public_ipv4=`curl -s http://169.254.169.254/latest/meta-data/public-ipv4`           local_ipv4=`curl -s http://169.254.169.254/latest/meta-data/local-ipv4`           #配置私网地址段,这里应为EC2实例所在VPC的地址范围           local_net=10.0.0.0/16           if [ […]

Read More