亚马逊AWS官方博客

Tag: Amazon VPC

如何在AWS上构建基于 OpenSwan 的软件 VPN 解决方案

概述 随着云的普及以及即用即付的模式,正在被大家逐渐接受,那么在初期从原始数据中心到云迁移的过程中,为了保证数据的平稳迁移,并不推荐将应用以及数据库一次性的迁移到云中。所有项目都应该分阶段来进行,阶段迁移的情况下就必须要将云资源与本地数据中心的资源互连互通。 要做到互连互通,有三种备选方案,互联网,专线直连(DX)和 VPN。从三个方面比较下这三种解决方案,安全,稳定性以及费用。DX 服务无疑是最优的一种解决方案,提供安全稳定的网络性能,高吞吐量。由于国内专线铺设所带来的高昂费用,所以在初期阶段,DX 并不是一个最优的。这里面互联网是最便宜的,因为本身数据中心就已经支付了这部分费用,只要保证云中的资源可以上互联网就可以了,但互联网面临的问题是网络依赖互联网,互联网的网络性能并不是可控的,另外一方面是互联网的安全性。VPN 呢是基于互联网的服务,虽然不能保证网络性通的可控,但可以做到数据的安全。 就以上比较而言,在初期阶段,VPN 无疑是一种高性比的安全以及节约成本的方案。考虑到目前北京区域并不支持硬件VPN的服务,即Global区域的VPN Connection。那么有没有可以替代的方案呢?答案是肯定的,一切问题都难不倒我们伟大的开源组织,开源方案如 OpenSwan (今天的主角),StrongSwan,Raccoon等等了。除了开源的解决方案外,还有一些商业解决方案,比如Sanfor 深信服,Hillstone 山石,Checkpoint , Cisco CSR1000v等也可以部署,有兴趣的可以与相应的软件提供商联系。 前面说了那么多关于VPN的各种软件,那么该如何选择呢?这里我们从使用上来划分下吧,将VPN主要划分为两类,一类是工作于客户端到服务端的模式,像OpenVPN,SSL VPN,L2TP,PPTP这些都是需要客户端主动发起连接,拨到Server端在两者之间建立一个逻辑上的隧道 (tunnel)进行通信。这种方式一般适用于个人到总部场景。服务器是无法主动发起连接到客户端。 另外一种就是站点到站点(site-to-site)的模式,像OpenSwan,StrongSwan, Raccoon 等软件,这种情况下两端会各有一个设备负责来建立两个站点之间安全通信的隧道,任何需要到对端的通信都会触发设备来建立安全隧道通信。 那么公司原有数据中心与云通信都是双向通信,所以站点到站点更合理。 实际上这里说的 VPN 即是指 IPsec VPN,IPsec 是一种工业标准,只要支持这种标准的设备都可以互相协商建立一个安全的隧道出来,比如支持的硬件设备有路由器,防火墙以及专业的 VPN 设备。 说了这么多,下面我们就以 AWS 端为 OpenSwan 与 Cisco 的路由器之间的配置为例。 场景及拓扑 拓扑如上图,AWS端建立一个VPC(CIDR:192.168.0.0/16),包含两个子网,一个可以上互联网的Public子网192.168.1.0/24以及私有子网Private 192.168.2.0/24。在公有子网上会配置一台OpenSwan实例与公司的Cisco设备做VPN连接。 OpenSwan的EIP地址为54.223.152.218 子网:192.168.1.0/24 Cisco设备的公网地址为54.223.170.5 子网:10.1.2.0/24 目标:实现AWS上私有子网192.168.2.0/24和数据中心10.1.2.0/24双向互通 详细配置步骤 1.配置 VPC 基础环境 1.1 创建 VPC 在AWS […]

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