1、各大云厂商之间的VPN比较
业内还有各种各样的移动云的SSL VPN,IPsec VPN,阿里云的VPN,腾讯云的VPN连接?
VPN到底是啥?
阿里云说:VPN网关一款提供网络连接服务的产品,通过建立加密隧道的方式实现企业本地数据中心、企业办公网络、互联网客户端与阿里云专有网络 VPC(Virtual Private Cloud)之间安全可靠的私网连接。
总结:客户网络与阿里云VPC之间加密的私网连接产品
阿里的两种方式:
①IPsec-VPN:基于路由的网络连接技术,提供灵活的流量路由方式,方便配置和维护VPN策略.
②SSL-VPN:适用于在互联网客户端与VPC之间建立网络连接。部署后,仅需要在互联网客户端中加载证书并发起连接,互联网客户端便可与VPC互通。
移动云:通过IPSEC VPN将本地数据中心和云上VPC互联,构建云上云下业务通过公网进行交互。
关键点:咱们通过公网实现云上云下互联互通。
腾讯云:大同小异,关键点说说吧
IPsecVPN:VPC与本地数据中心连接,VPN 网关可以建立多个 VPN 通道,每个 VPN 通道可以打通一个本地 IDC。
SSLVPN:打通客户端与VPC之间的隧道
2、VPN分类
根据实现的网络层次分类
IPSec:Internet Protocol Security, 因特网协议安全协议。
GRE:Generic Routing Encapsulation, 通用路由封装协议。
L2TP:Layer 2 Tunneling Protocol, 二层隧道协议。
MPLS:Multiprotocol Label Switching,多协议标签交换协议。
3、VPN的基本原理
VPN的基本原理:利用隧道(Tunnel)技术,对传输报文进行封装,利用VPN骨干网建立专用数据传输通道,实现报文的安全传输。
位于隧道两端的VPN网关:对原始报文进行封装和解封装。
隧道通过隧道协议实现。目前已存在不少隧道协议,如GRE(Generic Routing Encapsulation)、L2TP(Layer 2 Tunneling Protocol)等。
隧道协议通过在隧道的一端给数据加上隧道协议头,即进行封装,使这些被封装的数据能都在某网络中传输,并且在隧道的另一端去掉该数据携带的隧道协议头,即进行解封装
4、VPN关键技术
身份认证:保障接入VPN的都是合法客户而非恶意客户
数据加密:明文改为密文,即使被截取也无法获取其中的信息
数据验证:对数据的完整性和真伪进行检查,将混淆视听的坏东西丢弃掉。
5、常见VPN技术剖析
5.1 IPsec VPN
IPSec(IP Security)VPN一般部署在企业出口设备之间,通过加密与验证等方式验证数据加密、完整性、抗重等功能。
IPsec不是一个单独的协议,他给出了IP网络上数据安全的一整套体系结构,认证+加密+密钥等等
IPSec协议解释
使用认证头AH(Authentication Header)和封装安全载荷ESP(Encapsulating Security Payload)两种安全协议来传输和封装数据,提供认证或加密等安全服务。
AH和ESP协议提供的安全功能依赖于协议采用的验证、加密算法。
AH仅支持认证功能,不支持加密功能。ESP支持认证和加密功能。
安全协议提供认证或加密等安全服务需要有秘钥的存在。
秘钥交换的方式有两种:
带外共享密钥:在发送、接收设备上手工配置静态的加密、验证密钥。双方通过带外共享的方式(例如通过电话或邮件方式)保证密钥一致性。
讲实话,着实是有点笨了
通过IKE协议自动协商密钥:IKE建立在Internet安全联盟和密钥管理协议ISAKMP定义的框架上,采用DH(Diffie-Hellman)算法在不安全的网络上安全地分发密钥。
优点:这种方式配置简单,可扩展性好,特别是在大型动态的网络环境下此优点更加突出。同时,通信双方通过交换密钥交换材料来计算共享的密钥,即使第三方截获了双方用于计算密钥的所有交换数据,也无法计算出真正的密钥。
IPsec 隧道建立过程
两个对等体之间建立隧道,需要IKE协议进行IPsecSA(安全联盟)协商。
SA介绍:
SA三元组:安全参数索引SPI(Security Parameter Index)、目的IP地址和使用的安全协议号(AH或ESP)。
SPI是为唯一标识SA而生成的一个32位比特的数值,它在AH和ESP头中传输。
①在手工配置SA时,需要手工指定SPI的取值。
②使用IKE协商产生SA时,SPI将随机生成。
IKE密钥协商阶段:
IKE密钥协商协议,存在两个版本:IKEv1和IKEv2,以IKEv1为例子:
IKEv1协商阶段1:建立IKE SA安全通道,保障IKE第二阶段协商能进行,建立后对等体之间的消息都将通过加密和验证传输;
IKEv1协商阶段2:建立安全传输数据IPsec SA通道,使用第一阶段的ISAMP消息的完整性进行身份认证,并加密。;
协商成功:
IKE协商成功,意味着IPsec隧道建立,通过ACL和安全策略方式定义数据流,符合策略的数据流,将在隧道中加密传输。
5.2 IPsec包分析
第一阶段:ISAKMP协商阶段
发起端协商SA,使用的是UDP协议,端口号是500
- Initiator cookie:817622ea01367ec9
发起者的cookie值,告知响应端主机要使用IPSEC的哪一把密钥来加密这个封包。
- Responder cookie:0000000000000000
响应者的cookie值,第一个包只有发起者没有响应者所以响应者的cookie为空
- Version:1.0
IKE版本号,1.0表示使用IKE v1建立连接
- Exchange type:Identity Protection (Main Mode) (2)
IKE协商模式为主模式
- Life-Type (11): Seconds (1)
生存期时间的单位为秒
- Life-Duration (12): Duration-Value (86400)
密钥周期86400,密钥周期超过86400后会重新协商IKE
- Encryption-Algorithm (1): AES-CBC (7)
IKE使用DES-CBC加密算法加密数据
- Hash-Algorithm (2): SHA (2)
IKE使用SHA算法校验数据完整性
- Authentication-Method (3): RSA-SIG (3)
RSA方式进行认证,除此之外还有与共享秘钥(Pre-shared key)
- Group-Description (4): Alternate 1024-bit MODP group (2)
Diffie-Hellman (DH) 组在密钥交换进程中使用的1024 bit的密钥的强度
- Key-Length (14): Key-Length (128)
秘钥长度128位
第二个响应包
响应端收到发送端发送的加密套件后,对比自己是否有相对应的加密套件,如果有就使用和发送端相同的加密套件加密数据,把自己的cookie值和选择好的加密套件发送给发送端;如果没有相同加密套件则IKE建立失败响应。
- Initiator cookie:817622ea01367ec9
发起者的cookie值,告知响应端主机要使用IPSEC的哪一把密钥来加密这个封包。
- Responder cookie: 58E452AA5DC6679B
响应者的cookie值,告知发起端主机要使用IPSEC的哪一把密钥来加密这个封包
其他内容差不多
第三包:进行DH公共值和Nonce随机数协商,生成三把钥匙。
第四包:响应第三包
第五包:起方发起身份验证,报文中带有认证的数据(预共享密钥或者数字签名)。使用第一把钥匙
第六包:响应端回应报文,同样发送认证的数据(预共享密钥或者数字签名),双方身份验证通过后,IKE协商结束。
第二阶段:IPsec SA协商,加密隧道形成
第七包:发起方主要是进行IPSEC SA的协商,建立安全联盟,报文内容主要是协商用的封装方式以及后面的加密算法以及生存时间和感兴趣流等等。由于数据加密所以无法查看。
- Initiator cookie: 817622EA01367EC9
发起者的cookie值是由上阶段IKE协商时已经确定的,所以IPSec协商依然使用上阶段的cookie
- Responder cookie: 58E452AA5DC6679B
响应者的cookie值是由上阶段IKE协商时已经确定的,所以IPSec协商依然使用上阶段的cookie
- Next payload: Hash (8)
- Version:1.0
IKE版本号,1.0表示使用ikev1建立连接 - Exchange type:Quick Mode(32)
交换类型使用快速模式,IPSec协商时只有快速模式
- Encrypted payload (128 bytes)
被加密的数据,主要为感兴趣流、加密策略协商。(这里使用第二把钥匙进行加密)
第八包:响应方回包,同意包7发送的封装方式、加密算法、生存时间、感兴趣流等等
- Encrypted payload (128 bytes)
被加密的数据,主要为感兴趣流、加密策略协商。(这里使用第二把钥匙进行加密)
第九包:发送确认报文。其中包含一个HASH,其作用是确认接收方的消息以及证明发送方处于主动状态(表示发送方的第一条消息不是伪造的)。由于数据加密所以无法查看。
报文数据包参考学习自叨陪鲤:https://www.cnblogs.com/s2603898260/p/14624330.html
GRE、L2TP、MPLS VPN嫌麻烦,我自己悄悄看了