ipsec跨厂商对接之华为防火墙对接华三路由器
dis cu
#
version 7.1.064, Release 0707P16
#
sysname H3cRouter
#
password-recovery enable
#
vlan 1
#
controller Cellular0/0
#
interface NULL0
#
interface Ethernet0/3
port link-mode bridge
#
interface Ethernet0/4
port link-mode bridge
#
interface Ethernet0/5
port link-mode bridge
#
interface Ethernet0/6
port link-mode bridge
#
interface Ethernet0/7
port link-mode bridge
#
interface Ethernet0/8
port link-mode bridge
#
interface Ethernet0/9
port link-mode bridge
#
interface Ethernet0/10
port link-mode bridge
#
interface Ethernet0/11
port link-mode bridge
#
interface Ethernet0/12
port link-mode bridge
#
interface Ethernet0/13
port link-mode bridge
#
interface Ethernet0/14
port link-mode bridge
#
interface Ethernet0/15
port link-mode bridge
#
interface Ethernet0/16
port link-mode bridge
#
interface Ethernet0/17
port link-mode bridge
#
interface Ethernet0/18
port link-mode bridge
#
interface Ethernet0/19
port link-mode bridge
#
interface Ethernet0/20
port link-mode bridge
#
interface Ethernet0/21
port link-mode bridge
interface Ethernet0/22
port link-mode bridge
#
interface Ethernet0/23
port link-mode bridge
#
interface Ethernet0/24
port link-mode bridge
#
interface Ethernet0/25
port link-mode bridge
#
interface Ethernet0/26
port link-mode bridge
#
interface GigabitEthernet0/0
port link-mode route
#
interface GigabitEthernet0/1
port link-mode route
description Link-to-互联网
ip address 117.32.3.10 255.255.255.0
ipsec apply policy map1
#
interface GigabitEthernet0/2
port link-mode route
description Link-to-CQfenzhi
ip address 192.168.10.1 255.255.255.0
#
interface GigabitEthernet0/27
port link-mode route
#
scheduler logfile size 16
#
line class console
user-role network-admin
#
line class tty
user-role network-operator
#
line class vty
user-role network-operator
#
line con 0
user-role network-admin
line vty 0 63
user-role network-operator
#
ip route-static 172.16.10.0 24 GigabitEthernet0/1 117.32.3.1
#
acl advanced name ipsecvpn
rule 0 permit ip source 192.168.10.0 0.0.0.255 destination 172.16.10.0 0.0.0.255
#
domain system
#
domain default enable system
#
role name level-0
description Predefined level-0 role
#
role name level-1
description Predefined level-1 role
#
role name level-2
description Predefined level-2 role
#
role name level-3
description Predefined level-3 role
#
role name level-4
description Predefined level-4 role
#
role name level-5
description Predefined level-5 role
#
role name level-6
description Predefined level-6 role
#
role name level-7
description Predefined level-7 role
#
role name level-8
description Predefined level-8 role
#
role name level-9
description Predefined level-9 role
#
role name level-10
description Predefined level-10 role
#
role name level-11
description Predefined level-11 role
#
role name level-12
description Predefined level-12 role
#
role name level-13
description Predefined level-13 role
#
role name level-14
description Predefined level-14 role
#
user-group system
#
ipsec transform-set tran1
esp encryption-algorithm 3des-cbc
esp authentication-algorithm sha1
#
ipsec policy map1 10 isakmp
transform-set tran1
security acl name ipsecvpn
remote-address 117.32.3.1
ike-profile pro1
ike profile pro1
keychain key1
local-identity address 117.32.3.10
match remote identity address 117.32.3.1 255.255.255.0
match local address GigabitEthernet0/1
proposal 1
#
ike proposal 1
encryption-algorithm 3des-cbc
dh group2
#
ike keychain key1
pre-shared-key address 117.32.3.1 255.255.255.255 key cipher $c$3$GD+omtunVL9VumRP59L4sNTDY1373vZ5OIA=
#
return
dis ipsec sa
Interface: GigabitEthernet0/1
IPsec policy: map1
Sequence number: 10
Mode: ISAKMP
Tunnel id: 0
Encapsulation mode: tunnel
Perfect Forward Secrecy:
Inside VPN:
Extended Sequence Numbers enable: N
Traffic Flow Confidentiality enable: N
Path MTU: 1444
Tunnel:
local address: 117.32.3.10
remote address: 117.32.3.1
Flow:
sour addr: 192.168.10.0/255.255.255.0 port: 0 protocol: ip
dest addr: 172.16.10.0/255.255.255.0 port: 0 protocol: ip
[Inbound ESP SAs]
SPI: 4103859656 (0xf49bedc8)
Connection ID: 30064771074
Transform set: ESP-ENCRYPT-3DES-CBC ESP-AUTH-SHA1
SA duration (kilobytes/sec): 1843200/3600
SA remaining duration (kilobytes/sec): 1843192/3470
Max received sequence-number: 128
Anti-replay check enable: Y
Anti-replay window size: 64
UDP encapsulation used for NAT traversal: N
Status: Active
[Outbound ESP SAs]
SPI: 195769074 (0x0bab32f2)
Connection ID: 21474836483
Transform set: ESP-ENCRYPT-3DES-CBC ESP-AUTH-SHA1
SA duration (kilobytes/sec): 1843200/3600
SA remaining duration (kilobytes/sec): 1843192/3470
Max sent sequence-number: 127
UDP encapsulation used for NAT traversal: N
Status: Activedis ike sa ver
Connection ID: 153
Outside VPN:
Inside VPN:
Profile: pro1
Transmitting entity: Responder
Initiator cookie: e3972a5e96e4f9ab
Responder cookie: e45ac98115a824f5
Local IP: 117.32.3.10
Local ID type: IPV4_ADDR
Local ID: 117.32.3.10
Remote IP: 117.32.3.1
Remote ID type: IPV4_ADDR
Remote ID: 117.32.3.1
Authentication-method: PRE-SHARED-KEY
Authentication-algorithm: SHA1
Encryption-algorithm: 3DES-CBC
Life duration(sec): 86400
Remaining key duration(sec): 86262
Exchange-mode: Main
Diffie-Hellman group: Group 2
NAT traversal: Not detected
Extend authentication: Disabled
Assigned IP address:
Vendor ID index:0xffffffff
Vendor ID sequence number:0x0
dis ipsec sa ?
Redirect it to a fileRedirect it to a file in append modebrief Display brief information about all IPsec SAs
count Display SA count
interface Specify an interface
ipv6-policy Specify an IPv6 IPsec policy
policy Specify an IPv4 IPsec policy
profile Specify an IPsec profile
remote Specify a remote peer
| Matching output
dis ipsec sa bri
dis ipsec sa brief
Interface/Global Dst Address SPI Protocol Status
GE0/1 117.32.3.1 195769074 ESP Active
GE0/1 117.32.3.10 4103859656 ESP Active
dis cu
2025-09-21 11:55:39.460 +08:00
!Software Version V500R005C20SPC500
#
sysname HuaweiFW
#
l2tp enable
l2tp domain suffix-separator @
#
authentication-profile name portal_authen_default
#
undo factory-configuration prohibit
#
undo telnet server enable
undo telnet ipv6 server enable
#
clock timezone Beijing add 08:00:00
#
update schedule location-sdb weekly Sun 06:15
#
firewall defend action discard
#
log type traffic enable
log type syslog enable
log type policy enable
#
undo dataflow enable
#
undo sa force-detection enable
#
banner enable
#
user-manage web-authentication security port 8887
undo privacy-statement english
undo privacy-statement chinese
page-setting
user-manage security version tlsv1.1 tlsv1.2
password-policy
level high
#
firewall ids authentication type aes256
#
web-manager security version tlsv1.1 tlsv1.2
web-manager enable
web-manager security enable
undo web-manager config-guide enable
#
firewall dataplane to manageplane application-apperceive default-action drop
#
undo ips enhanced enable
feedback type threat-log enable
feedback type pdns enable
#
update schedule ips-sdb daily 23:21
update schedule av-sdb daily 23:21
update schedule sa-sdb daily 23:21
update schedule ip-reputation daily 23:21
update schedule cnc daily 23:21
update schedule file-reputation daily 23:21
update schedule ext-url-sdb daily 06:58
#
set disk-scan parameter attach on
set disk-scan parameter cycle 15
set disk-scan parameter iostat 80
set disk-scan parameter speed 10
set disk-scan parameter switch on
set disk-scan parameter parallel 50
disk-usage alarm threshold 95
#
ip vpn-instance default
ipv4-family
#
ip address-set 互联网接口IP type object
address 0 117.32.3.1 mask 32
#
ip address-set CQ分支机构IP type object
address 0 range 192.168.10.1 192.168.10.254
address 1 range 172.16.100.2 172.16.100.100
#
ip address-set 总部业务IP type object
address 0 range 172.16.10.1 172.16.10.254
#
ip address-set SSLVPN网络扩展资源客户端IP type object
address 0 range 172.16.200.1 172.16.200.200
#
ip address-set 感兴趣流 type object
address 0 172.16.10.0 mask 24
#
ip address-set 感兴趣流源IP_业务1 type object
address 0 172.16.10.0 mask 24
#
ip address-set 感兴趣流目的IP_业务1 type object
address 0 192.168.10.0 mask 24
#
ip address-set 建立VPN隧道的源地址 type object
address 0 117.32.3.1 mask 32
#
ip address-set 建立VPN隧道的目的地址 type object
address 0 117.32.3.10 mask 32
#
time-range worktime
period-range 08:00:00 to 18:00:00 working-day
#
acl number 3000
rule 5 permit ip source 172.16.10.0 0.0.0.255 destination 192.168.10.0 0.0.0.255
#
ipsec proposal prop21995140294
esp authentication-algorithm sha1
esp encryption-algorithm 3des
#
ike proposal default
encryption-algorithm aes-256 aes-192 aes-128
dh group14
authentication-algorithm sha2-512 sha2-384 sha2-256
authentication-method pre-share
integrity-algorithm hmac-sha2-256
prf hmac-sha2-256
ike proposal 1
encryption-algorithm 3des
dh group2
authentication-algorithm sha1
authentication-method pre-share
integrity-algorithm hmac-sha2-256
prf hmac-sha2-256
#
ike peer ike21995140294
undo version 2
pre-shared-key %^%#n};A)f~p;!$wi!q5iEIy8;fPj-dq.>eA0$_lvrI%^%# ike-proposal 1 remote-id-type none local-id 117.32.3.1 dpd type periodic remote-address 117.32.3.10 rsa encryption-padding oaep rsa signature-padding pss local-id-preference certificate enable ikev2 authentication sign-hash sha2-256 # ipsec policy ipsec2199514012 1 isakmp security acl 3000 ike-peer ike21995140294 proposal prop21995140294 tunnel local applied-interface alias IPSEC_to_H3CRouter sa trigger-mode auto sa duration traffic-based 5242880 sa duration time-based 3600 # web-auth-server default port 50100 # portal-access-profile name default # ip pool pool section 0 172.16.100.2 172.16.100.100 # aaa authentication-scheme admin_ad authentication-scheme admin_ad_local authentication-scheme admin_hwtacacs authentication-scheme admin_hwtacacs_local authentication-scheme admin_ldap authentication-scheme admin_ldap_local authentication-scheme admin_local authentication-scheme admin_radius authentication-scheme admin_radius_local authentication-scheme default authorization-scheme default accounting-scheme default domain default service-type internetaccess ssl-vpn l2tp ike internet-access mode password reference user current-domain manager-user audit-admin password cipher $1a$Vg0H:|1TH)$c/eA0.a335K6l1+u)c7*L+m%}a~.\Ep)Tt2q0($
service-type web terminal
level 15
manager-user api-admin
password cipher $1a$#Wjx+e2″l.$pBXPY2iAn!(6VYR=fk2W&O$vHL9>lW_*jJ4ywX1$$
service-type api
level 15
manager-user admin
password cipher $1a$F^d.HB)f@%$hw9N=79)Sst)5/T0a5>&$
service-type web terminal
level 15
role system-admin
role device-admin
role device-admin(monitor)
role audit-admin
bind manager-user audit-admin role audit-admin
bind manager-user admin role system-admin
#
l2tp-group default-lns
#
interface GigabitEthernet0/0/0
undo shutdown
ip binding vpn-instance default
ip address 192.168.0.1 255.255.255.0
service-manage http permit
service-manage https permit
service-manage ping permit
#
interface GigabitEthernet1/0/0
undo shutdown
ip address 10.1.1.2 255.255.255.252
service-manage ping permit
#
interface GigabitEthernet1/0/1
undo shutdown
ip address 117.32.3.1 255.255.255.0
service-manage ping permit
ipsec policy ipsec2199514012
#
interface GigabitEthernet1/0/2
undo shutdown
#
interface GigabitEthernet1/0/3
undo shutdown
#
interface GigabitEthernet1/0/4
undo shutdown
#
interface GigabitEthernet1/0/5
undo shutdown
#
interface Virtual-if0
#
interface Cellular0/0/0
#
interface NULL0
#
firewall zone local
set priority 100
#
firewall zone trust
set priority 85
add interface GigabitEthernet0/0/0
add interface GigabitEthernet1/0/0
firewall zone untrust
set priority 5
add interface GigabitEthernet1/0/1
#
firewall zone dmz
set priority 50
#
api
#
ip route-static 0.0.0.0 0.0.0.0 117.32.3.10
ip route-static 172.16.10.0 255.255.255.0 10.1.1.1
#
undo ssh server compatible-ssh1x enable
ssh authentication-type default password
#
firewall detect ftp
#
v-gateway public ssl version tlsv11 tlsv12
v-gateway public ssl public-key algorithm rsa
v-gateway public ssl ciphersuit custom aes256-sha non-des-cbc3-sha aes128-sha
v-gateway ssl-renegotiation-attack defend enable
#
user-interface con 0
authentication-mode aaa
user-interface vty 0 4
authentication-mode aaa
protocol inbound ssh
user-interface vty 16 20
#
pki realm default
#
sa
#
location
#
multi-interface
mode proportion-of-weight
#
right-manager server-group
#
agile-network
#
IoT
#
network-scan
network-scan timeout per-asset 300
network-scan timeout entire-scan 23
conflict-resolve override
#
device-classification
device-group pc
device-group mobile-terminal
device-group undefined-group
#
user-manage single-sign-on ad
user-manage single-sign-on tsm
user-manage single-sign-on radius
user-manage auto-sync online-user
user-manage server-sync tsm
#
security-policy
rule name 允许感兴趣流从本端出防火墙
source-zone trust
destination-zone untrust
source-address address-set 感兴趣流源IP_业务1
destination-address address-set 感兴趣流目的IP_业务1
action permit
rule name 允许感兴趣流从对端进防火墙
source-zone untrust
destination-zone trust
source-address address-set 感兴趣流目的IP_业务1
destination-address address-set 感兴趣流源IP_业务1
action permit
rule name 允许防火墙发起IPSEC隧道建立
source-zone local
destination-zone untrust
source-address address-set 建立VPN隧道的源地址
destination-address address-set 建立VPN隧道的目的地址
action permit
rule name 允许防火墙接受IPSEC隧道建立
source-zone untrust
destination-zone local
source-address address-set 建立VPN隧道的目的地址
destination-address address-set 建立VPN隧道的源地址
action permit
#
auth-policy
#
traffic-policy
#
policy-based-route
#
nat-policy
#
proxy-policy
quota-policy
#
pcp-policy
#
dns-transparent-policy
mode based-on-multi-interface
#
rightm-policy
#
flow-probe-policy
#
mac-access-profile name mac_access_profile
#
return
dis ike sa
2025-09-21 11:55:54.610 +08:00
IKE SA information :
Conn-ID Peer VPN Flag(s) Phase RemoteType RemoteID
581 117.32.3.10/500 RD|ST|A v1:2 IP 117.32.3.10
580 117.32.3.10/500 RD|ST|A v1:1 IP 117.32.3.10
Number of IKE SA : 2
Flag Description:
RD–READY ST–STAYALIVE RL–REPLACED FD–FADING TO–TIMEOUT
HRT–HEARTBEAT LKG–LAST KNOWN GOOD SEQ NO. BCK–BACKED UP
M–ACTIVE S–STANDBY A–ALONE NEG–NEGOTIATING
dis ike sa ver
^
Error:Incomplete command found at ‘^’ position.
dis ike sa ?
all-systems All the systems
business-group Business group
remote Remote address
remote-id Set remote id
remote-id-type Set peer ID type
verbose Display detailed information
vsys Virtual system
dis ike sa verb
dis ike sa verbose
^
Error:Incomplete command found at ‘^’ position.
dis ike sa verbose ?
connection-id SA connection ID
remote Remote address
remote-id Set remote id
remote-id-type Set peer ID type
dis ike sa verbose re
dis ike sa verbose remote?
remote remote-id
remote-id-type
dis ike sa verbose remote ?
X.X.X.X Remote IPv4 address
X:X::X:X Remote IPv6 address
dis ike sa verbose remote 117.32.3.10
2025-09-21 11:56:28.830 +08:00
Ike sa verbose information :
Ike Sa phase : 2
Establish Time : 2025-09-21 11:51:54
PortCfg Index : 0x8
IKE Peer Name : ike21995140294
Connection Id : 581
Version : v1
Flow VPN :
Peer VPN :
Initiator Cookie : 0xe3972a5e96e4f9ab
Responder Cookie : 0xe45ac98115a824f5
Local Address : 117.32.3.1/500
Remote Address : 117.32.3.10/500
PFS :
Flags : RD|ST|A
Ike Sa phase : 1
Establish Time : 2025-09-21 11:51:54
PortCfg Index : 0x8
IKE Peer Name : ike21995140294
Connection Id : 580
Version : v1
Exchange Mode : Main
Flow VPN :
Peer VPN :
Initiator Cookie : 0xe3972a5e96e4f9ab
Responder Cookie : 0xe45ac98115a824f5
Local Address : 117.32.3.1/500
Remote Address : 117.32.3.10/500
Encryption Algorithm : 3DES-CBC
Authentication Algorithm : SHA1
Authentication Method : Pre-Shared key
DPD Capability : Yes
DPD Enable : Yes
DPD Message Learning Enable : Yes
DPD Message Format : Seq-Hash-Notify
SA Remaining Soft Timeout (sec) : 77486
SA Remaining Hard Timeout (sec) : 86126
Reference Counter : 1
Flags : RD|ST|A
Remote Id Type : IP
Remote Id : 117.32.3.10
DH Group : 2
NAT Traversal Version : RFC3947
ModeCfg IP : –
Number of IKE SA : 2
Flag Description:
RD–READY ST–STAYALIVE RL–REPLACED FD–FADING TO–TIMEOUT
HRT–HEARTBEAT LKG–LAST KNOWN GOOD SEQ NO. BCK–BACKED UP
M–ACTIVE S–STANDBY A–ALONE NEG–NEGOTIATING
dis ipsec sa
2025-09-21 11:56:39.490 +08:00
ipsec sa information:
===============================
Interface: GigabitEthernet1/0/1
IPSec policy name: “ipsec2199514012”
Sequence number : 1
Acl group : 3000/IPv4
Acl rule : 5
Mode : ISAKMP
Connection ID : 581
Encapsulation mode: Tunnel
Holding time : 0d 0h 4m 44s
Tunnel local : 117.32.3.1/500
Tunnel remote : 117.32.3.10/500
Flow source : 172.16.10.0/255.255.255.0 0/0-65535
Flow destination : 192.168.10.0/255.255.255.0 0/0-65535
[Outbound ESP SAs]
SPI: 4103859656 (0xf49bedc8)
Proposal: ESP-ENCRYPT-3DES-192 ESP-AUTH-SHA1
SA remaining soft duration (kilobytes/sec): 1658864/2957
SA remaining hard duration (kilobytes/sec): 1843184/3316
Max sent sequence-number: 280
UDP encapsulation used for NAT traversal: N
SA encrypted packets (number/bytes): 279/16740
[Inbound ESP SAs]
SPI: 195769074 (0xbab32f2)
Proposal: ESP-ENCRYPT-3DES-192 ESP-AUTH-SHA1
SA remaining soft duration (kilobytes/sec): 1658864/2957
SA remaining hard duration (kilobytes/sec): 1843184/3316
Max received sequence-number: 256
UDP encapsulation used for NAT traversal: N
SA decrypted packets (number/bytes): 279/16740
Anti-replay : Enable
Anti-replay window size: 1024
VPN的应用场景及选择
VPN适用于以下基本场景，以及从以下场景中衍生的复杂场景。通过对比各种VPN的特点，可选择适合的VPN类型。
site-to-site VPN
site-to-site VPN即两个局域网之间通过VPN隧道建立连接。
如图1所示，企业的分支和总部分别通过网关1和网关2连接到Internet。出于业务需要，企业分支和总部间经常相互发送内部机密数据。为了保护这些数据在Interner中安全传输，在网关1和网关2之间建立VPN隧道。
这种场景的特点为：两端网络均通过固定的网关连接到Internet，组网相对固定。且访问是双向的，即分支和总部都有可能向对端发起访问。适用于比如连锁超市、政府机关、银行等的业务通信。
此场景可以使用以下几种VPN实现：IPSec、L2TP、L2TP over IPSec、GRE over IPSec、IPSec over GRE。
如果您的组网有以下典型特征，可根据以下几项选择相应的VPN。
- 两端相互访问较频繁，传输的数据为机密数据，且任何用户都能访问对端内网，无需认证时，可采用IPSec方式。
- 只有一端访问另一端，且访问的用户必须通过用户认证时，可采用L2TP方式。
- 如果只有一端访问另一端，传输数据为机密数据，且访问的用户必须通过用户认证，可采用L2TP over IPSec方式，安全性更高。
- GRE over IPSec隧道和IPSec over GRE隧道都可以用来安全的传输数据，两者的区别在于对数据的封装顺序不同。GRE over IPSec在报文封装时，是先GRE封装然后再IPSec封装；IPSec over GRE在报文封装时，是先IPSec封装再GRE封装。由于IPSec无法封装组播报文，因此IPSec over GRE隧道也无法传输组播数据。如果隧道两端要传输组播数据时，就要采用GRE over IPSec方式。比如，当网络1和网络2中采用RIP建立路由时，由于RIP路由数据为组播数据，需采用GRE over IPSec将RIP路由发送到对端。
各种VPN的深入介绍和配置方法请参见IPSec、L2TP VPN和GRE。不同VPN技术的特点如表1所示。
| 对比项 | IPSec | L2TP | L2TP over IPSec | GRE over IPSec | IPSec over GRE |
|---|---|---|---|---|---|
| 数据加密功能 | 支持，对隧道两端内网的需要加密的通讯数据进行加密。数据加密功能强大，支持多种对称加密方式及组合。 | 不支持。 | 支持，通过IPSec进行加密。 | 支持，通过IPSec进行加密。 | 支持，通过IPSec进行加密。 |
| 用户认证功能 | 支持。 | 支持，用户认证方式包括本地认证、RADIUS服务器认证等。LAC和LNS对用户进行双重认证，只有认证通过的用户才可访问企业内网服务器。 | 支持，通过L2TP进行用户认证。 | 不支持。 | 不支持。 |
| 对客户端的要求 | 无要求。 | 有支持PPP拨号的软件，如Windows系统自带的拨号软件。 | 与L2TP的要求相同。 | 无要求。 | 无要求。 |
| 是否支持隧道中间有NAT设备 | 支持。 | 支持。 | 支持。 | 支持。 | 不支持。 |
client-to-site VPN
client-to-site VPN即客户端与企业内网之间通过VPN隧道建立连接。
组网图如图2所示，外出差员工（客户端）跨越Internet访问企业总部内网，完成向总部传送数据、访问内部服务器等需求。为确保数据安全传输，可在客户端和企业网关之间建立VPN隧道。
这种场景的特点为：客户端的地址不固定。且访问是单向的，即只有客户端向内网服务器发起访问。适用于企业出差员工或临时办事处员工通过手机、电脑等接入总部远程办公。
此场景可以使用以下几种VPN实现：SSL、IPSec（IKEv2）、L2TP、L2TP over IPSec。
如果您的组网有以下典型特征，可根据以下几项选择相应的VPN。如果不是，则根据表2来选择：
- 如果对客户端没有要求，但是待访问的服务器要针对不同类型用户开放不同的服务、制定不同的策略等，可采取SSL方式。
- 出差员工或临时办事处员工，如果需要频繁访问某几个固定的总部服务器，且服务器功能对全部用户都开放的情况下，可采取L2TP over IPSec方式。
各种VPN的深入介绍和配置方法请参见SSL VPN、IPSec和L2TP VPN。
| 对比项 | SSL | IPSec（IKEv2） | L2TP | L2TP over IPSec |
|---|---|---|---|---|
| 数据加密功能 | 支持，只对通信双方传输的应用层数据进行加密。 | 支持，对隧道两端的所有通讯数据均进行加密。数据加密功能强大，支持多种对称加密方式及组合。 | 不支持。 | 支持，通过IPSec进行加密。 |
| 用户认证功能 | 支持，用户认证方式包括本地认证、RADIUS服务器认证、LDAP服务器认证等。 | 支持EAP认证。需要搭建第三方的认证服务器，如RADIUS服务器等。 | 支持，用户认证方式包括本地认证、RADIUS服务器认证等。 | 支持，通过L2TP进行用户认证。 |
| 对客户端的要求 | 有支持SSL协议的浏览器，如IE浏览器。客户端不需进行任何配置，只需在浏览器中输入虚拟网关IP地址或域名即可进入登录界面。 | 有支持IKEv2和EAP认证的IPSec软件，如Windows 7自带软件等。 | 有支持L2TP拨号的软件，如VPN Client软件。 | 有支持L2TP拨号和支持IPSec的软件，如VPN Client软件。 |
| 是否支持隧道中间有NAT设备 | 支持。 | 支持。 | 支持。 | 支持。 |
BGP/MPLS IP VPN
BGP/MPLS IP VPN主要用于解决跨域企业互连等问题。当前企业越来越区域化和国际化，同一企业的不同区域员工之间需要通过服务提供商网络来进行互访。服务提供商网络往往比较庞大和复杂，为严格控制用户的访问，确保数据安全传输，需在骨干网上配置BGP/MPLS IP VPN功能，实现不同区域用户之间的访问需求。
BGP/MPLS IP VPN为全网状VPN，即每个PE和其他PE之间均建立BGP/MPLS IP VPN连接。服务提供商骨干网的所有PE设备都必须支持BGP/MPLS IP VPN功能。
基本组网图如图3所示。
图3 BGP/MPLS IP VPN
IPSec简介
起源
随着Internet的发展，越来越多的企业直接通过Internet进行互联，但由于IP协议未考虑安全性，而且Internet上有大量的不可靠用户和网络设备，所以用户业务数据要穿越这些未知网络，根本无法保证数据的安全性，数据易被伪造、篡改或窃取。因此，迫切需要一种兼容IP协议的通用的网络安全方案。
为了解决上述问题，IPSec（Internet Protocol Security）应运而生。IPSec是对IP的安全性补充，其工作在IP层，为IP网络通信提供透明的安全服务。
定义
IPSec是IETF（Internet Engineering Task Force）制定的一组开放的网络安全协议。它并不是一个单独的协议，而是一系列为IP网络提供安全性的协议和服务的集合，包括认证头AH（Authentication Header）和封装安全载荷ESP（Encapsulating Security Payload）两个安全协议、密钥交换和用于验证及加密的一些算法等。
通过这些协议，在两个设备之间建立一条IPSec隧道。数据通过IPSec隧道进行转发，实现保护数据的安全性。
受益
IPSec通过加密与验证等方式，从以下几个方面保障了用户业务数据在Internet中的安全传输：
抗重放：接收方拒绝旧的或重复的数据包，防止恶意用户通过重复发送捕获到的数据包所进行的攻击。
数据来源验证：接收方验证发送方身份是否合法。
数据加密：发送方对数据进行加密，以密文的形式在Internet上传送，接收方对接收的加密数据进行解密后处理或直接转发。
数据完整性：接收方对接收的数据进行验证，以判定报文是否被篡改。
安全联盟
安全联盟SA（Security Association）是通信对等体间对某些要素的协定，它描述了对等体间如何利用安全服务（例如加密）进行安全的通信。这些要素包括对等体间使用何种安全协议、需要保护的数据流特征、对等体间传输的数据的封装模式、协议采用的加密和验证算法，以及用于数据安全转换、传输的密钥和SA的生存周期等。
IPSec安全传输数据的前提是在IPSec对等体（即运行IPSec协议的两个端点）之间成功建立安全联盟。IPSec安全联盟简称IPSec SA，由一个三元组来唯一标识，这个三元组包括安全参数索引SPI（Security Parameter Index）、目的IP地址和使用的安全协议号（AH或ESP）。其中，SPI是为唯一标识SA而生成的一个32位比特的数值，它被封装在AH和ESP头中。
IPSec SA是单向的逻辑连接，通常成对建立（Inbound和Outbound）。因此两个IPSec对等体之间的双向通信，最少需要建立一对IPSec SA形成一个安全互通的IPSec隧道，分别对两个方向的数据流进行安全保护，如图1所示。
另外，IPSec SA的个数还与安全协议相关。如果只使用AH或ESP来保护两个对等体之间的流量，则对等体之间就有两个SA，每个方向上一个。如果对等体同时使用了AH和ESP，那么对等体之间就需要四个SA，每个方向上两个，分别对应AH和ESP。
建立IPSec SA有两种方式：手工方式和IKE方式。二者的主要差异如表1所示。
| 对比项 | 手工方式建立IPSec SA | IKE方式自动建立IPSec SA |
|---|---|---|
| 加密/验证密钥配置和刷新方式 | 手工配置、刷新，而且易出错密钥管理成本很高 | 密钥通过DH算法生成、动态刷新密钥管理成本低 |
| SPI取值 | 手工配置 | 随机生成 |
| 生存周期 | 无生存周期限制，SA永久存在 | 由双方的生存周期参数控制，SA动态刷新 |
| 安全性 | 低 | 高 |
| 适用场景 | 小型网络 | 小型、中大型网络 |
安全协议
IPSec使用认证头AH（Authentication Header）和封装安全载荷ESP（Encapsulating Security Payload）两种IP传输层协议来提供认证或加密等安全服务。
- AH协议AH仅支持认证功能，不支持加密功能。AH在每一个数据包的标准IP报头后面添加一个AH报文头，如封装模式所示。AH对数据包和认证密钥进行Hash计算，接收方收到带有计算结果的数据包后，执行同样的Hash计算并与原计算结果比较，传输过程中对数据的任何更改将使计算结果无效，这样就提供了数据来源认证和数据完整性校验。AH协议的完整性验证范围为整个IP报文。
- ESP协议ESP支持认证和加密功能。ESP在每一个数据包的标准IP报头后面添加一个ESP报文头，并在数据包后面追加一个ESP尾（ESP Trailer和ESP Auth data），如封装模式所示。与AH不同的是，ESP将数据中的有效载荷进行加密后再封装到数据包中，以保证数据的机密性，但ESP没有对IP头的内容进行保护，除非IP头被封装在ESP内部（采用隧道模式）。
AH和ESP协议的简单比较如表1所示。
| 安全特性 | AH | ESP |
|---|---|---|
| 协议号 | 51 | 50 |
| 数据完整性校验 | 支持（验证整个IP报文） | 支持（传输模式：不验证IP头，隧道模式：验证整个IP报文） |
| 数据源验证 | 支持 | 支持 |
| 数据加密 | 不支持 | 支持 |
| 防报文重放攻击 | 支持 | 支持 |
| IPSec NAT-T（NAT穿越） | 不支持 | 支持 |
从表中可以看出两个协议各有优缺点，在安全性要求较高的场景中可以考虑联合使用AH协议和ESP协议。
报文头结构
AH报文头结构
| 字段 | 长度 | 含义 |
|---|---|---|
| 下一头部 | 8比特 | 标识AH报文头后面的负载类型。传输模式下，是被保护的上层协议（TCP或UDP）或ESP协议的编号；隧道模式下，是IP协议或ESP协议的编号。说明：当AH与ESP协议同时使用时，AH报文头的下一头部为ESP报文头。 |
| 负载长度 | 8比特 | 表示以32比特为单位的AH报文头长度减2，缺省为4。 |
| 保留字段 | 16比特 | 保留将来使用，缺省为0。 |
| SPI | 32比特 | IPSec安全参数索引，用于唯一标识IPSec安全联盟。 |
| 序列号 | 32比特 | 是一个从1开始的单项递增的计数器，唯一地标识每一个数据包，用于防止重放攻击。 |
| 认证数据 | 一个变长字段，长度为32比特的整数倍，通常为96比特。 | 该字段包含数据完整性校验值 ICV（Integrity Check Value），用于接收方进行完整性校验。可选择的认证算法有MD5、SHA1、SHA2、SM3。说明：MD5和SHA1验证算法存在安全隐患，建议优先使用SHA2或SM3算法。 |
ESP报文头结构
ESP报文头结构如图2所示；ESP报文头字段含义如表3所示。
| 字段 | 长度 | 含义 |
|---|---|---|
| SPI | 32比特 | IPSec安全参数索引，用于唯一标识IPSec安全联盟。 |
| 序列号 | 32比特 | 是一个从1开始的单项递增的计数器，唯一地标识每一个数据包，用于防止重放攻击。 |
| 负载数据 | — | 包含原始IP报文中可变长度数据内容。ESP保护的内容类型由下一头部字段标识。 |
| 填充字段 | — | 用于增加ESP报文头的位数。填充字段的长度与负载数据的长度和算法有关。当待加密报文的长度不是加密算法所要求的块长度时，需要进行填充补齐。 |
| 填充长度 | 8比特 | 给出前面填充字段的长度，置0时表示没有填充。 |
| 下一头部 | 8比特 | 标识ESP报文头后面的下一个负载类型。传输模式下，是被保护的上层协议（TCP或UDP）的编号；隧道模式下，是IP协议的编号。 |
| 认证数据 | 一个变长字段，长度为32比特的整数倍，通常为96比特。 | 该字段包含数据完整性校验值ICV，用于接收方进行完整性校验。可选择的认证算法与AH的相同。ESP的验证功能是可选的，如果启动了数据包验证，会在加密数据的尾部添加一个ICV数值。 |
封装模式
封装模式是指将AH或ESP相关的字段插入到原始IP报文中，以实现对报文的认证和加密，封装模式有传输模式和隧道模式两种。
传输模式
在传输模式中，AH头或ESP头被插入到IP头与传输层协议头之间，保护TCP/UDP/ICMP负载。由于传输模式未添加额外的IP头，所以原始报文中的IP地址在加密后报文的IP头中可见。以TCP报文为例，原始报文经过传输模式封装后，报文格式如图1所示。
传输模式下，与AH协议相比，ESP协议的完整性验证范围不包括IP头，无法保证IP头的安全。
隧道模式
在隧道模式下，AH头或ESP头被插到原始IP头之前，另外生成一个新的报文头放到AH头或ESP头之前，保护IP头和负载。以TCP报文为例，原始报文经隧道模式封装后的报文结构如图2所示。
隧道模式下，与AH协议相比，ESP协议的完整性验证范围不包括新IP头，无法保证新IP头的安全。
传输模式和隧道模式比较
传输模式和隧道模式的区别在于：
- 从安全性来讲，隧道模式优于传输模式。它可以完全地对原始IP数据包进行验证和加密。隧道模式下可以隐藏内部IP地址，协议类型和端口。
- 从性能来讲，隧道模式因为有一个额外的IP头，所以它将比传输模式占用更多带宽。
- 从场景来讲，传输模式主要应用于两台主机或一台主机和一台VPN网关之间通信；隧道模式主要应用于两台VPN网关之间或一台主机与一台VPN网关之间的通信。
当安全协议同时采用AH和ESP时，AH和ESP协议必须采用相同的封装模式。
加密和验证
IPSec提供了两种安全机制：加密和验证。加密机制保证数据的机密性，防止数据在传输过程中被窃听；验证机制能保证数据真实可靠，防止数据在传输过程中被仿冒和篡改。
加密
IPSec采用对称加密算法对数据进行加密和解密。如图1所示，数据发送方和接收方使用相同的密钥进行加密、解密。
用于加密和解密的对称密钥可以手工配置，也可以通过IKE协议自动协商生成。
常用的对称加密算法包括：数据加密标准DES（Data Encryption Standard）、3DES（Triple Data Encryption Standard）、先进加密标准AES（Advanced Encryption Standard）国密算法（SM1和SM4）。其中，DES和3DES算法安全性低，存在安全风险，不推荐使用。
验证
IPSec的加密功能无法验证解密后的信息是否是原始发送的信息或完整。IPSec采用HMAC（Keyed-Hash Message Authentication Code）功能，比较完整性校验值ICV进行数据包完整性和真实性验证。
通常情况下，加密和验证通常配合使用。如图2所示，在IPSec发送方，加密后的报文通过验证算法和对称密钥生成完整性校验值ICV，IP报文和完整性校验值ICV同时发给对端；在IPSec接收方，使用相同的验证算法和对称密钥对加密报文进行处理，同样得到完整性校验值ICV，然后比较完整性校验值ICV进行数据完整性和真实性验证，验证不通过的报文直接丢弃，验证通过的报文再进行解密。
同加密一样，用于验证的对称密钥也可以手工配置，或者通过IKE协议自动协商生成。
常用的验证算法包括：消息摘要MD5（Message Digest 5）、安全散列算法SHA1（Secure Hash Algorithm 1）、SHA2、国密算法SM3（Senior Middle 3）。其中，MD5、SHA1算法安全性低，存在安全风险，不推荐使用。
密钥交换
使用对称密钥进行加密、验证时，如何安全地共享密钥是一个很重要的问题。有两种方法解决这个问题：
- 带外共享密钥在发送、接收设备上手工配置静态的加密、验证密钥。双方通过带外共享的方式（例如通过电话或邮件方式）保证密钥一致性。这种方式的缺点是安全性低，可扩展性差，在点到多点组网中配置密钥的工作量成倍增加。另外，为提升网络安全性需要周期性修改密钥，这种方式下也很难实施。
- 使用一个安全的密钥分发协议通过IKE协议自动协商密钥。IKE采用DH（Diffie-Hellman）算法在不安全的网络上安全地分发密钥。这种方式配置简单，可扩展性好，特别是在大型动态的网络环境下此优点更加突出。同时，通信双方通过交换密钥交换材料来计算共享的密钥，即使第三方截获了双方用于计算密钥的所有交换数据，也无法计算出真正的密钥，这样极大地提高了安全性。
IKE协议
因特网密钥交换IKE（Internet Key Exchange）协议建立在Internet安全联盟和密钥管理协议ISAKMP定义的框架上，是基于UDP（User Datagram Protocol）的应用层协议。它为IPSec提供了自动协商密钥、建立IPSec安全联盟的服务，能够简化IPSec的配置和维护工作。
IKE与IPSec的关系如图1所示，对等体之间建立一个IKE SA完成身份验证和密钥信息交换后，在IKE SA的保护下，根据配置的AH/ESP安全协议等参数协商出一对IPSec SA。此后，对等体间的数据将在IPSec隧道中加密传输。
IKE SA是一个双向的逻辑连接，两个对等体间只建立一个IKE SA。
IKE安全机制
IKE具有一套自保护机制，可以在网络上安全地认证身份、分发密钥、建立IPSec SA：
- 身份认证身份认证确认通信双方的身份（对等体的IP地址或名称），包括预共享密钥PSK（pre-shared key）认证、数字证书RSA（rsa-signature）认证和数字信封认证。
- 在预共享密钥认证中，通信双方采用共享的密钥对报文进行Hash计算，判断双方的计算结果是否相同。如果相同，则认证通过；否则认证失败。当有1个对等体对应多个对等体时，需要为每个对等体配置预共享的密钥。该方法在小型网络中容易建立，但安全性较低。
- 在数字证书认证中，通信双方使用CA证书进行数字证书合法性验证，双方各有自己的公钥（网络上传输）和私钥（自己持有）。发送方对原始报文进行Hash计算，并用自己的私钥对报文计算结果进行加密，生成数字签名。接收方使用发送方的公钥对数字签名进行解密，并对报文进行Hash计算，判断计算结果与解密后的结果是否相同。如果相同，则认证通过；否则认证失败。使用数字证书安全性高，但需要CA来颁发数字证书，适合在大型网络中使用。
- 在数字信封认证中，发送方首先随机产生一个对称密钥，使用接收方的公钥对此对称密钥进行加密（被公钥加密的对称密钥称为数字信封），发送方用对称密钥加密报文，同时用自己的私钥生成数字签名。接收方用自己的私钥解密数字信封得到对称密钥，再用对称密钥解密报文，同时根据发送方的公钥对数字签名进行解密，验证发送方的数字签名是否正确。如果正确，则认证通过；否则认证失败。数字信封认证用于设备需要符合国家密码管理局要求时使用，此认证方法只能在IKEv1的主模式协商过程中支持。
- 身份保护身份数据在密钥产生之后加密传送，实现了对身份数据的保护。IKE支持的加密算法有：DES、3DES、AES-128、AES-192、AES-256、SM1和SM4。
- DHDH是一种公共密钥交换方法，它用于产生密钥材料，并通过ISAKMP消息在发送和接收设备之间进行密钥材料交换。然后，两端设备各自计算出完全相同的对称密钥。该对称密钥用于计算加密和验证的密钥。在任何时候，通信双方都不交换真正的密钥。DH密钥交换是IKE的精髓所在。
- PFS完善的前向安全性PFS（Perfect Forward Secrecy）通过执行一次额外的DH交换，确保即使IKE SA中使用的密钥被泄露，IPSec SA中使用的密钥也不会受到损害。
- MD5和SHA1认证算法不安全，建议使用SHA2-256、SHA2-384、SHA2-512、SM3算法。
- DES和3DES加密算法不安全，建议使用AES或SM算法。
IKE版本
IKE协议分IKEv1和IKEv2两个版本。IKEv2与IKEv1相比有以下优点：
- 简化了安全联盟的协商过程，提高了协商效率。IKEv1使用两个阶段为IPSec进行密钥协商并建立IPSec SA：第一阶段，通信双方协商和建立IKE本身使用的安全通道，建立一个IKE SA；第二阶段，利用这个已通过了认证和安全保护的安全通道，建立一对IPSec SA。IKEv2则简化了协商过程，在一次协商中可直接生成IPSec的密钥并建立IPSec SA。IKEv1和IKEv2的具体协商过程请分别参见IKEv1协商安全联盟的过程和IKEv2协商安全联盟的过程。
- 修复了多处公认的密码学方面的安全漏洞，提高了安全性能。
- 加入对EAP（Extensible Authentication Protocol）身份认证方式的支持，提高了认证方式的灵活性和可扩展性。EAP是一种支持多种认证方法的认证协议，可扩展性是其最大的优点，即若想加入新的认证方式，可以像组件一样加入，而不用变动原来的认证体系。当前EAP认证已经广泛应用于拨号接入网络中。
定义IPSec保护的数据流
IPSec是基于定义的感兴趣流触发对特定数据的保护，至于什么样的数据是需要IPSec保护的，可以通过以下两种方式定义。其中IPSec感兴趣流即需要IPSec保护的数据流。
- ACL方式手工方式和IKE自动协商方式建立的IPSec隧道是由ACL来指定要保护的数据流范围，筛选出需要进入IPSec隧道的报文，ACL规则允许（permit）的报文将被保护，未匹配任何permit规则的报文将不被保护。这种方式可以利用ACL的丰富配置功能，根据IP地址、端口、协议类型等对报文进行过滤进而灵活制定IPSec的保护方法。
- 路由方式通过IPSec虚拟隧道接口建立IPSec隧道，将所有路由到IPSec虚拟隧道接口的报文都进行IPSec保护，根据该路由的目的地址确定哪些数据流需要IPSec保护。其中IPSec虚拟隧道接口是一种三层逻辑接口。路由方式具有以下优点：
- 通过路由将需要IPSec保护的数据流引到虚拟隧道接口，不需使用ACL定义待加/解密的流量特征，简化了IPSec配置的复杂性。
- 支持动态路由协议。
- 通过GRE over IPSec支持对组播流量的保护。
IKEv1协商安全联盟的过程
采用IKEv1协商安全联盟主要分为两个阶段：第一阶段，通信双方协商和建立IKE协议本身使用的安全通道，即建立一个IKE SA；第二阶段，利用第一阶段已通过认证和安全保护的安全通道，建立一对用于数据安全传输的IPSec安全联盟。
IKEv1协商阶段1
IKEv1协商阶段1的目的是建立IKE SA。IKE SA建立后对等体间的所有ISAKMP消息都将通过加密和验证，这条安全通道可以保证IKEv1第二阶段的协商能够安全进行。
IKEv1协商阶段1支持两种协商模式：主模式（Main Mode）和野蛮模式（Aggressive Mode）。
主模式包含三次双向交换，用到了六条ISAKMP信息，协商过程如图1所示。这三次交换分别是：
- 消息①和②用于提议交换发起方发送一个或多个IKE安全提议，响应方查找最先匹配的IKE安全提议，并将这个IKE安全提议回应给发起方。匹配的原则为协商双方具有相同的加密算法、认证算法、认证方法和Diffie-Hellman组标识。
- 消息③和④用于密钥信息交换双方交换Diffie-Hellman公共值和nonce值，用于IKE SA的认证和加密密钥在这个阶段产生。
- 消息⑤和⑥用于身份和认证信息交换（双方使用生成的密钥发送信息），双方进行身份认证和对整个主模式交换内容的认证。
- IKE安全提议指IKE协商过程中用到的加密算法、认证算法、Diffie-Hellman组及认证方法等。
- nonce是个随机数，用于保证IKE SA存活和抗重放攻击。
野蛮模式只用到三条信息，前两条消息①和②用于协商IKE安全提议，交换Diffie-Hellman公共值、必需的辅助信息以及身份信息，并且消息②中还包括响应方发送身份信息供发起方认证，消息③用于响应方认证发起方。IKEv1协商阶段1的协商过程如图1所示。
与主模式相比，野蛮模式减少了交换信息的数目，提高了协商的速度，但是没有对身份信息进行加密保护。
IKEv1协商阶段2
IKEv1协商阶段2的目的就是建立用来安全传输数据的IPSec SA，并为数据传输衍生出密钥。这一阶段采用快速模式（Quick Mode）。该模式使用IKEv1协商阶段1中生成的密钥对ISAKMP消息的完整性和身份进行验证，并对ISAKMP消息进行加密，故保证了交换的安全性。IKEv1协商阶段2的协商过程如图2所示。
IKEv1协商阶段2通过三条ISAKMP消息完成双方IPSec SA的建立：
- 协商发起方发送本端的安全参数和身份认证信息。安全参数包括被保护的数据流和IPSec安全提议等需要协商的参数。身份认证信息包括第一阶段计算出的密钥和第二阶段产生的密钥材料等，可以再次认证对等体。IPSec安全提议指IPSec协商过程中用到的安全协议、加密算法及认证算法等。
- 协商响应方发送确认的安全参数和身份认证信息并生成新的密钥。IPSec SA数据传输需要的加密、验证密钥由第一阶段产生的密钥、SPI、协议等参数衍生得出，以保证每个IPSec SA都有自己独一无二的密钥。如果启用PFS，则需要再次应用DH算法计算出一个共享密钥，然后参与上述计算，因此在参数协商时要为PFS协商DH密钥组。
- 发送方发送确认信息，确认与响应方可以通信，协商结束。
L2TP over IPSec
L2TP over IPSec，即先用L2TP封装报文再用IPSec封装，这样可以综合两种VPN的优势，通过L2TP实现用户验证和地址分配，并利用IPSec保障通信的安全性。L2TP over IPSec既可以用于分支接入总部，也可以用于出差员工接入总部。
分支接入总部网络的L2TP over IPSec的工作原理如图1所示，这里以NAS-Initiated L2TP VPN为例。对于其他L2TP VPN场景，请参见L2TP VPN中的描述。
报文在隧道中传输时先进行L2TP封装再进行IPSec封装。IPSec封装过程中增加的IP头即源地址为IPSec网关应用IPSec安全策略的接口IP地址，目的地址即IPSec对等体中应用IPSec安全策略的接口IP地址。
IPSec需要保护的是从L2TP的起点到L2TP的终点数据流。L2TP封装过程中增加的IP头即源IP地址为L2TP起点地址，目的IP地址为L2TP终点的地址。分支接入总部组网中L2TP起点地址为NAS出接口的IP地址，L2TP终点的地址为LNS入接口的IP地址。
由于L2TP封装时已经增加了一个公网IP头，而隧道模式跟传输模式相比又多增加了一个公网IP头，导致报文长度更长，更容易导致分片。所以推荐采用传输模式L2TP over IPSec。
出差用户远程接入总部网络的组网中L2TP over IPSec的协商顺序和报文封装顺序跟分支接入总部网络的组网中的协商顺序和报文封装顺序是一样的。所不同的是出差用户远程接入总部网络的组网中，用户侧的L2TP和IPSec封装是在客户端上完成的。L2TP起点的地址为客户端将要获取的内网地址，此地址可以是LNS上配置的IP地址池中的任意地址。L2TP终点地址为LNS入接口的地址。
GRE over IPSec
GRE over IPSec可利用GRE和IPSec的优势，通过GRE将组播、广播和非IP报文封装成普通的IP报文，通过IPSec为封装后的IP报文提供安全地通信，进而可以提供在总部和分支之间安全地传送广播、组播的业务，例如视频会议或动态路由协议消息等。
当网关之间采用GRE over IPSec连接时，先进行GRE封装，再进行IPSec封装。GRE over IPSec使用的封装模式为可以是隧道模式也可以是传输模式。因为隧道模式跟传输模式相比增加了IPSec头，导致报文长度更长，更容易导致分片，所以推荐采用传输模式GRE over IPSec。
图1 GRE over IPSec报文封装和隧道协商过程
IPSec封装过程中增加的IP头即源地址为IPSec网关应用IPSec安全策略的接口地址，目的地址即IPSec对等体中应用IPSec安全策略的接口地址。
IPSec需要保护的数据流为从GRE起点到GRE终点的数据流。GRE封装过程中增加的IP头即源地址为GRE隧道的源端地址，目的地址为GRE隧道的目的端地址。
在GRE over IPsec场景，如果需在设备上配置NAT，则还需额外配置一条源地址为NAT转换前IP地址且动作为允许的ACL规则。
IPSec多实例
IPSec多实例主要用于向小企业提供防火墙租赁业务和实现企业内部网络隔离。
如图1所示，三个小企业的总部共用一台VPN网关。三个企业之间需要保持网络独立，互相之间不会产生影响。三个企业的总部内部网络IP地址是各自规划的，可能出现IP地址重叠（即不同私网出现使用相同IP地址的情况），此时需要在网关上应用IPSec多实例功能，将三个企业的IPSec隧道与三个IPSec多实例绑定，保证相同IP地址的报文能够正确转发。
IPSec智能选路
FW作为分支的网关时，可以通过配置IPSec智能选路功能实现多条IPSec隧道动态切换。
IPSec智能选路功能按照链路切换机制的不同有两种使用场景，一种是基于链路质量探测结果切换链路，另一种是基于路由状态变化切换链路。
基于链路质量探测结果切换链路
如图1所示，隧道两端的网关设备有多个公网接口，网关设备之间存在多条可通信的链路。通过在FW_B上配置IPSec智能选路功能，可以实现分支和总部之间多条IPSec隧道动态切换。使用其中一条链路建立IPSec隧道后，网关设备会实时检测已有IPSec隧道的时延或丢包率。在时延或丢包率高于设定的阈值时，动态切换到备用链路上重新建立IPSec隧道。
在FW_B上配置IPSec智能选路功能后，FW_B会选择一条链路建立IPSec隧道。而后FW_B通过发送ICMP报文检测IPSec隧道的时延或丢包率。当隧道的时延或丢包率高于设定的阈值时，FW_B会拆除当前的IPSec隧道，并选择另一条链路建立IPSec隧道。新的隧道建立后，FW_B继续检测隧道的时延或丢包率，如果时延或丢包率仍然高于设定的阈值，FW_B会继续切换链路，直至隧道的时延和丢包率达标或者循环切换次数达到设定的上限值时停止。这样，就能确保分支和总部之间始终使用满足质量要求的IPSec隧道通信。
此外，FW还支持高优先级链路自动回切功能，在IPSec隧道因高优先级链路（如图1中的link1）的链路质量不达标被切换到备用链路（如图1中的link2）后持续探测高优先级链路的链路质量，若在一定的回切时延内高优先级链路的质量持续达标，则FW会自动将IPSec隧道回切到高优先级链路上，实现高优先级链路的最大化利用。
基于路由状态变化切换链路
如图2所示，从分支网关FW_B到总部网关FW_A之间有两条链路Link1和Link2，FW_B与Internet之间运行动态路由协议（此处以OSPF为例）。在FW_B上配置IPSec智能选路功能，可以实现分支和总部之间多条IPSec隧道动态切换。
Link1和Link2链路状态都正常的情况下，FW_B会选择一条链路建立IPSec隧道，例如选择Link1链路。当Link1链路出现故障时，通过Link1到达FW_A的路由就会消失，于是FW_B会根路由变化自动将IPSec隧道切换到Link2上。
链路冗余备份
为提高网络可靠性，企业分支一般通过两条或多条链路与企业总部建立IPSec连接，如何在一条链路故障后将流量及时切换到其他链路，以保证业务的正常运行就成为需要解决的问题。为此，设备提供IPSec主备链路冗余备份和IPSec多链路冗余备份两种功能。
IPSec主备链路冗余备份
如图1所示，FW_A通过主备两条链路连接FW_B。在FW_A上创建两个Tunnel接口，借用同一个物理接口的IP地址，分别应用不同的IPSec安全策略，在FW_B的两个物理接口上也分别应用不同的IPSec安全策略，这样可以创建主备两条IPSec隧道。正常情况下，流量通过由主链路和Tunnel1接口建立的IPSec隧道传输；当主链路故障时，FW_A感知变化，采用Tunnel2接口与FW_B的备份链路建立IPSec隧道，旧的IPSec隧道被拆除，流量切换也随之完成。
IPSec多链路冗余备份
如图2所示，FW_A通过主备两条链路连接FW_B。系统在FW_A的物理接口与FW_B的Tunnel接口之间建立一个IPSec隧道，流量通过Tunnel接口进行IPSec处理，然后通过路由表选择物理接口发送。当主物理链路失效时，其路由变为不可达，流量自然切换到备用链路。这种情况下，IPSec隧道不需要进行重协商，故可快速完成流量切换。
通过Tunnel接口进行链路冗余备份可以实现多条链路的冗余备份，而且与主备链路冗余备份相比，配置更简单，流量切换速度更快。
当IPSec网关连接不同的运营商网络或者即使连接的是同一个运营商的网络，但存在主备两条链路跨局域网、跨区域连接到一个运营商的不同接入路由器上，都可能存在主链路故障后，备链路设备发现IPSec报文的源地址属于不同运营商或不同接入路由器而将报文丢弃的问题。因此进行配置时一定要先测试一下，看看实际网络环境是否允许主备链路倒换。
IPSec双机热备
FW支持主备方式和负载分担方式两种双机热备。需根据实际组网情况进行选择。
双机热备场景下，要求两台网关的软硬件配置完全一致，包括硬件插板的数量、位置，硬件版本和驱动软件版本、主机软件版本等。
IPSec双机热备（主备方式）
如图1所示，FW_A1和FW_A2对外配置VRRP备份组1，并在VRRP备份组1和分支网关FW_B的物理接口之间建立IPSec隧道。当主用FW_A1物理接口、链路或主机故障时，流量被引导到备用FW_A2进行IPSec和转发处理。这种情况下，原有的IPSec隧道并不会被拆除，切换速度更具优势。
双机热备主备模式下，备机不进行IPsec协商。
IPSec双机热备（负载分担方式）
负载分担方式的IPSec双机热备主要应用在LTE场景下，又分为以下3种典型场景，不同场景下的实现机制略有不同。
- IPSec网关负载分担，隧道不备份如图2所示，FW_A1和FW_A2以负载分担方式工作。eNodeB1和FW_A1、FW_A2各建了一条IPSec隧道，这两条IPSec隧道共同分担了分支发往总部的流量。这两条IPSec隧道之间不存在备份关系，彼此独立，因而互不影响。当FW_A1发生故障时，eNodeB1与FW_A1的IPSec隧道将断开，分支发往总部的流量将全部通过eNodeB1与FW_A2之间的IPSec隧道发往总部。反之，当FW_A2发生故障时，流量将会全部通过eNodeB1与FW_A1之间的IPSec隧道发往总部。图2 IPSec网关负载分担，隧道不备份
- IPSec网关负载分担，上下行连接路由器如图3所示，FW_A1和FW_A2以负载分担方式工作。eNodeB1/eNodeB2分别与FW_A1和FW_A2建立了主、备IPSec隧道。建立隧道的基本原理是：分别在FW_A1和FW_A2的物理接口上配置相同的两个IP地址IP_1和IP_2。eNodeB1会以IP_1地址作为隧道对端地址与FW_A1和FW_A2建立主、备IPSec Tunnel1，eNodeB2会以IP_2地址作为隧道对端地址与FW_A1和FW_A2建立主、备IPSec Tunnel2。FW_A1和FW_A2运行正常时，eNodeB1下的用户发给总部的流量将由eNodeB1与FW_A1之间的主IPSec Tunnel1发往总部；eNodeB2下的用户发给总部的流量将由eNodeB2与FW_A2之间的主IPSec Tunnel2发往总部。当FW_A1出现故障时，eNodeB1则会将流量通过eNodeB1与FW_A2之间的备IPSec Tunnel1发往总部。同样，当FW_A2出现故障时，eNodeB2也将会使用备IPSec Tunnel2发送流量。图3 IPSec网关负载分担，上下行连接路由器
- IPSec网关负载分担，上下行连接交换机如图4所示，FW_A1和FW_A2以负载分担方式工作。eNodeB1和eNodeB2分别与FW_A1和FW_A2建立了主、备IPSec隧道。建立隧道的基本原理是：在FW_A1和FW_A2上分别创建一个VRRP备份组1，eNodeB1将会以VRRP备份组1的虚拟IP地址作为隧道对端地址与FW_A1和FW_A2建立主、备IPSec Tunnel1。同样，在FW_A1和FW_A2上分别创建一个VRRP备份组2，eNodeB2将会以VRRP备份组2的虚拟地址作为隧道对端地址与FW_A1和FW_A2建立主、备IPSec Tunnel2。当FW_A1和FW_A2运行正常时，eNodeB1下的用户发给总部的流量将由eNodeB1与FW_A1之间的主IPSec Tunnel1发往总部。eNodeB2下的用户发给总部的流量将由eNodeB2与FW_A2之间的主IPSec Tunnel2发往总部。当FW_A1出现故障时，eNodeB1则会将流量通过eNodeB1与FW_A2之间的备IPSec Tunnel1发往总部。同样，当FW_A2出现故障时，eNodeB2也将会使用备IPSec Tunnel2发送流量。图4 IPSec网关负载分担，上下行连接交换机
IPSec集群
在LTE场景中，基站所承载的客户流量需要在不安全的传输网络与安全的核心网络之间传输。为保护客户流量的安全，就需要在核心网络的边缘部署IPSec网关。在基站与IPSec网关之间建立IPSec隧道，客户流量通过IPSec隧道安全地传输。问题在于LTE场景中基站数量众多，且随着4G业务的发展每个基站承载的客户流量也大量增加。
一台IPSec网关的性能有限，无法承载所有基站的客户流量。所以LTE场景下通常需要多台IPSec网关才能满足IPSec隧道和VPN流量带宽的需求。由于基站所承载的客户流量不是固定的，多台IPSec网关之间彼此独立，很容易造成某些IPSec网关负载过重而无法建立新的IPSec隧道，某些IPSec网关却没有得到充分利用的情况。IPSec集群功能正是在此背景下产生的。
IPSec集群是指彼此有关联的一组IPSec网关的集合，这些IPSec网关对外相当于一台虚拟设备。对于基站来说，它与IPSec集群协商建立IPSec隧道，而不需要知道具体与哪个IPSec网关协商IPSec隧道。集群内部可以根据成员的负载情况选择一台IPSec网关响应基站的IPSec协商请求。
IPSec集群的典型组网如图1所示。
设备仅支持作为IPSec协商响应端与做为IPSec协商发起方的基站进行IPSec协商。
IPSec集群的实现主要依赖VRRP、IPSec、IKEv2重定向、IPSec路由注入、异地容灾倒换等功能：
- VRRPVRRP负责在IPSec集群内选举一个Master网关。
- IKEv2重定向一个IPSec集群就对应一个IKEv2重定向组，IKEv2对外发布一个虚拟的Server IP地址。通过将VRRP的虚拟地址VIP设置为IKEv2重定向组对外公布的Server IP，将VRRP组与IKEv2重定向组的功能结合起来。IPSec集群内包括Master网关设备和其他成员网关设备。Master网关负责对所有成员进行管理，成员网关定期向Master网关发送自己的负载情况。Master根据所有成员的负载情况计算出负载最小的IPSec网关。IKEv2重定向是在RFC5685中定义的一个标准。IKEv2重定向机制允许在IKE安全联盟初始交换（IKE_SA_INIT交换）或IKE认证交换（IKE_AUTH交换）这两个不同的阶段进行IPSec隧道请求重定向。
- IPSec路由注入通过IPSec路由注入确保流量可以按照正确的路由进入IPSec隧道。
- 异地容灾倒换基站可以向多个IPSec集群发起隧道协商，通过异地的IPSec集群实现容灾备份。
VRRP、IPSec路由注入都是原来的功能，异地容灾倒换主要在基站侧实现，此处不再赘述。本节重点说明IKEv2重定向的原理。
IKEv2协商安全联盟主要是通过初始交换来完成。初始交换包括两个交换：IKE安全联盟初始交换（IKE_SA_INIT交换）和IKE认证交换（IKE_AUTH交换）。IKE_SA_INIT交换用来协商IKE SA，IKE_AUTH交换用来协商第一对CHILD SA。IKEv2重定向既可以在IKE_SA_INIT交换阶段进行也可以在IKE_AUTH交换阶段进行。
IKE_SA_INIT交换阶段重定向
图2 IKEv2安全联盟的协商过程（IKE_SA_INIT交换阶段重定向）
- 基站发送IKE_SA_INIT请求报文给IKEv2重定向组（发送到Master网关）。IKE_SA_INIT请求报文中携带REDIRECT_SUPPORTED通知消息，表明基站支持IKEv2重定向功能。另外跟普通的IKE_SA_INIT请求报文一样，会发送一个nonce值。
- Master网关计算负载情况，找出最小负载网关。Master网关向基站发送IKE_SA_INIT响应报文，报文中携带REDIRECT通知消息。该通知消息中包含新的IPSec网关的地址（若最小负载网关是自己则不进行重定向）和从IKE_SA_INIT请求报文中获取的nonce值。
- 基站收到Master网关发送的IKE_SA_INIT响应报文后，验证该nonce值是否是自己发送的IKE_SA_INIT请求报文中携带的nonce值。若nonce值不匹配，基站将丢弃该响应报文并等待下一个响应报文。若nonce值匹配，则基站将向获取的新IPSec网关地址发送IKE_SA_INIT请求报文。该IKE_SA_INIT请求报文中携带REDIRECTED_FROM通知消息，表明该请求是重定向过来的。
- 新的IPSec网关正常响应基站的IKE协商请求，并与基站完成IKE SA和CHILD SA的协商。
IKE_AUTH交换阶段重定向
图3 IKEv2安全联盟的协商过程（IKE_SA_INIT交换阶段重定向）
- 基站发送IKE_SA_INIT请求报文给IKEv2重定向组（发送到Master网关）。IKE_SA_INIT请求报文中携带REDIRECT_SUPPORTED通知消息，表明基站支持IKEv2重定向功能。
- Master网关计算负载情况，找出最小负载网关。Master网关与基站之间完成IKE_SA_INIT交换，建立IKE SA。在IKE_AUTH响应报文中携带REDIRECT通知消息。该通知消息中包含新的IPSec网关的地址（若最小负载网关是自己则不进行重定向）。
- 基站收到初始IPSec网关IKE_AUTH响应报文。在重定向载荷之前还会收到认证载荷，基站先对Master网关进行身份认证，并发送删除消息，删除已经建立的IKE SA。由于已经进行了身份确认，就可以进行IPSec重定向了。IKEv2重定向场景下，FW不支持EAP认证。
- 基站发送IKE_SA_INIT请求报文给新的IPSec网关。该IKE_SA_INIT请求报文中携带REDIRECTED_FROM通知消息，表明该请求是重定向过来的。
- 新的IPSec网关正常响应基站的IKE协商请求，并与基站完成IKE SA和CHILD SA的协商。
IPSec在过渡网络中的应用及原理
仅隧道模式支持IPSec 6 over 4和IPSec 4 over 6。
IPSec 6 over 4
在IPv4网络向IPv6网络过渡的初期，IPv4网络已被大量部署，IPv6网络只是零星的散布在网络中间，由于IPv6网络无法与IPv4网络直接互通，因此这些被IPV4网络所阻隔的IPv6网络之间就无法通信。利用隧道技术可以在IPv4网络上创建隧道，从而实现IPv6网络之间的互连。在IPv4网络上用于连接IPv6网络的隧道称为IPv6 over IPv4隧道。为了保证IPv6报文在安全的通过IPv4网络，就需要IPSec来提供保护，对应的技术称为IPSec 6 over 4技术。
隧道模式的IPSec 6 over 4，直接采用IPSec隧道模式实现IPv6 over IPv4和IPSec。隧道模式IPSec 6 over 4隧道原理图如图1所示。
IPSec 4 over 6
在IPv4 Internet向IPv6 Internet过渡的后期，IPv6网络已被大量部署，此时IPv4网络只是零星的散布在网络中间。由于IPv4网络无法与IPv6网络直接互通，因此这些被IPv6网络所阻隔的IPv4网络之间就无法通信。利用隧道技术可在IPv6网络上创建隧道，从而实现IPv4网络的互连。这类似于在IP网络上利用隧道技术部署VPN。在IPv6网络上用于连接IPv4网络的隧道，称为IPv4 over IPv6隧道。为了保证IPv4报文安全的通过IPv6网络，就需要IPSec来提供保护，对应的技术称为IPSec 4 over 6技术。
隧道模式的IPSec 4 over 6，直接采用IPSec隧道模式实现IPv4 over IPv6和IPSec。隧道模式IPSec 4 over 6隧道原理图如图2所示。
通过IPSec VPN实现局域网安全互联
分支与总部互联主要有如下场景。
点到点VPN—IPSec
点到点VPN也称为局域网到局域网VPN，网关到网关VPN，主要用于两个网关之间建立IPSec隧道，从而实现局域网之间安全地互访。点到点IPSec VPN典型组网如图1所示。
点到点VPN两端网关必须提供固定的IP地址或固定的域名。通信双方都可以主动发起连接。
- 点到点VPN既可以应用于纯IPv4网络也可以应用于纯IPv6网络或IPv4到IPv6的过渡网络中。
- FW作为IPSec网关可以部署在三层可以部署在二层。部署在二层被称为透明模式IPSec VPN。
- FW支持同时做IPSec网关和NAT网关。
- 当两个IPSec网关之间存在NAT设备时，FW支持IPSec NAT穿越。
点到点VPN—L2TP over IPSec
L2TP over IPSec，即先将报文用L2TP封装再用IPSec传输。L2TP和IPSec这两种VPN经常一起使用，可以实现优势互补。L2TP用于拨号并获取总部内网的IP地址，但是L2TP本身不够安全，正好可以通过IPSec保障通信的安全性。L2TP over IPSec适用于分支网络通过LAC拨号接入VPN并进行安全访问的场景。
分支接入总部的L2TP over IPSec组网如图2所示。LAC和LNS的出接口IP地址固定，分支用户通过PPPoE拨号到LAC。由LAC通过Internet向LNS发起建立隧道连接请求。在LAC和LNS之间建立L2TP over IPSec隧道。LAC侧对用户的身份进行验证，LNS侧还可以对用户的身份进行二次验证。验证通过后由LNS为接入用户分配总部内网的IP地址。
点到点VPN－GRE over IPSec
GRE是常用的隧道封装协议，可以很好的实现对于组播、广播和非IP报文的数据承载，但是GRE只有简单的密码验证，没有加密功能，数据传输安全性较低。IPSec虽具备很高的数据安全传输能力，但其本身不支持封装组播、广播和非IP报文。当需要在IPSec VPN上传输组播、广播和非IP报文时，如在总部和分支之间开视频会议等组播业务，可以采用GRE over IPSec。GRE over IPSec利用了GRE和IPSec的优势，利用GRE将组播、广播和非IP报文封装成普通的IP报文，通过IPSec将封装后的IP报文安全地传输。
GRE over IPSec VPN的典型组网，如图3所示。
GRE over IPSec使用的封装模式为可以是隧道模式也可以是传输模式。因为隧道模式跟传输模式相比多增加了IPSec头，导致报文长度更长，更容易导致分片。所以推荐采用传输模式GRE over IPSec。
点到多点VPN（Hub-Spoke VPN）
实际组网中最常见的是公司总部与多个分支机构通过点到多点IPSec VPN互通，典型组网如图4所示。
总部的IP地址通常为固定公网IP地址或提供固定域名，分支的IP地址可以为静态公网IP也可以为内网IP或动态公网IP。此时网络内数据流量可能存在如下几种情况：
- 各分支机构之间不需要通信此时只需要在总部和分支之间部署IPSec VPN。
- 各分支机构之间需要通信此时，若分支采用动态的公网地址接入Internet时，部署传统的IPSec VPN将存在一个问题，即分支与分支间无法直接通信，所有分支与分支间的通信数据只能由总部中转。而总部在中转分支间的通信流量时会消耗Hub的CPU及内存资源，造成资源紧张；另外，总部要对分支间的流量进行封装和解封装，会引入额外的网络延时。
通过IPSec VPN实现移动用户远程安全接入
远程接入是指出差员工或者合作伙伴在非固定办公地点，例如酒店、机场等场所，通过不安全的接入网或公网（例如Internet）接入核心网络，并访问核心网中的内部资源。由于远程接入是通过不安全的网络接入的，因此关键是要保证远程访问的安全性。为此，可通过部署IPSec VPN，在用户终端和核心网网关之间构建IPSec隧道，通过IPSec来保证数据的安全可靠传输。
远程接入场景主要有如下几种。
移动用户通过L2TP over IPSec方式远程接入
如图1所示，移动用户（如出差员工）通过Windows自带拨号软件或其他拨号软件通过拨号接入企业网络。L2TP具有很好的用户认证功能，但没有加密功能，不够安全。为此可部署L2TP over IPSec，在企业网关FW和PC之间建立L2TP over IPSec隧道，报文将先由L2TP封装再用IPSec加密后传输，保障了通信的安全性。
用户接入则可以通过本地认证方式对接入用户进行认证；也可以在总部部署认证服务器（以RADIUS服务器为例），对接入用户进行远端认证。认证通过后由企业网关FW为PC或移动终端分配总部内网的IP地址。
图1 移动用户远程接入组网图（L2TP over IPSec）
移动用户或无线设备通过EAP方式远程接入
如图2所示，无线设备通过基站远程接入核心网络，基站位于不安全的传输网络内，RADIUS服务器位于运营商核心网内。由于基站跟RADIUS服务器不在同一个网络内，总部网关设备需要开启EAP（Extensible Authentication Protocol）认证中继功能。同时，由于中间穿越不安全的Internet网络，为了防止在公网中传输时，EAP协议报文被拦截、修改或者仿冒，可使IKEv2协商采用EAP方式对协商的发起方进行附加的用户身份认证，提高安全性。
图2 移动用户远程接入组网图（EAP over IPSec）
移动用户或无线设备通过DHCP over IPSec方式接入
如图3所示的LTE场景中，eNodeB位于不安全的接入网络内，eNodeB需要通过汇聚网络中的DHCP服务器获取一个私网IP，用于与M2000相连，建立临时OM通道，获取OM配置等。由于eNodeB跟DHCP服务器不在同一个网络内，汇聚网络的网关设备需要开启DHCP中继功能。同时，由于中间穿越不安全的接入网络，为了防止在接入网络中传输时，DHCP协议报文被拦截、修改或者仿冒，可使用IPSec对DHCP协议进行加密和验证，提高传输的安全性。
图3 移动用户远程接入组网图（DHCP over IPSec）
此场景下，网关和基站设备（DHCP Client）必须同时支持DHCP over IPSec功能。