ADVPN的S-S捷径到底有没有从总部绕转？

正文共：1234 字 11 图，预估阅读时间：10 分钟

前面我们已经分别介绍了ADVPN的两种组网结构：Hub-Spoke（ADVPN：Hub-Spoke类型组网实验）和Full-Mesh（ADVPN：Full-Mesh模型组网实验），并且介绍了穿越NAT场景下的Full-Mesh组网（HPE VSR配置穿越NAT场景下的ADVPN案例）。

现在有个问题，那就是Spoke-Spoke隧道的转发到底有没有经过HUB节点，我们今天就来验证一下。

实验组网如下图所示：

两个SPOKE节点我们使用内网的两台VSR设备，HUB节点我们使用公网的VSR设备，这样一来，分支的Spoke设备就要经过运营商的NAT设备和总部的Hub设备建立连接。同时，组网结构也使用Full-Mesh模型。

上次的案例中，因为SPOKE1和SPOKE2都在NAT设备后面，所以无法直接建立点对点隧道，官网给的方法是把GRE封装的ADVPN隧道修改为UDP封装的ADVPN隧道，也就是取消了IPsec保护。我们本次把封装模式修改为IPsec，以保护数据安全性。

本案例主要基于（HPE VSR配置穿越NAT场景下的ADVPN案例）进行配置调整。

HUB

HUB设备同时担当3个设备角色：Hub设备、VAM服务器和AAA认证服务器。需要注意的是，在HUB设备上需要放通VAM Server监听的UDP端口18000。

#
sysname HUB
#
ospf 1
 area 0.0.0.0
  network 172.30.1.0 0.0.0.255
  network 10.1.1.0 0.0.0.255
#
interface GigabitEthernet1/0
 ip address 172.30.3.19 255.255.255.0
#
interface GigabitEthernet2/0
 ip address 172.30.1.29 255.255.255.0
#
interface Tunnel1 mode ad udp
 ip address 10.1.1.254 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 172.30.3.1
#
domain ad
 authentication ad local
#
domain default enable ad
#
local-user HUB class network
 password simple HUB
 service-type ad
#
local-user SPOKE1 class network
 password simple SPOKE1
 service-type ad
#
local-user SPOKE2 class network
 password simple SPOKE2
 service-type ad
#
ipsec transform-set ADVPN
 encapsulation-mode transport
 esp encryption-algorithm des-cbc
 esp authentication-algorithm sha1
#
ipsec profile ADVPN isakmp
 transform-set ADVPN
 ike-profile ADVPN
#
ike profile ADVPN
 keychain ADVPN
#
ike keychain ADVPN
 pre-shared-key address 0.0.0.0 0.0.0.0 key simple ADVPN
#
vam client name HUB
 ad-domain ADVPN
 server primary ip-address 49.7.205.89
 pre-shared-key simple ADVPN
 user HUB password simple HUB
 client enable
#
vam server ad-domain ADVPN id 1
 pre-shared-key simple ADVPN
 server enable
 hub-group HUB
 hub private-address 10.1.1.254
 spoke private-address range 10.1.1.0 10.1.1.255

SPOKE1

设备配置我们保持不变。

#
vam client name SPOKE1
 ad-domain ADVPN
 server primary ip-address 49.7.205.89
 pre-shared-key simple ADVPN
 user SPOKE1 password simple SPOKE1
 client enable
#
ike keychain ADVPN
 pre-shared-key address 0.0.0.0 0.0.0.0 key simple ADVPN
#
ike profile ADVPN
 keychain ADVPN
#
ipsec transform-set ADVPN
 encapsulation-mode transport
 esp encryption-algorithm des-cbc
 esp authentication-algorithm sha1
#
ipsec profile ADVPN isakmp
 transform-set ADVPN
 ike-profile ADVPN
#
ip route-static 0.0.0.0 0 192.168.1.1
#
ospf 1
 area 0.0.0.0
  network 10.1.1.0 0.0.0.255
  network 11.1.1.0 0.0.0.255
#
interface Tunnel1 mode ad udp
 ip address 10.1.1.1 255.255.255.0
 ospf network-type broadcast
 ospf dr-priority 0
 source GigabitEthernet1/0
 tunnel protection ipsec profile ADVPN
 vam client SPOKE1

SPOKE2

配置和SPOKE1配置相似，直接上配置。

#
vam client name SPOKE2
 ad-domain ADVPN
 server primary ip-address 49.7.205.89
 pre-shared-key simple ADVPN
 user SPOKE2 password simple SPOKE2
 client enable
#
ike keychain ADVPN
 pre-shared-key address 0.0.0.0 0.0.0.0 key simple ADVPN
#
ike profile ADVPN
 keychain ADVPN
#
ipsec transform-set ADVPN
 encapsulation-mode transport
 esp encryption-algorithm des-cbc
 esp authentication-algorithm sha1
#
ipsec profile ADVPN isakmp
 transform-set ADVPN
 ike-profile ADVPN
#
ip route-static 0.0.0.0 0 192.168.1.1
#
ospf 1
 area 0.0.0.0
  network 10.1.1.0 0.0.0.255
  network 22.1.1.0 0.0.0.255
#
interface Tunnel1 mode ad udp
 ip address 10.1.1.2 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地址+端口等信息。

有点意外的是，同一个公网下的两台SPOKE竟然也能同时上线。可以看到，SPOKE1和SPOKE2都在NAT设备后面，公网地址是相同的，但是注册地址不相同；HUB设备使用的是自己的公网IP地址上线，显示也穿越了NAT设备。还可以看出链路协议是IPsec over UDP，是有安全封装的。

查看VAM Client的状态机信息。

在HUB设备上查看OSPF邻居信息。状态为DROther，表示路由器既不是所连网络的指定路由器，也不是所连网络的备份指定路由器。

查看HUB上的IPv4 ADVPN隧道信息，可以看到类型都是Hub-Spoke，说明本端是HUB角色，对端是SPOKE角色。

查看VSR1上的IPv4 ADVPN隧道信息，可以看到类型是Spoke-Hub，说明本端是SPOKE角色，对端是HUB角色。

此时SPOKE2和SPOKE1之间是没有隧道的，我们还是和上次一样，手工触发一下。

建立失败。难道是因为两个SPOKE使用同一个公网IP地址的原因吗？

没办法，只能换个IP地址再装一次了。

重装之后，两个SPOKE的公网IP地址不一样了。

再测试就好了。

可以看到TTL从254变成了255，时延也从15 MS降到了6 MS。

通过对比时延，可以看到，分支互访的时延比分支到总部的还要低1 MS，说明分支之间的互访是没有从总部绕转的。

会话类型是Spoke-Spoke的捷径，链路协议是IPsec-UDP的加密封装。

所以，分支之间的互访是没有从总部绕转的，而且分支不能使用同一个公网IP地址上线，否则无法建立Spoke-Spoke捷径。当然，应该也没人这么用吧？

长按二维码
关注我们吧

快速部署新鲜出炉的EVE-NG 5.0，并导入VSR镜像

把EVE-NG干趴下了！34台设备+1600行配置的小实验有多可怕

付出总有回报，全国SRv6组网实验成功了！

一种基于IPsec的VXLAN“专线”解决方案

如何给最小化安装的主机装个远程桌面？

VPP配置指南：配置VXLAN隧道

VPP配置指南：穿越NAT的IPsec VPN配置及性能测试

IPsec VPN文章及知识点汇总【墙裂建议收藏】