前面我们已经分别介绍了ADVPN的两种组网结构:Hub-Spoke(ADVPN:Hub-Spoke类型组网实验)和Full-Mesh(ADVPN:Full-Mesh模型组网实验)。
但是这两个案例和实际的应用场景多少存在一点差别,比如说并不是所有的企业都会拿出一台设备或者服务器来搭建独立的VAM服务器和AAA认证服务器,一般都是简化部署,能用一台设备解决的问题尽量不用两台设备。再就是实际使用中一般不是所有的站点都有MV专线,所以穿越NAT是在所难免的。
综合前面两点吧,本次实验做一些小的升级:
1、模拟器从HCL升级为EVE-NG;
2、设备由MSR36升级为HPE的VSR1000,版本是最新的R0633P17;
3、组网结构直接上Full-Mesh模型;
4、分支Spoke设备经过NAT设备。
本案例的组网拓扑如下,CT和CU两台设备为NAT设备。
本案例中HUB设备同时担当3个设备角色:Hub设备、VAM服务器和AAA认证服务器。同时不涉及穿越NAT,所以和上次的案例相比,只要把VAM设备的配置和HUB设备的配置融合一下即可。
#
sysname HUB
#
ospf 1
area 0.0.0.0
network 10.1.1.0 0.0.0.255
network 10.10.10.0 0.0.0.255
#
interface GigabitEthernet1/0
ip address 12.1.1.2 255.255.255.0
#
interface GigabitEthernet2/0
ip address 10.1.1.1 255.255.255.0
#
interface Tunnel1 mode advpn gre
ip address 10.10.10.1 255.255.255.0
ospf network-type broadcast
source GigabitEthernet1/0
tunnel protection ipsec profile ADVPN
vam client HUB
#
ip route-static 0.0.0.0 0 12.1.1.1
#
domain advpn
authentication advpn local
#
domain default enable advpn
#
HUB class network
password simple HUB
advpn
#
SPOKE1 class network
password simple SPOKE1
advpn
#
SPOKE2 class network
password simple SPOKE2
advpn
#
ipsec transform-set ADVPN
transport
esp encryption-algorithm des-cbc
esp authentication-algorithm sha1
#
ipsec profile ADVPN isakmp
ADVPN
ADVPN
#
ike profile ADVPN
keychain ADVPN
#
ike keychain ADVPN
address 0.0.0.0 0.0.0.0 key simple ADVPN
#
vam client name HUB
ADVPN
server primary ip-address 12.1.1.2
simple ADVPN
user HUB password simple HUB
client enable
#
vam server advpn-domain ADVPN id 1
simple ADVPN
server enable
HUB
hub private-address 10.10.10.1
spoke private-address range 10.10.10.0 10.10.10.255
设备配置我们先保持和上个案例一样,看一下效果。
#
vam client name SPOKE1
ADVPN
server primary ip-address 12.1.1.2
simple ADVPN
user SPOKE1 password simple SPOKE1
client enable
#
ike keychain ADVPN
address 0.0.0.0 0.0.0.0 key simple ADVPN
#
ike profile ADVPN
keychain ADVPN
#
ipsec transform-set ADVPN
transport
esp encryption-algorithm des-cbc
esp authentication-algorithm sha1
#
ipsec profile ADVPN isakmp
ADVPN
ADVPN
#
ip route-static 0.0.0.0 0 172.1.1.1
#
ospf 1
area 0.0.0.0
network 10.10.10.0 0.0.0.255
network 192.1.1.0 0.0.0.255
#
interface Tunnel1 mode advpn gre
ip address 10.10.10.2 255.255.255.0
ospf network-type broadcast
ospf dr-priority 0
source GigabitEthernet1/0
tunnel protection ipsec profile ADVPN
vam client SPOKE1
配置和SPOKE1配置相似,直接上配置。
#
vam client name SPOKE2
ADVPN
server primary ip-address 12.1.1.2
simple ADVPN
user SPOKE2 password simple SPOKE2
client enable
#
ike keychain ADVPN
address 0.0.0.0 0.0.0.0 key simple ADVPN
#
ike profile ADVPN
keychain ADVPN
#
ipsec transform-set ADVPN
transport
esp encryption-algorithm des-cbc
esp authentication-algorithm sha1
#
ipsec profile ADVPN isakmp
ADVPN
ADVPN
#
ip route-static 0.0.0.0 0 172.1.1.1
#
ospf 1
area 0.0.0.0
network 10.10.10.0 0.0.0.255
network 192.2.1.0 0.0.0.255
#
interface Tunnel1 mode advpn gre
ip address 10.10.10.3 255.255.255.0
ospf network-type broadcast
ospf dr-priority 0
source GigabitEthernet1/0
tunnel protection ipsec profile ADVPN
vam client SPOKE2
现在可以直接在HUB设备上查看注册上线的所有VAM Client的IPv4私网地址映射信息,可以看到HUB和SPOKE设备对应角色、隧道接口地址、公网地址、注册地址和IPsec地址+端口等信息。
可以看到,HUB设备使用的自身接口地址上线,没有穿越NAT;因为SPOKE1和SPOKE2都在NAT设备后面,所以能看到公网地址和注册地址不相同。还可以看出链路协议是IPsec over GRE,还有对应的端口信息等。
查看VAM Client的状态机信息。
在HUB设备上查看OSPF邻居信息。状态为DROther,表示路由器既不是所连网络的指定路由器,也不是所连网络的备份指定路由器。
查看HUB上的IPv4 ADVPN隧道信息,可以看到类型是H-S,说明本端是HUB角色,对端是SPOKE角色。
查看SPOKE2上的IPv4 ADVPN隧道信息,可以看到类型是S-H,说明本端是SPOKE角色,对端是HUB角色。
此时SPOKE2和SPOKE1之间是没有隧道的,我们还是和上次一样,手工触发一下。
很不幸,SPOKE1和SPOKE2之间的捷径一直建立不起来,无法建立捷径,那就是Hub-Spoke模型了。
其实,这就和前面看到的IPsec over GRE有关系了,因为SPOKE1和SPOKE2都在NAT设备后面,所以无法建立点对点隧道。
那怎么办呢?办法就是修改隧道接口模式,官网给的方法是把GRE封装的ADVPN隧道修改为UDP封装的ADVPN隧道,同时取消了IPsec保护。
配置变更就是把interface Tunnel1 mode advpn gre变更为interface Tunnel1 mode advpn udp;再移除掉IPsec保护隧道tunnel protection ipsec profile ADVPN。
变更后的配置如下:
#
interface Tunnel1 mode advpn udp
ip address 10.10.10.1 255.255.255.0
ospf network-type broadcast
source GigabitEthernet1/0
vam client HUB
#
interface Tunnel1 mode advpn udp
ip address 10.10.10.2 255.255.255.0
ospf network-type broadcast
ospf dr-priority 0
source GigabitEthernet1/0
vam client SPOKE1
#
interface Tunnel1 mode advpn udp
ip address 10.10.10.3 255.255.255.0
ospf network-type broadcast
ospf dr-priority 0
source GigabitEthernet1/0
vam client SPOKE2
先清空一下ADVPN会话,再次触发一下,就能看到直连隧道S-S建立成功了,TTL值有一个明显的变化。
再次查看ADVPN会话详情,可以看到ADVPN隧道使用的承载链路层协议已经是UDP了。
当然,我确认了一下,命令里面应该也可以支持IPsec over UDP,只需要在隧道接口下面把tunnel protection ipsec profile ADVPN命令再加回去就行了。
可以看到,Spoke-Hub会话和Spoke-Spoke会话的建立都是没有问题的,协议是IPsec-UDP。