VPN的分类
-
VPN有什么作用?
-
虚拟私用网, 利用共享的公网网络设施对广域网设施进行仿真而构建的私有专用网; 可以像企业现有的私有网络一样提供安全性,可靠性和可管理性
-
-
按业务类型分类:
-
LAN-LAN VPN:又称(Site to Site VPN),用于对接不同的远程分支机构内网,隧道两端都需要专用的 VPN 设备,隧道建立后两端内网的主机无需任何设置就可以直接互相访问，一般是在网关之间架设的。
-
Client-LAN VPN:用于对接单个终端和企业内网。隧道一端是企业内网的VPN 设备、另一端允许 PC或其它终端设备直接拨入。用户终端无需任何专用 VPN 设备，随时随地都能连接，一般用于远程接入VPN。
-
-
按照运营模式分类:
-
(企业级VPN)CPE-Based VPN:基于用户前端设备的 VPN。该 VPN 隧道由用户使用自己的设备建立。VPN的部署和维护完全由用户自行完成。我们将这种VPN称为企业级 VPN。好处是用户可自由部署，随意扩展;缺点是需要相当专业能力来完成配置,而且隧道要穿越中间运营商网络:Q0S难以自行控制。典型的 IPSec VPN。
-
(运营商级VPN)Network-Based VRN:这种 WPN 由运营商来建设和维护,隧道也是在运营商网络中建立，用户只需要接入到运营商网络的 VPN 服务就可以了。好处是用户对 VPN 无感知，无需任何复杂的配置和操作。我们也将这种 VPN 称为运营商级别的 VPN。典型的 MPLS VPN。
-
-
按照 OSI模型分类:
-
L2VPN:工作在数据链路层的 VPN,隧道抓取数据帧进行公网封装。如 L2TPVPN、PPTP VPN、MPLS L2VPN。
-
L3VPN:工作在网络层的 VPN,隧道抓取数据包进行公网封装。如 GRE VPN、IPSec VPN、 MPLS L3VPN.
-
应用层VPN:工作在应用层的VPN，隧道抓取应用层的数据进行封装，如SSL VPN.
-
GRE VPN的特点:
-
GRE:通用路由封装,一种封装方法的名称;在任意一种网络协议上传送任意一种其他网络协议的封装方法;只是一种封装方法,对于隧道和VPN操作的处理机制没有规范
-
GRE VPN:直接使用GRE封装建立GRE隧道，在一种协议的网络上传送其他协议的一种VPN;直接利用GRE多层封装构造隧道(Tunnel),从而在一个网络协议上透明传送其他协议分组
-
GRE VPN的优点:
-
支持多种协议
-
支持组播，所以可以在隧道中运行路由协议(任何需要从Tunnel接口发出的数据均可以获得GRE封装并穿越隧道)
-
配置简单，部署容易
-
-
GRE VPN的缺点:
-
点到点隧道，多站点部署复杂(只适用于站点到站点)
-
静态配置隧道参数,想要修改必须同时手工修改两端
-
缺乏安全性,不提供数据加密服务
-
不能隔离地址空间
-
从数据包收到到转发结束端点路由器两次查找路由表,实际上路由器只有一个路由表,公网和私网接口不能有重合的地址,不能真正上分割公网和私网
-
-
GRE VPN的封装格式
-
IP over IP的GRE封装:
-
采用以IP同时作为载荷协议和承载协议的GRE封装IP over IP的GRE封装
-
使用公有IP来封装私有IP
-
公网IP头部使用47标识GRE头部:IP头中Protocol字段为47时说明IP包后面跟着GRE头部
-
GRE头部使用0x0800标识私网IP头部:GRE头中Protocol Type 0x0800说明GRE后面跟着IP头
-
-
结构
-
公网IP头部:GRE隧道封装新的IP头部,用于在公网上寻址转发,Protocol通过47标识后面是GRE协议
-
GRE头部:使用以太网协议类型0x800标识后面是IP协议
-
原始IP头部:原始的私网 IP 头部
-
原始载荷:原始数据内容
-
GRE VPN把Tunnel口的源地址宣告进路由协议的问题
在配置的时候有什么注意事项?
-
公网可达,使用默认路由
-
把Tunnel口的源地址通过通告到路由协议
-
Tunnel可达->查路由表怎么去目的
-
原本静态路由走公网
-
后来ospf通告Tunnel口学到更加明细的路由
-
-
解决:不要让前往隧道目的的路由走Tunnel口
-
写静态路由前往隧道目标指到公网口
-
-
无限封装
-
如果把 GRE Tunnel口的源地址宣告进路由协议的话，就会把源地址的路由传递给对端VPN设备学习。该路由在对端设备就是Tunnel口的目的地址的路由
-
如果对端的 VPN 设备通过隧道间的路由协议学习到了目的地址的路由，出接口一定是指向 Tunnel 口的,那么当 VPN 设备把私网数据包抓取到 Tunnel 口后，封装上新的IP头部
-
再次查询路由表，按照最长匹配机制，就会匹配到学习到的目的地址的路由再次进入Tunnel口，而不是匹配缺省路由发往公网
-
数据包再次进入Tunnel口后，再次进行新的封装，封装后重复上一步、形成死循环，数据转发失败;
GRE VPN 两端可以经过 NAT 吗
-
如果两边都是静态 NAT的场景，可以在两端的 NAT设备上将建立 GRE 的源和目标地址分别都转换成公网地址，在基于这些可达的公网地址建立IPSec VPN最后基于建立的IPSec VPN 建立两端的 GRE VPN。
-
如果一端是静态 NAT，另一端是动态 NAT,则可以在静态 NAT 那端，将建立GRE 的源转换成公网地址，然后结合安全模板和野蛮模式的方式，在动态 NAT那端主动发起到静态 NAT这端的 VPN 连接。
-
如果两边都是动态 NAT的话，则不支持 GRE VPN 的建立，因为 IPSec VPN 的建立，需要有一端固定的 IP地址，在动态 NAT场景中，转换的公网地址是不固定的，所以不支持两端都是动态 NAT的 GRE VPN 建立。
如何解决数据传输的机密性、完整性、身份验证、不可否认性，实现安全的四要素
VPN有什么作用?然后接着问怎么保护数据?
-
机密性:通信是否安全
-
防止数据被未获得授权的查看和理解，从而在存储和传输的过程中防止有意或无意信息内容泄露，保证信息安全性。通过数据加密来保证机密性
-
对称加密:也称为预共享密钥算
-
原理:加密和解密使用同一个密钥，数据传输之前需要先在网络中传输密钥;
-
特点:优点是效率高,算法简单,适合加密大量数据;缺点是安全性差和扩展性差
-
适用于能够安全交换密钥且传输数据量较大的场合
-
典型算法(DES,3DES,CAST,ASE)
-
-
非对称加密:
-
原理:加密和解密使用不同密钥,其中公钥是对外公开的,通常用于数据加密,私钥是不公开的,通常用于解密,必须成对使用
-
特点:优点安全性高,缺点是算法复杂,导致加密大量数据时间长,加密中添加较多附加信息,使得报文较长传输效率低
-
不适合对大量数据的加密
-
典型算法(RSA,DSA,DH)
-
-
混合加密:数字信封
-
原理:用非对称加密的方式来确保对称密钥传输的安全性;使用对称加密密钥来保护数据传输,使用非对称加密来保护对称加密的密钥
-
特点:解决了对称密钥的发布安全问题，和公钥加密速度慢问题,提高了安全性、扩展性和效率等
-
但是无法确保信息是真正来自对方的;
-
-
-
完整性:发出的信息被篡改过吗
-
防止数据在存储或传输的过程中受到非法的篡改。这种篡改既包括无授权者的篡改，也包括具备有限授权者的越权篡改。一些意外的错误也可能导致信息错误、完整性检查需要发现这些错误。通过数字签名来保证数据完整性或者通过哈希算法来对数据的完整性做检查
-
-
身份验证:我在与谁通信,是否有权?
-
通过检查用户的某种印鉴或标识，判断一份数据是否源于正确的创建者。也通过数字签名来解决，或通过预共享密钥。
-
-
数字签名:
-
给数据加密的同时解决身份验证问题,数据完整性问题,防止交易中的抵赖发生
-
工作原理:
-
发送方:
-
使用接受方的公钥对明文加密,生成密文信息
-
数字指纹:使用HASH算法明文进行HASH运算,生成数字指纹
-
数字签名:用自己的私钥对数字指纹进行加密,生成数字签名
-
将密文信息和数字签名一起发送给接收方
-
-
接收方:
-
得到数字签名:使用发送方的公钥对数字签名进行解密,得到数字指纹
-
解开密文信息:接收到发送方的加密信息后,使用自己的私钥对密文信息进行解密,得到最初的明文
-
生成数字指纹:使用HASH算法对还原出的明文用与甲所使用的相同HASH算法进行HASH运算,生成数字指纹
-
然后将生成的数字指纹与从接收方得到的数字指纹进行比较，如果一致接收,不一致丢弃
-
-
-
-
不可否认性:
-
使用非对称加密和数字签名技术后，公钥的传递和真实性也是一个很大问题。如果公钥能够被随意更改和伪造，那么数据发送者的身份就无法确定,发送者可以否认和抵赖。这个问题需要通过PKI 体系给通讯双方颁发证书来解决
-
-
PKI体系:
-
定义:一个签发证书、传播证书、管理证书、使用证书的环境,PKI体系保证了公钥的可获得性、真实性、完整性
-
CA:证书颁发机构,处理用户的证书请求、签发用户证书、注销用户证书
-
RA:证书注册机构,用于处理用户的证书注册请求
-
-
数字证书:
-
非对称加密和数字签名本身无法验证公钥的真伪,需要权威第三方来统一下发和管理公钥
-
定义;一个经证书颁发机构数字签名的包含公开密钥拥有者信息和公钥的文件,数字证书由证书颁发机构下发,包含用户身份、用户公钥、根证书签名
-
数字证书包含的内容
(没问过)
-
用户的身份、用户的公钥、根证书签名。根证书签名用于验证此证书和公钥的真伪
-
主要格式是X509
-
通过 PKI体系来实现数字证书的申请、签发、管理和注销等功能
-
证书的类型:
-
根证书:CA颁发给自身的证书，即CA的自签名证书。
-
个人证书:用户或设备向 CA申请的证书，由CA 签发给用户或设备的证书。
-
IPsec 的工作模式
(封装模式)
-
封装指的是将AH或者ESP协议的相关字段插入到原始IP数据包种,实现对报文的认证和加密
-
传输模式:
-
概述
-
仅传输层数据被用来计算安全协议头
-
生成的安全协议头以及加密的用户数据（仅针对ESP封装）被放置在原IP报头后面
-
不对原IP报文进行重封装，只是把新添加的认证头当成原始IP报文的数据部分进行传输
-
-
架构:
-
实现端到端的保护，不建立VPN隧道
-
需要两个通信的终端计算机在彼此之间直接运行IPsec协议,AH和ESP直接用于保护上层协议
-
所有加密,解密,协商操作均由端系统自行完成,网络设备仅执行正常的路由转发,不关心过程或协议,也不加入任何IPSec过程
-
-
封装格式:
-
单独使用AH
(IP报头 | AH报头 |TCP段头|数据)
-
单独使用ESP
(IP报头|ESP报头|TCP段头|数据|ESP尾|ESP认证数据)
-
同时使用AH和ESP
(IP报头| AH报头| IP报头| ESP报头| TCP段头| 数据| ESP尾| ESP认证数据)
-
-
-
隧道模式:
-
概述:
-
用户的整个IP数据包都被用来计算安全协议头
-
生成的安全协议头以及加密的用户数据(仅ESP)被封装在一个新的IP数据包中
-
隧道模式下的安全协议用于保护整个IP数据包
-
封装后的IP报头:
-
内部IP报头为原IP报头
-
外部IP报头是新增加的IP报头:源IP地址是本地部署安全策略的接口IP地址;目的IP是对端部署安全策略的接口IP地址
-
-
-
架构:
-
实现站点到站点保护，建立VPN隧道
-
两个安全网关在彼此之间运行IPsec协议,对彼此之间需要加密的数据达成一致,并运用AH或者ESP对这些数据进行保护
-
对端系统的IPSec能力没有任何要求,端系统的数据流经过安全网关时,由安全网关对其进行保护;所有操作由安全网关完成,对端系统完全透明
-
-
封装格式:
-
单独使用AH
(新IP头| AH报头| 源IP报头| TCP段头| 数据)
-
单独使用ESP
(新IP头 |ESP报头 |源IP报头 |TCP段头 |数据 |ESP尾 | ESP认证数据)
-
同时使用AH和ESP
(新IP头 |AH报头 |ESP报头 |源IP报头 |TCP段头 |数据 |ESP尾 | ESP认证数据)
-
-
-
对比:
-
安全性:隧道模式优于传输模式，因为隧道模式可以完全地对原始IP数据包进行认证和加密,隐藏客户机私网IP地址;传输模式的数据加密不包括原始IP报头
-
性能:隧道模式有额外的IP头,比传输模式占用更多的带宽,传输效率较低
-
应用场景:
-
传输模式IPSec只提供端到端的安全保护，但并不建立 VPN 隧道,在两个安全网关之间运行IPSec,不适用于对一个局域网中对数据传输安全性的保护,适用于已经实现IP 可达的上层应用数据进行保护，无需增加额外的IP头部，报文开销比较小。
-
隧道模式:实现站点到站点的保护,在两个安全网关之间运行IPSec,提供站点到站点的安全保护,并建立 VPN 隧道，适用于异地分支机构的安全远程对接,为增加一个新的IP头部,报文开销比较大对于本身IP不可达的主机,通过隧道模式架设IPSec VPN,实现业务可达
-
-
IPSec 中传输模式和隧道模式报文封装由什么区别?
-
隧道模式会封装新的IP 头部，而传输模式不封装新 IP 头部。
-
传输模式一般应用已经具备 IP 可达， 需要对上层数据进行保护的场景，比如L2TP over |PSec 和 GRE over lPSec。
-
隧道模式一般应用于本身不具备IP 可达，通过隧道模式建立 IPSec VPN，如果是在 IPSec NAT 穿越的场景只能使用隧道模式。
-
使用传输模式的例子
-
GRE隧道,IPSec over GRE,以及站点间地址固定的GRE over IPSec
-
L2TP over IPSec
-
ADVPN
-
IPv6中,用扩展报头对OSPFv3的报文进行验证和加密
-
IPSec的安全协议
IPSec 的保护协议
-
概述:
-
定义了对IP报文的封装格式以及可提供的安全服务,实现身份认证和数据加密方面的安全机制
-
AH协议定义了认证的应用方法,提供了数据源认证和完整性保证;ESP定义了加密和可选认证的应用方法,比AH提供更全面的安全保证
-
-
AH:
-
概述:
-
称为认证头部,基子IP协议 51,在原始数据包中添加一个身份认证报文头; 提供数据的完整性校验和源验证,以及可选的抗重播服务,整个数据包(新IP报头中可选字段除外) ;不提供数据加密功能(适用于传输非机密数据)
-
无法穿透NAT(AH对整个新的IP报文做校验，所以NAT修改IP地址后，将导致校验值改变)
-
使用的认证算法有HMAC-MD5,HMAC-SHA1等
-
-
报文格式:
-
网络层,IP协议号51,在IP协议之上,需要经过IP协议封装
-
-
下一头部:8位,标识AH报头后第一个上层协议的类型
-
传输模式下是被保护的上层(TCP/UDP)或者ESP协议的编号;隧道模式下是IP协议或者ESP的编号;AH和ESP一起使用,AH报头下一个头部为ESP报文头
-
-
安全参数索引(SPI):32位,用于唯一标识IPSec安全联盟
-
序列号:32位,用于抗重放攻击
-
认证数据:用于接收方进行完整性校验
-
-
-
ESP:
-
概述:
-
称为封装安全载荷，基于IP协议 50，在原始数据包中添加一个ESP报文头，并在数据包后面追加一个ESP尾和可选的ESP认证数据,提供数据加密、完整性校验、数据源验证功能。将需要保护的用户数据进行加密后再封装到IP包中(ESP头-ESP尾)
-
可以穿透NAT(ESP不对新的外层IP头部做校验，所以NAT修改数据头部后不会影响校验结果 ;可以穿越 NAT，并且基于 UDP 4500 来封装 ESP 报文)
-
加密算法,DES,3DES,ASE
-
-
报头格式:
-
网络层,IP协议号50,在IP协议之上,需要经过IP协议封装
-
ESP头部:
-
安全参数索引:32位,用于唯一标识IPSec安全联盟
-
序列号:32位,用于抗重放攻击
-
-
负载数据
-
ESP尾部:
-
填充,填充长度8位,下一个头部
-
-
认证数据,ESP的验证功能是可选的
-
-
-
能否同时使用 AH 和 ESP:
-
可以同时使用，先用ESP 对报文进行加密，然后用 AH 对整个 ESP 报文在进行完整性校验。认证功能重叠,会影响传输效率
-
什么应用场景:基于IPSec对OSPFv3的报文进行加密和身份验证
-
-
AH和ESP比较:
-
协议号:AH:51,ESP:50
-
数据完整性校验:AH:支持(验证整个IP报头),ESP:支持(不验证IP头:ESP头--ESP尾);AH的认证服务强于ESP
-
数据加密:AH:不支持,ESP:支持
-
NAT穿越:AH:不支持,ESP:支持
-
AH对整个新的IP报文做校验，所以NAT修改IP地址后，将导致校验值改变;ESP不对新的外层IP头部做校验，所以NAT修改数据头部后不会影响校验结果 ;可以穿越 NAT，并且基于 UDP 4500 来封装 ESP 报文
-
-
安全联盟SA
IPSec隧道建立原理:其实就是在隧道两端设备上建立好SA
SA概述:
-
IPsec安全联盟,是IPsec的基础,也是IPSec的本质
-
SA 是 IPsec 对等体间对某些要素的约定(安全策略)双方对如何保护通信安全达成的一个协定,包含安全协议、封装模式,认证/加密算法、密钥等,具体确定了如何对IP报文进行处理; 对等体只能在双方最终确定所采用的SA后才能建立对等体关系
-
SA是单向的,一个SA就是两个IPsec系统之间的一个单向逻辑连接,入站数据流和出站数据流由入站SA与出站SA分别处理
SA的内容:
-
一个IPSec SA 通过(SPI、IP 目的地址、安全协议标识符)三元组来标识:
-
SPI安全参数索引:一个 32 比特的数值，在每一个IPSec 报文中都携带该值，类似该 SA 的ID，该 SPI是两个对等体动态协商的一个随机值，与不同的对等体用不同的SPI标识:
-
可以从接收到的数据的AH或ESP报头获知对应的SPI，然后看与本端配置的哪个入方向的SPI一致，以此可确定所接收的数据是采用哪个SA。在SPI的配置中，要求本端的出方向SA的SPI必须和对端的入方向的SPI一样
-
-
IP目的地址:是 IPSec协议对方的地址
-
安全协议标识符:标识该 SA 使用的是 AH 或 ESP
-
-
SA 的内容包括使用什么协议、验证和加密使用什么算法、密钥等内容
SA的生成方式
-
手工配置:
-
两端手工设置一些参数,在参数匹配和协商过后建立SA
-
特点:配置复杂,而且需要大量重复配置,不支持一些高级特性(定时更新密钥); 但是可以不依赖IKE独立实现IPSec功能; 适用于需要通信的对等体少,或小型静态组网环境
-
需要手工指定SPI的取值,必须使用不同的SPI来保证唯一性
-
-
IKE自动协商
-
使用 IKE 进行 IPSec SA 的自动协商。IKE 基于 UDP500，IKE为IPSec 提供了自动协商交换密钥、建立 SA的服务
-
在隧道两端协商建立IKE SA,此过程中生成认证密钥和加密密钥 ;再在此基础上协商建立IPSec SA,此阶段还可生成新的直接用于用户数据加密的加密密钥
-
特点:能够简化ipsec 的使用和管理,扩展性强,在中大型的动态组网中使用
-
SPI随机生成
-
两个对等体之间存在一个IKE SA，IKE SA用于保护 IKE 的协商数据。存在至少一对的IPSec SA,IPSec SA用户保护用户的实际业务数据,一个是用于outbound的数据加密处理，一个用于inbound 对收到的加密数据进行解密处理，如果两个对等体之间，存在多个会话，则会生成多对的IPsec SA
-
SA的老化机制:
-
手工建立的SA用不老化,通过IKE建立的SA具有生存时间,生存时间到达SA会删除
-
IKE 协商建立的 SA 在生存时间到达前会提前协商一个新的 SA 来替换旧的 SA,从 SA 建立到启动新 SA 协商的这段时间是软超时时间
-
两种形式的生存时间:
-
以时间进行限制:每隔定长的时间就对SA进行更新
-
以流量进行限制:每传输一定的字节数量的信息就对SA进行更新
-
可以同时存在,其中一个到达就会删除旧的SA
-
SPD和SAD是什么
-
SPD:安全策略数据库,记录了对哪些数据流使用哪个SA 进行保护,SPD中的项指向SAD中的相应项(SA的具体内容就是SAD)
-
SAD:安全联盟数据库,记录了每个SA的具体内容,一台设备的每个IPsec SA都在SAD有对应项,定义了该SA的所有参数
-
例如一个需要被 IPSec 保护的数据包出站，系统会将它与 SPD 数据库中的策略相比较，如果查询到该数据包被某一个SA 保护，则到 SAD 中具体去查询该SA的保护方案
IKE
IKE概述
-
IKE 协议建立在 ISAKMP定义的框架上,基于UDP端口500的应用层协议,IKE为IPSec提供自动交换密钥,建立SA的服务,简化IPSec的使用和管理
-
采用IKE建立IPSec隧道时,SA有两种:
-
IKE SA:为了协商用于保护IPSec的一组安全参数
-
IPSec SA:为了协商用于保护用户数据的安全参数
-
IKE SA是IPSec SA的基础,IPSec SA建立需要用到IKE SA建立后的一系列密钥
-
-
IKE不仅可以用于IPsec,实际上是一个通用的交换协议可以用于交换任何的共享密码
-
IKE动态协商的好处:
-
降低配置复杂度:SPI,认证密钥,加密密钥等可以自动生成
-
提供抗重播功能:使用序列号实现抗重播(不接受相同的数据包)序列号溢出后,为了实现抗重播需要重新建立,需要IKE配合
-
支持协商发起方地址动态请情况下身份验证
-
支持认证中心CA在线对对方身份的认证集中管理
-
协商建立的SA具有生存周期可以实时更新,降低被破解风险
-
-
IKE包括三大协议:
-
ISAKMP:定义了IKE对等体（IKE Peer）之间合作关系，建立IKE SA
-
Oakley:产生和交换IPSec密钥材料并协调IPSec参数的框架,包括支持哪些安全协议
-
SKEME:决定了IKE密钥交换的方式，主要采用DH（Diffie-Hellman）算法
-
IKE和IPSec的关系
-
IPsec SA有两种来源,一种是手工配置的,另一种就是通过IKE自动协商生成的,通过IKE交换,IPsec通信双方可以协商并获得一致的安全参数,建立共享密钥,建立IPsec SA,把建立的参数及生成的密钥交给IPSec,IPSec使用IKE建立的SA对IP报文进行加密或者验证处理
-
对等体之间建立一个IKE SA后，在IKE SA保护了IPSec隧道的情况下,再根据配置的AH、ESP安全协议等参数协商出一对IPSec SA，用于对等体间的数据在IPSec隧道中的安全数据传输。
-
IKE 是UDP协议(AH和ESP是网络层协议)是IPSec的信令协议
IKE的安全机制
-
身份认证机制
-
预共享密钥认证PSK:共享密钥是作为密钥生成材料的,双方采用共享的密钥用相同的哈希算法对报文进行哈希运行,根据运算的结果是否与发送方发来的哈希一致来判断所接收的数据是否被篡改
-
数字证书认证RSA:通信双方使用CA证书进行数字证书合法性验证;非对称密钥
-
数字信封认证:将对称密钥通过非对称加密（即有公钥和私钥两个）的结果向对方分发对称密钥的方法，类似于现实生活中的信件;非对称密钥
-
-
数据加密机制:
-
IKE协商阶段保护所传输的用于身份认证的数据信息（如共享密钥、证书、认证密钥等）
-
IPSec隧道建立后保护在隧道中传输的用户数据
-
采用的对称密钥机制,加密解密相同的密钥
-
-
DH密钥交换算法:
-
通信双方可在不传送密钥的情况下，仅通过交换一些数据，即可计算出双方共享的密钥;主要用于IKE动态协商时重新生成新的IPSec SA所用的密钥
-
-
PFS机制:
-
完善的前向安全性,指一个密钥被破解后并不影响其他密钥的安全性，因为这些密钥间没有派生关系
-
IKE的协商阶段
第一阶段
-
目的:在对等体之间创建一条安全通道,建立对等体的IKE SA;IKE对等体彼此验证对方,并确定共同的会话密钥;这个阶段需要用到DH算法进行密钥交换,完成IKE SA建立使后面的第二阶段过程的协商过程受到安全保护
-
交换模式:
-
主模式:
-
在IKEv1的主模式IKE SA建立过程中,包含三次双向消息交换,用到了6条信息
-
6次握手流程:
-
第①②个包:主要是协商IKE策略,策略包括:加密策略,散列函数,DH组,认证方式,密钥有效期
-
第③④个包:通过DH交互来产生IKE SA的密钥
-
低⑤⑥个包:在安全的环境下进行身份认证,这两个包是被加密的,在这两个包中根据配置的方式,进行预共享密钥认证,或者证书认证,或者RSA认证,一般都采用预共享密钥认证;
-
-
具体交换过程:
-
第一步骤消息①②:IKE策略交换
-
隧道两端对等体之间通过交换彼此配置的IKE策略协商好要共同采用的IKE安全策略,因为只有双方都采用相同的安全策略才能相互识别对方加密的数据，并对对方身份进行正确认证;为后面能在一个安全的环境之下协商IPSec SA打下基础，因为这些IKE策略会直接提供对第二阶段的IPSec SA协商的加密保护。
-
这个过程中,发起方发送一个或多个IKE安全提议,加密算法,哈希算法,响应方在本地查找最先与收到的安全提议匹配的IKE安全提议，并将这个确定的IKE安全提议回应给发起方，使发起方获知双方共同确定的IKE策略
-
-
第二步骤消息③④:密钥信息交换,产生密钥
-
对等体间通过DH算法交换彼此的密钥生成所需的参数信息(DH公开值和随机数nonce等),建立两端相同的一系列共享密钥主要包括用于在第二阶段协商的身份认证密钥和协商数据的加密密钥。
-
认证密钥用于在IKE第二阶段协商中为信道中传输的协商数据（非用户数据）进行认证
-
加密密钥用于在IKE第二阶段协商中为信道中传输的协商数据进行加密
-
-
第三步骤消息⑤⑥:验证身份
-
用前面已创建好的加密密钥彼此相互发送各自的身份（如对等体的IP地址或名称）和验证数据（所采用的身份认证方式中的密钥，或证书数据等）
-
当相互认证通过后，对等间的IKE SA建立就完成了
-
第二个阶段协商IPSec SA所需的安全通道就会立即建立，两端的VPN设备就可用第一个阶段协商的安全策略对第二阶段协商IPSec SA进行安全加密和认证。
-
-
-
-
野蛮模式(积极模式)
-
野蛮模式只用到三条信息，消息①和②用于在对等体间协商IKE安全策略，交换DH公钥、必需的辅助信息和身份信息（通常不以IP地址进行标识，而是以主机名进行标识的）
-
三次握手流程
-
第一个包由主动方发起一个消息，包含:加密算法、散列函数、验证方法、DH组、DH 公共值、身份信息
-
第二个包被动方也发送自己的上述内容，并加上一个验证载荷
-
第三个包由主动方回复一个验证载荷，第三个包是被加密的
-
-
交换过程:
-
消息①:
-
包括了发起方提供给响应方的IKE安全策略、本端密钥生成信息（本端的DH公钥）和身份信息（主要是对等体名称）响应方在收到这些信息后，首先也是要在本地查找与发起方发来的IKE安全策略匹配的策略如果找到即确定作为共同的IKE策略。
-
然后利用确定的IKE安全策略、发起方发来的密钥生成信息，以及本端的DH公/私钥，一个nonce随机数生成认证密钥和加密密钥，并根据发起方发来的身份信息对发起方的身份进行初步的验证。
-
-
消息②:
-
仅包括响应方的密钥生成信息、身份信息，以及响应方用于身份验证的验证数据（包括所采用的身份认证机制中的密钥、证书等）发给发起方
-
发起方在收到后获知最终采用的IKE策略，并利用响应方的公钥、本端的公/私钥，以及一个nonce随机数生成一系列密钥（正确情况下，与响应方生成的密钥是相同的）并根据响应方发来的身份信息和验证数据对响应方进行最终的身份验证。
-
-
消息③:
-
是发起方根据已确定的IKE策略，把自己的验证数据（包括所采用的身份认证机制中的密钥、证书等）发给响应方让响应方最终完成对发起方的身份验证。
-
-
-
-
第二阶段
-
目的:IKEv1版本的第二阶段就是要在第一阶段基础上最终建立一对IPSec SA
-
交换模式:
-
它只有一种模式，即快速模式（Quick Mode）
-
快速模式的协商是受IKE SA保护的
-
在快速模式的协商过程中主要是完成以下IPSec SA安全策略的确定：
-
使用哪种IPSec安全协议：AH或ESP。
-
使用哪种HASH算法（认证算法）：MD5或SHA。
-
使用哪种IPSec工作模式：隧道模式或传输模式;
-
是否要求加密，若是，选择加密算法：3DES或DES。
-
可选支持PFS（完善的前向安全性）
-
在上述几方面达成一致后，将建立起两个IPSec SA，分别用于入站和出站通信
-
-
过程:
-
消息①②:IPSec安全提议包括了安全协议、SPI、IPSec封装模式、PFSIPSec SA生存周期等。这两条消息中还包括双方的身份信息,验证数据,，以及nonce,接收方会利用所收到的对方数据生成加密密钥
-
消息③:为确认消息，通过确认发送方收到该阶段的消息②，使响应方获知可以正式通信了
-
-
第一阶段主模式和野蛮模式的区别
两个模式对比:
-
主模式:
-
通过6次握手完成协商:第1次和第2次用于协商算法、第3次和第4 次用于交换密钥资源，产生密钥信息，其中第5次和第6次用协商的算法和产生的密钥信息进行加密，而描述身份的主机名信息是在5、6两次握手中传输的，导致主模式无法识别到对方的主机名信息，只能通过IP 地址来标识对方身份。
-
所以主模式要求隧道双方都具有固定公网IP地址,旦某一方公网地址变更、需要重新配置，非常麻烦。但也由于主机名身份信息被加密、所以主模式更加安全
-
-
野蛮模式:
-
通过3次握手完全协商，更快速。第1次和第2次交换报文完成主模式第1次到第4次交互报文的工作，其中只有第3次被加密。
-
主机名信息是在第1次和第2次握手中传递的，未被加密，所以野蛮模式下，可以使用主机名来标识对方身份。所以可以支持某一方的公网IP地址不固定。
-
但由于主机名身份信息未被加密，也会导致相对不够安全，如果双方采用固定地址，也可以采用野蛮模式。采用数字证书作为身份验证方式时,可以采用主模式
-
-
但虽然野蛮模式不提供身份保护，它仍可以满足某些特定的网络环境需求。
-
当IPSec隧道中存在NAT设备时，需要启用NAT穿越功能，而NAT转换会改变对等体的IP地址，由于野蛮模式不依赖于IP地址标识身份，使得如果采用预共享密钥验证方法时，NAT穿越只能在野蛮模式中实现。
-
如果发起方的IP地址不固定或者无法预知，而双方都希望采用预共享密钥验证方法来创建IKE SA，则只能采用野蛮模式。
-
如果发起方已知响应方的策略，或者对响应者的策略有全面的了解，采用野蛮模式能够更快地创建IKE SA。
-
IPSec 预共享密钥的作用
-
IPSec 预共享密钥的作用主要有两个
-
在采用共享密钥的身份验证方式时，可以通过这个共享密钥完成身份验证
-
在 IKE阶段一的 DH 交互过程中，会将该共享密钥作为计算实际密钥的密钥参数,产生SKEYID，SKEYID才会作为后续IKE 消息的加密和验证,以及作为 IKE阶段二计算和产生真正 IPSec 加解密的密钥参数。
-
IPSec VPN 隧道建立流程
-
第一阶段:协商并建立IKE SA。第一阶段采用 DH 算法在不传递密钥的情况下进行双方共享密钥一致性的检查，完成身份验证，并建立起IKE SA
-
第二阶段:在IKE SA 的保护下，进行IPSec SA 的协商。IPSec SA 定义的保护方案用于保护数据传输
IPSec处理流程
-
-
出站流程:
-
1.数据包到达出接口，查找IPsec策略(SPD)
-
丢弃 ;
-
旁路安全策略:直接转发 ;
-
需要提供安全服务:下一步;
-
-
2.根据IPsec策略(SAD)查找对应IPsec SA
-
找到则执行对应安全服务,并进行转发
-
未找到则需要为其创建一个IPSecSA去查找IKE SA,下一步;
-
-
3.查找IKE SA
-
找到则在IKE SA的保护下创建IPsec SA，并执行安全服务
-
未找到则创建IKE SA
-
-
4.创建IKE SA之后，在IKE SA的保护下，创建IPsec SA，并执行安全服务
-
-
入站流程:
-
1.数据包到达入接口,检查目的地址是否为本地
-
不是则转发,是则进行下一步
-
-
2.查看该数据是否被IPsec保护
-
否则直接交由上层处理,是则查找对应IPsec SA,下一步
-
-
3.查找IPsec SA
-
未找到则丢弃数据包
-
找到则使用IPsec SA解开封装，获得原始数据
-
-
4.查看IP包目的地址是否为本地
-
是则交由上层处理,不是则转发
-
-
IPSec VPN 与 NAT 的问题
-
NAT和IPSec在同一台设备部署:NAT地址排除
-
-
NAT 会优先IPsec 生效，所以我们需要进行 NAT 地址排除，把站点之间需要互访的内网流量从 NAT 中通过 ACL排除。
-
-
存在的问题:IPSecVPN与NAT是天然有冲突的技术。NAT的某些类型中,不仅需要更改源目IP 地址，还需要更改源目端回信息。而 IPSec 是三层技术,只封装新的IP头部，原始报文的传输层头部成为了数据载荷的一部分而无法被 NAT识别,导致NAT 无法处理 IPSec 封装的报文
-
AH协议,无论是传输模式还是隧道模式,都验证整个数据包,经过NAT修改后必然破坏数据包完整性,无法通过对端验证
-
ESP协议认证范围不包括外部IP报文头,因此NAT转换时不会破坏数据包的完整性,但是ESP具有加密功能,会对TCP/UDP报文进行加密,导致NAT设备无法修改端口,因此无法共存;需要增加额外的端口实现
-
-
解决方法是开启 NAT 穿透(NAT-T),并选择 ESR 封装协议。
-
开启NAT穿越功能后，VPN网关会探测NAT设备，当检测到NAT设备时，IPSec 会在ESP 头部和外层IP 头部之间封装上一个 UDR4500 端口的传输层头部使 NAT可以处理该报文，NAT穿越默认激活无需额外配置。
-
这样，不管是传输模式还是隧道模式，IPsec报文中都有不用加密和验证的IP报文头和UDP报文头，当IPsec报文到达NAT设备时，NAT设备即可修改其IP报文头和UDP报文头中的IP地址和端口。
-
配置 NAT穿越的注意事项:需要使用ESP,隧道模式
-
-
-
什么情况下 IPSec 需要穿越 NAT?不同的设备部署,穿越NAT的场景:IPSec处理完还要经过NAT转换
-
-
如果 VPN 设备单臂部署在内网，当私网报文在 VPN 设备完成封装后，需要发往公网出口设备进行 NAPT地址转换后才能进入公网。即 IPSec VPN 设备穿越一个 NAT 设备与对端建立 IPSec VPN 的场景
-
IPSec 建立过程中如何判断网络中是否存在NAT设备
NAT穿越怎么判断是用UDP4500还是用UDP500封装?(NAT-D)
-
IKE中使用 NAT-D(NAT Discovery)载荷用于探测两个IKE 实体之间是否存在NAT
-
协商双方各自向对端发送自己的IP 地址和端口的散列值，对端通过对收到的 IP 和端口进行散列计算，如果计算结果和收到的散列值相同，则表明中间路径无 NAT，如果散列结果不同，则表明中间路径有NAT 存在，若存在 NAT则进行 NAT 穿越的封装
-
H3C设备在协商阶段会自动检测隧道两端设备中间是否存在NAT设备，如果有则开危NAT穿越功能，采用UDP报文进行封装。
-
具体流程
-
开启NAT穿越功能后，IKEv1协商的第一阶段会互相发送标识NAT穿越功能的Vendor ID载荷，用于确认彼此是否支持NAT穿越功能。
-
主模式消息3和消息4中发送NAT-D ( NAT Discovery )载荷。NAT-D载荷用于探测两个要建立IPSec隧道的网关之间是否存在NAT设备以及NAT设备的位置。
-
Remote HASH: 指将发送报文中的目的IP地址和端口号进行HASH运算后的数值。
-
Local HASH: 指将发送报文中的源IP地址和端口号进行HASH运算后的数值。
-
通过对比Remote HASH和Local HASH值，可以判断网关之间是否存在NAT设备以及NAT网关的位置。
-
-
发现NAT设备后，后续ISAKMP消息(主模式从消息5开始)的端口号转换为4500。
GRE over IPSec VPN 的技术原理
over:在里面的意思,谁在前面就先封装谁
-
GRE over IPSec和 IPSec over GRE的区别
-
GRE over IPSec VPN 是使用 IPSec 来保护 GRE 隧道中的数据，所以是先封装GRE,再封装 IPSec、并且是对 GRE 上所有的流量进行保护处理。
-
原理:
-
数据包先发往Tunnel口封装GRE，再发往公网口封装IPsec
-
必须有到达对端私网的路由指向Tunnel口
-
定义的感兴趣流就是建立 GRE 隧道的源和目标IP地址(让经过GRE封装的数据包能够再进行IPSec处理)
-
IPSec 的策略对等体是建立 GRE 隧道的目标 IP 地址
-
IPSec的策略应用在公网的接口上(数据包先进入GRE口再到公网口)
-
-
工作流程
-
1.私网报文到达 VPN设备，匹配到私网路由，数据包发往 Tunnel 口(将私网路由指向Tunnel口)
-
2.私网数据包在 Tunnel 口进行 GRE 封装，封装的新的IP 头部的目的和源是对端的环回口地址和本端的环回口地址(或者是公网的出站接口地址和对端的公网口接口地址)
-
3.对一次封装的数据包再次查询路由表，配到默认路由，把数据包发往公网接口
-
4.GRE 的数据包在公网口匹配到IPSec 的感兴趣流,再进行 IPSec VPN 的封装，封装上公网IP 头部，把数据包发出到公网
-
-
GRE over IPSec VPN建立的地址和模式选择
-
GRE over IPSec VPN可以基于公网接口建立也可以基于loopback接口建立,但都要保证公网接口可达和loopback口可达
-
GRE over IPsec VPN,如果是基于公网物理接口地址建立的，建议使用传输模式。可以节约开销
-
loopback口建立就不能用传输模式,loopback口不可达,必须要隧道模式
-
双方地址都固定的场景,可以直接基于公网物理接口建立,并且采用传输模式;本身地址可达对数据部分做保护就行
-
双方地址有一端不固定的场景,可以基于Loopback接口建立,并且采用隧道模式;借助隧道模式实现站点的可达
-
-
GRE over IPSec VPN 的报文封装过程
-
GRE 封装的目的和源设置为Loopback 口的原因:
-
GRE的封装可以采用物理接口，也可以采用loopback接口，只要保证这些地址的可达性，loopback 更加稳定。
-
GRE的封装并不用于公网传输，公网封装由IPSec 完成，GRE 封装之后需要把数据包交由IPSec完成后续处理，所以GRE的目的和源其实是 VPN设备任何接口的地址都无所谓，只要保证与IPSec 感兴趣流能匹配就可以了为了稳定性和统一标识，一般就使用 Loopback 口
-
-
注意:不要把Tunnel口中的目的和源宣告进路由协议
IPSec over GRE VPN 的技术原理
-
IPSec over GRE VPN 是使用 GRE隧道来传输被IPSec 保护的数据，所以是先封装 IPSec,再封装 GRE。只对定义的需要保护的特定流量进行保护处理
-
原理:
-
数据包先在Tunnel口通过感兴趣流封装IPsec，再进入Tunnel口封装GRE
-
IPSec定义的感兴趣是两端私网地址
-
IPSec 策略是应用在 GRE的Tunnel 接口
-
在Tunnel口上配置公网地址作为目的和源
-
IPSec 策略对等体指定的是对端GRE,隧道的Tunnel地址(让封装过IPSec的包匹配到Tunnel口,再次GRE封装)
-
-
工作流程:
-
1.私网报文到达 VPN 设备，匹配私网路由，数据包发往 Tunnel 口(将私网路由指向Tunnel口)
-
2.在 Tunnel 口上下发了 IPSec 策略，IPSec 会通过感兴趣流抓取到私网数据包，进行 IPSec 封装,封装的新IP 头部的目的和源是两端Tunnel 口的地址(让封装好的数据报再匹配到Tunnel口)
-
3.经过 IPSec 封装之后路由器再次查询路由表，匹配到 Tunnel口的直连路由，数据包再次进入Tunnel 口。由于此时数据包的源目地址已经不再是私有地址，所以不会再次被IPSec 感兴趣流命中，而是直接进入Tunnel 口进行 GRE 封装，封装上公网地址
-
4.再次查询路由表，匹配到缺省路由，把数据包发往公网
GRE over IPSec VPN 和 IPSec over GRE VPN 的应用场景
-
GRE over IPsec VPN:
-
需要支持组播流量的场景:
-
IPSec本身不支持组播，而GRE隧道可以传输组播流量
-
典型用例：分支与总部间运行动态路由协议(如OSPF)
-
-
需要加密所有隧道流量的场景
-
企业希望对分支与总部之间所有互访流量进行端到端保护;适用于安全要求高的环境，如金融、政府机构
-
-
一端使用动态公网IP的场景
-
当VPN设备一端是固定IP，另一端是动态IP
-
因为GRE隧道可以保持连接，而IPSec提供安全保护
-
-
需要传输非IP协议的场景
-
GRE可以封装IPX、AppleTalk等非IP协议
-
-
分支与总部通过公网建立通信,包括组播通信
-
企业希望对分支与总部之间互访的流量进行安全保护
-
由于组播数据无法直接应用IPSec,所以基于虚拟隧道的方式建立GRE over IPSec
-
对tunnel接口下的流量进行保护
-
-
IPSec over GRE VPN:
-
需要选择性加密的场景
-
两个公司间只有特定网段需要加密，其他流量明文传输
-
-
需要减少加密开销的场景
-
对性能敏感的应用，只加密关键业务流量;非敏感流量(如视频会议)不加密以提高性能
-
-
特殊路由需求场景
-
当IPSec隧道端点与GRE隧道端点不在同一设备时,需要更灵活的路由控制
-
-
-
选择因素 GRE over IPSec IPSec over GRE 加密范围 全隧道加密 选择性加密 协议支持 支持非IP协议和组播 仅限IP单播 端点类型 支持动态IP一端 要求两端固定IP 路由协议 支持运行动态路由 不适合运行动态路由 性能考虑 所有流量加密开销大 可减少加密开销 -
对于 VPN 设备两端都是固定地址的场景，可以根据需要选择使用 GRE over IPSec VPN 或 IPSec over GRE VPN
-
对于 VPN 设备一端地址不固定的场景，需要使用GRE over IPSec VPN
IPSec over GRE 和GRE over IPSec的区别
-
封装顺序:
-
GRE over IPSec：先GRE封装，再IPSec封装
-
IPSec over GRE：先IPSec封装，再GRE封装
-
-
保护范围:
-
GRE over IPSec：保护GRE隧道中的所有流量
-
IPSec over GRE：只保护特定的感兴趣流量
-
-
对比
-
特性 GRE over IPSec IPSec over GRE 封装顺序 1. 先GRE封装 2. 后IPSec封装 1. 先IPSec封装 2. 后GRE封装 保护范围 保护整个GRE隧道中的所有流量 只保护特定的感兴趣流量 IPSec策略位置 应用在物理公网接口 应用在Tunnel接口 感兴趣流定义 GRE隧道的端点地址 需要保护的私网地址 IPSec对等体 对端GRE隧道目标IP(通常是公网IP) 对端Tunnel接口地址 路由指向 私网路由指向Tunnel口 私网路由指向Tunnel口 适用场景 需要保护GRE隧道中所有流量时 需要选择性保护特定流量时 -
GRE over IPSec更为常见，因为它提供了对GRE隧道的全面保护。
GRE与IPSec VPN 的对比
-
GRE VPN:
-
优点:简单,支持组播，所以可以在隧道上运行路由协议
-
缺点:静态隧道,缺乏安全保障机制，不支持一端非固定公网IP地址的隧道建立
-
-
IPSec VPN:
-
优点:安全性高，可使用野蛮模式支持某一方非固定公网IP
-
缺点:不支持组播，配置复杂
-
一端地址固定,一端不固定的场景VPN如何建立
-
GRE over IPSec VPN
-
基于安全模板的方式建立IPSec VPN配合野蛮模式
-
ADVPNN
-
L2TP VPN
-
SSL VPN
IPSec VPN 不通的排错思路
-
可以使用 display ike sa 和 display ipsec sa 来检査是否存在 IKE SA 和 IPSec SA
-
如果 IKESA 存在，而 IPSecSA 不存在
-
说明问题出在第二阶段
-
检查第二阶段的转换集、IPSec 策略的调用和配置是否正确
-
-
如果 IKE SA 和 IPSec SA 都不存在
-
说明第一阶段有问题
-
检查第一阶段IKE 提议、预共享密钥、IKE profile 的调用和配置是否正确、IPSec 策略在接口上是否正确下发、检查用于建立 IPSec VPN 的公网地址是否可达、检查定义的 ACL 感兴趣流是否正确
-
-
如果 IPSec SA 存在，而 IKE SA 不存在
-
说明是重置 IPSec 时，错误的只重置了第一阶段，而没有重置第二阶段，需要把第二阶段也重置，重新来触发Psec隧道
-
可以使用reset ikesa 和 reset ipsec sa 来重置 ike sa 和ipsec sa
-
-
如果IPSec SA和 IKE SA 都存在，而 VPN 还是不通
-
检查感兴趣流是否匹配置正确
-
是否需要穿越 NAT 而没有开启 NAT-T;
-
如果是 IPSec 和 GRE的嵌套，还要检查私网路由是否正确;
-
如果IPSec VPN 设备与NAT 是在同一台设备完成的，检测是否进行NAT的地址排除。
-
-
-
SA都有但是ping不通
-
无限封装问题
-
防火墙问题
-
IPSec VPN能通，但是无法访问网页是什么原因
SA都有,ping得到,但是业务不可达
-
MTU 问题，IPSec VPN 隧道连通后，用 Ping 测试能通，因为 Ping 包一般比较小，所以就算 MTU有问题也不会因为分片问题而导致不同;
-
而访问网页时，由于数据包可能会很大，达到 MTU最大值，所以如果 MTU 设置有问题，将导致无法正常访问网页
-
可能由于有关于 HTTP 或 HTTPS 协议的 ACL 过滤
-
可能由于是网页服务器本身的原因
IPSec的保活机制
-
IPSec本身会周期性通过 Keepalive 进行保活
-
DPD(称为失效对等体检测)技术也可以用于IPSec 的保活。当启用 DPD后如果长时间接收不到对端的报文时，就能触发DPD查询，主动向对端发送请求报文,对IKE Peer 是否存活进行检测。相对于IPSec 中原有的周期性 Keepalive DPD 流量小，检测及时，隧道恢复快，所以更常用
-
对等体存在正常的流量交互时，不进行 DPD 检测
-
不等体之间没有报义要发送时，不进行 DPD 检测
-
当本地发送的数据,在一定时间之内，对方没有回复时，本地才主动向对方发送 DPD 检测
-
IPSec VPN 和 GREVPN 各自有什么特点
-
IPSec 的主要使用特点在于:
-
对指定的部分数据进行加密。
-
aggressive 模式可以支持通信双方有一方是动态获得地址的方式。
-
IPSec 支持 NAT 穿越。
-
不支持在 IPSec 隧道上运行动态路由协议。
-
对没使用硬件加密方式的低端路由器的 CPU 压力较大。
-
-
GRE 的主要使用特点在于:
-
在 GRE 隧道上支持动态路由。
-
常用的点到点 GRE 隧道方式不能支持通信一方为动态获得地址的方式。(P2MP 方式例外，只有部分设备支持)
-
仅支持静态 NAT 方式。
-
所有数据使用明文传输。
-
大规模 IPSec VPN 的拓扑设计
-
IPSec VPN网络拓扑结构选择
-
全网状连接
-
部分网状连接
-
星形连接
-
分层的星形连接
-
-
全网状，任意的两个站点之间都建立独立的IPSec VPN 隧道。优点是所有站点之间的通讯都具有最短路径、隧道具有最高的冗余可靠性，缺点是隧道数量巨大，对 VPN 设备会带来极大性能负担，配置和维护难度较大
-
部分网状:站点之间的隧道连接可以只在有需要时建立，可大幅减少同时存在的隧道数量，降低设备性能负担;但是需要支持动态 VPN 技术
-
星型连接;所有站点都只与一个核心站点建立隧道，任意两个站点之间的通讯都要经过核心站点中转。优点是结构简单，隧道数量少;缺点是核心站点性能压力巨大，且容易造成单点故障
-
分层的星型连接:引入经典网络分层的概念将 VPN 网络分为核心、汇聚和接入。核心站点只与汇聚站点建立隧道，接入站点只与汇聚站点建立隧道。有效缓解了核心站点的转发压力和配置复杂性。
隧道的两端能否都采用模版的方式来完成
-
不能两端都基于模板的方式来完成 IPSec VPN 的建立。
-
配置模板的这一端无法主动发起 VPN 的连接，只能被动接受远端发起的连接
SSL VPN的三种接入方式
-
Web 接入:也称为无客户端模式，由VPN设备来完成 Web 源码解析，远程用户通过请求 VPN 设备来访问 Web 资源。该接入方式只支持访问基于 Web 的应用和服务，远程用户可以直接通过浏览器发起连接，主要支持HTTP和CIFS文件共享运用
-
TCP 接入:也称为端口转发，需要在客户端上安装 TCP 控件。该控件会抓取远程用户访问 VPN 内网的 TCP 请求，进行 SSL 公网封装，再与内网进行通讯。该接入方式只支持基于 TCP 的应用和服务。
-
IP 接入:也称为 tunnelmode 或者 ful tunnelclient,需要在客户端上安装 VPN客户端软件,在客户端上安装虚拟网卡,由 VPN 客户端软件发起到 SSL VPN 服务端的连接，连接成功之后，VPN 服务端会为连接成功的 VPN 客户分配一个私网地址，然后在客户端本地产生到达 VPN内网资源的静态路由，出接口指问虚拟网卡，由虚拟网卡完成SSL公网封装，使用获取的私有地址再与内网进行通讯。该接入方式支持所有基于TCP/UDP/CMP 的应用和服务,支持所有IP协议
SSL VPN的部署模式
-
直连模式
-
网关跨接再内网和外网之间
-
优点:网关可以全面地保护内网,对内网之间的所有通信数据进行管理和控制
-
缺点:网关成为整个内网出口的性能瓶颈;网关的可靠性也关系到整个内网访问外网通讯的稳定性
-
-
旁路模式:
-
网关设备部署于内网，代理远程主机对内网服务器的访问。
-
优点:网关的处理能力不会成为整个内网访问外网的性能瓶颈，网关的临时故障也不会影响到整个内网对外网的访问。
-
缺点:网关设备不能全面地保护内部网络，只能对部分网络流量进行管理和控制
-
VPN的部署模式
-
双臂模式:又称网关模式，是指把 VPN部署在互联网出口设备上。由于作为企业出口，所以需要具备高度的稳定性和可靠性。此方案使用小型网络
-
单臂模式:也称为旁挂模式，是把 VPN 部署在内网，不在网络通讯的必经之路上。好处是其性能不会影响内外网的通讯。而且如果 VPN 设备出现问题,不会影响整个网络访问外部的连通性。但是需要在互联网出口设备上对 VPN 做端口映射
L2TP VPN的两种拓扑结构
-
独立 LAC 结构:由运营商提供LAC设备，用户端通过 PPP 或 PPPOE 拨号至运营商的 LAC,来触发 LAC 与 LNS 建立隧道
-
由于可能存在多个用户 PPP 或 PPPoE 拨入 LAC,但 LAC 和 LNS 只建立一条隧道，所以隧道中需要通过 Session ID 来区分不同用户
-
当第一个用户拨入时，LAC与 LNS 建立隧道，并创建第一个Session,后续再有用户拨入,只在当前隧道中建立Session;
-
当某个用户结束L2TP 连接时,LAC 和 LNS 结束该用户的 Session,当隧道中最后一个 Session 被结束时隧道也会断开
-
独立 LAC 模式，客户端可以不具备 IP连通性，也可以接入 L2TP VPN
-
-
客户 LAC 结构:用户使用自己的 LAC 与 LNS 建立隧道。用户的 LAC 可以是 PC终端，也可以是具备 L2TP 接入功能的路由器或 VPN 等设备
-
由于用户使用自己的 LAC 设备，所以对于 VPN 接入的地点和上网方式没有限制，不依赖运营商的接入
-
用户的终端设备比较复杂
-
客户 LAC 模式需要客户端具备IP 连通性，才能发起到 L2TP VPN 的连接
-
客户端可以使用微软自带的L2TP终端,或者安装客户端软件即可实现L2TPVPN 的拨入。
-
L2TP over IPSec VPN
-
L2TP VPN 本身没有任何安全机制，不加密，不做严格身份验证，所以一般会嵌套IPSec 来使用
-
私网报文先通过私网路由匹配进L2TP隧道，被L2TP 封装后，再交给IPSec 抓取进行安全封装后发往公网
-
建议使用传输模式,本身业务可达
-
-
L2TP overIPSec报文封装和隧道协商过程
L2TP VPN 的工作原理
-
L2TP VPN 是在 LAC 和 LNS 之间建立的隧道
-
L2TP VPN 是一种 Acces VPN,用于终端设备直接在公网上与公司网络建立隧道需要在终端上进行用户名和密码的认证才能成功连通
-
L2TP VPN是一种二层 VPN,由PPP或PPPOE 触发，私网报文先匹配私网路由进入到 L2TP 隧道，进行PPP 封装后发送至 LAC,LAC 把该帧传递给 L2TP 协议给该报文添加一个L2TP头部，再封装一个UDP 头部，最后再封装上公网IP头部后传递至公网，把报文发往LNS
SSL VPN 的配置步骤主要包含哪些
-
配置 SSL VPN 网关
-
配置 IP 接入服务
-
配置用于IP 接入服务的 SSL VPN AC 接口
-
配置分配给 IP 接入用户的地址池
-
配置 SSL VPN 访问实例的 IP 接入参数
-
为 IP 接入配置 SSL VPN 策略组
-
如果站点两边都采用动态地址接入的情况，要如何实现IPSec VPN 的架设
-
一种可能的解决方案是使用动态域名系统(DDNS)来为两端的路由器分配个固定的域名，然后在配置IPSec 隧道时，使用域名作为对等体的标识，而不是IP地址。这样，当一端的 IP地址变更时，可以通过 DDNS 更新域名对应的IP地址，实现动态IPSec VPN 的建立。
-
这种方法的一个优点是可以从两端任囊一端启动隧道，而不需要等待对方发起连接。
-
这种方法的一个缺点是需要在两端都配置 DDNS 客户端，并且需要一个可靠的 DDNS 服务提供商，同时需要支付 DDNS 的维护费用。
-
-
还有一种可能方案是采用 ADVPN技术,ADVPN(自动发现虚拟专用网络)是一种基于VAM(VPN 地址管理)协议的动态 VPN技术。ADVPN 的核心思想是VAM cient 从自动建立 Hub-Spoke 永久隧道VAM sever 获取目标 VAM client 的公网地址，以及 Spoke-spoke 动态隧道。spoke-Spoke 隧道仅在 Spoke 之间有数据交互时建立，当 Spoke之间没有数据交互时，自动删除隧道，从而避免设备维护大量闲置的隧道表项，有效地提高了设备资源的利用率。
SSLVPN 的接入方式有哪些
-
SSLVPN 提供了Web 接入、TCP 接入、IP 接入三种接入方式。
-
Web 接入对返回 Web 页面中的 URL进行改写，使得远程用户在公网上可以访问到私网中的 URL。
-
-
TCP 接入在远程主机上安装一个 VPN 客户端，以代理方式与 SSL VPN 网关建立 SSL连接，SSLPN 网关再以代理方式与服务器端建立 TCP 连接。
-
IP 接入在远程主机上安装一个虚拟网卡,配上内网的IP 地址和可以访问内网的路由。远程主机与内网服务器之间传送的数据报文通过路由进行IP 层的转发:
