上回书说到,我们用MSR810-W-LM搭建移动ADVPN网关()。有朋友就问了:方案虽好,但总部不还是需要IPv4公网地址吗?我可是一毛不拔的铁公鸡,不想花这个冤枉钱!
那么,有没有一种可能,让咱们能花小钱办大事,甚至实现白嫖级别的组网呢?
答案是:有!咱们把目光投向那片更广阔的免费土地——IPv6,我们来尝试一下IPv6承载的ADVPN。
在前面介绍IPv6的时候(),我们就发现IPv6和IPv4的骨干网是有差异的。
同样是北京和衡水两地的数据中心互联,使用ADVPN的Spoke-Spoke捷径直接进行转发,平均时延为17.550 ms;使用GRE over IPv6隧道进行转发(),平均时延为19.474 ms。理想很丰满,现实略骨感。测试结果有点出乎意料,说好的IPv6高速公路更快呢?看来网络世界的新路也得经过一番磨合才行。
实际上,上面的两个时延都是封装过的,如果直接使用IPv6地址进行测试,平均时延只有16.037 ms。但是,我们没有办法直接测得IPv4的互访时延,无法判断。我通过traceroute的方式找了一个中间节点(),北京到这个节点的时延为12.931 ms,衡水到这个节点的时延为2.983 ms,合计15.914 ms,还是比IPv6要快一些。
那ADVPN大概增加了多少时延呢?
从北京进行测试,直接访问时延为5.549 ms,通过ADVPN访问时延为6.093 ms,大约增加0.544 ms。
从衡水进行测试,直接访问时延为13.169 ms,通过ADVPN访问时延为13.814 ms,大约增加0.645 ms。
按照比较小的值计算,减掉ADVPN的开销,IPv4直连的时延最高也就是16.905 ms,跟IPv6直连的时延差不多。
无论是IPv4还是IPv6,网络质量整体都是比较稳定的,所以如果我们换用IPv6来承载ADVPN,理论上体验不会有明显差异,但是成本会大幅下降。
我们配置ISP作为IPv6 PPPoE服务器(),让其余3台设备都从其拨号获取IPv6地址。
配置完成之后,ISP设备的IPv6地址信息如下:
HUB设备的IPv6地址信息如下:
SPOKE1设备的IPv6地址信息如下,可以访问HUB设备的IPv6地址:
SPOKE2设备的IPv6地址信息如下,也可以访问HUB设备的IPv6地址:
这样,我们模拟PPPoE的底层环境就搭好了。剩下的ADVPN配置也很简单,对比IPv4配置,主要是将IPv4地址换成了IPv6地址,直接上配置。
HUB设备同时作为VAM服务器,配置如下:
#domain advpnauthentication advpn local#domain default enable advpn#local-user HUB class networkpassword simple HUBservice-type advpn#local-user SPOKE1 class networkpassword simple SPOKE1service-type advpn#local-user SPOKE2 class networkpassword simple SPOKE2service-type advpn#vam server advpn-domain ADVPN id 1pre-shared-key simple ADVPNserver enablehub-group HUBhub ipv6 private-address 2222::2spoke ipv6 private-address range 2222:: 2222::FFFF:FFFF:FFFF:FFFF#vam client name HUBadvpn-domain ADVPNserver primary ipv6-address 2002::2pre-shared-key simple ADVPNuser HUB password simple HUBclient enable#ike keychain ADVPNpre-shared-key address ipv6 :: 0 key simple ADVPN#ike profile ADVPNkeychain ADVPN#ipsec transform-set ADVPNencapsulation-mode transportesp encryption-algorithm des-cbcesp authentication-algorithm sha1#ipsec profile ADVPN isakmptransform-set ADVPNike-profile ADVPN#ospfv3 1area 0.0.0.0#interface Tunnel1 mode advpn gre ipv6ospfv3 1 area 0.0.0.0ospfv3 network-type broadcastsource Dialer1ipv6 address 2222::2/64tunnel protection ipsec profile ADVPNvam ipv6 client HUB
SPOKE1设备的配置如下:
#vam client name SPOKE1advpn-domain ADVPNserver primary ipv6-address 2002::2pre-shared-key simple ADVPNuser SPOKE1 password simple SPOKE1client enable#ike keychain ADVPNpre-shared-key address ipv6 :: 0 key simple ADVPN#ike profile ADVPNkeychain ADVPN#ipsec transform-set ADVPNencapsulation-mode transportesp encryption-algorithm des-cbcesp authentication-algorithm sha1#ipsec profile ADVPN isakmptransform-set ADVPNike-profile ADVPN#ospfv3 1area 0.0.0.0#interface Tunnel1 mode advpn gre ipv6ospfv3 1 area 0.0.0.0ospfv3 network-type broadcastsource Dialer1ipv6 address 2222::3/64tunnel protection ipsec profile ADVPNvam ipv6 client SPOKE1
SPOKE2设备的配置如下:
#vam client name SPOKE2advpn-domain ADVPNserver primary ipv6-address 2002::2pre-shared-key simple ADVPNuser SPOKE2 password simple SPOKE2client enable#ike keychain ADVPNpre-shared-key address ipv6 :: 0 key simple ADVPN#ike profile ADVPNkeychain ADVPN#ipsec transform-set ADVPNencapsulation-mode transportesp encryption-algorithm des-cbcesp authentication-algorithm sha1#ipsec profile ADVPN isakmptransform-set ADVPNike-profile ADVPN#ospfv3 1area 0.0.0.0#interface Tunnel1 mode advpn gre ipv6ospfv3 1 area 0.0.0.0ospfv3 network-type broadcastsource Dialer1ipv6 address 2222::4/64tunnel protection ipsec profile ADVPNvam ipv6 client SPOKE2
查看注册到VAM Server的所有VAM Client的IPv6私网地址映射信息,可以看到HUB和SPOKE设备对应的隧道接口IPv6地址、公网IPv6地址、角色等信息。
查看HUB上的IPv6 ADVPN隧道信息,可以看到类型是H-S,说明本端是HUB角色,对端是SPOKE角色。
查看SPOKE1上的IPv6 ADVPN隧道信息,可以看到类型是S-H,说明本端是SPOKE角色,对端是HUB角色。
此时SPOKE1和SPOKE2之间是没有隧道的,我们需要手工触发一下。
可以看到,第一次触发的时候,hlim还是63,此时ADVPN的隧道状态是Establishing建立中。等S-S隧道建立成功之后,hlim就变成了64,说明SPOKE1和SPOKE2之间成功建立了直连隧道S-S。
一切配置就绪,我们看一下SPOKE2建立的IKE SA和IPsec SA信息,可以看到,隧道存在于SPOKE2和HUB、SPOKE2和SPOKE1之间。
咦?乱花渐欲迷人眼,IPsec SA怎么有6条?如果仔细看,下面的4条是重复的,其中有2条是历史遗留问题,是协商过程中产生的重复项。。
仔细对比IPsec SA信息,我们发现下面的两个的生成时间比上面两个要早5秒钟,理论上讲,清楚这两个应该是不影响通信的,咱们来个精兵简政,清理掉冗余项,网络通道立刻就清爽了!。
好了,现在正常了。从SPOKE1追踪到SPOKE2的路径信息.
可以看到,流量一跳直达SPOKE2,符合Full-Mesh模型的转发路径,即:Spoke设备和Spoke设备之间建立起了S-S隧道,可以直接通信,无需绕转Hub设备。互访流量跟IPv4的ADVPN一样(),直接走“捷径”转发。
金无足赤,人无完人。这套方案虽然简单,但目前的一个小遗憾是MSR810尚不支持IPv6的DDNS,需要借助第三方工具。如果你的IPv6地址相对稳定,这简直就是为你量身打造的低成本、高性能组网利器。这不比守着昂贵的IPv4要香得多吗?
***推荐阅读***
推荐站内搜索:最好用的开发软件、免费开源系统、渗透测试工具云盘下载、最新渗透测试资料、最新黑客工具下载……




还没有评论,来说两句吧...