• 文章搜索:
  • 唯快不破

        • 分享到...

        • 新浪微博
        • 腾讯微博
        • 推荐到豆瓣 豆瓣空间
        • 分享到搜狐微博 搜狐微博
        • 分享到QQ空间 QQ空间
        • 分享到腾讯朋友 腾讯朋友
        • 网易微博分享 网易微博
        • 添加到百度搜藏 百度搜藏
        • 转贴到开心网 开心网
        • 转发好友 告诉聊友
    • 推荐
    • 打印
    • 收藏

    丐帮安全通信之DVPN排查技巧

    作者:  |  上传时间:2014-11-26  |  关键字:丐帮安全通信之DVPN排查技巧

    自丐帮创立已有数百年之久,在历代帮主的带领下,得到了长足的发展,各地分舵兴起,帮众遍及武林各地,除暴安良,维护武林秩序,逐渐成为天下第一大帮,与少林、武当形成鼎立之势。

    然丐帮众弟子较多,如何管理众弟子,使得通信隧道稳定安全,使之按照丐帮帮规统一行事,成为帮务管理一大难题。

    按照丐帮规定,每名弟子入帮时,必须要向丐帮总部报告自己所属的地址,然后根据所属地址,将其加入到相应的分舵之中。久而久之就形成了如下的丐帮结构分布图:

    随着丐帮规模的越来越大,由于其他门派的嫉妒,渐渐有一些人开始探听丐帮的信息,这极大的影响到了丐帮的发展。

    而丐帮的长距离通信主要依靠的通信隧道,很容易被其他门派干扰拦截,篡改通信内容的事件时有发生,为了不使得丐帮内务被他派探听到,各大长老出谋划策,决定采用DVPN方案,在传输信道上,对内容进行加密,采用ipsec加密信道,使得信息在被拦截之后,由于拦截者暗号对应错误,无对应解密密钥,依然无法破解丐帮内重要信息,使得丐帮得到了稳健的发展。

    然一日,中原南部地区,一分舵与众弟子进行联系时,发生了时而可以联系上,时而联系不上的问题,引起了帮内重视,于是派人南下进行审查。

    1、实地观察了解DVPN故障

    经过一众人彻夜赶路,实地了解,根据众弟子的描述,问题现象如下:

    该HUB下的一个Spoke设备,DVPN隧道上的OSPF协议会定时断开,会出现十多分钟断一次的问题,导致与总部通信过程中常常会出现中断,严重影响到了总部信息及指示的传达。

    经过多次观察发现,是DVPN隧道每隔十多分钟会断开一次连接,进而导致OSPF down掉,大概1到3分钟恢复,而运营商则认定通信链路无异常。

    通过到分舵Hub进行了解,该分舵下面只有一个Spoke分支有此问题,其他分支,其他分舵均无此问题,为了节省工作和人力,就先排除其他分舵和分支,仅观察该分舵Hub和该分支Spoke的连接情况,以简化处理并快速定位问题。

    HUB设备采用了性能更强,版本更安全的V7版本的MSR3640设备,该HUB设备同时兼做VAM Server,MSR930做Spoke设备,MSR930通过联通3G卡拨号与HUB和VAM Server进行互连,组网图简化如下:

    说明: E:\常用文件\百日维新\无标题.jpg

    VAM Server与HUB的出接口地址为:124.160.106.130;

    Spoke设备走的是3G链路,获取到的地址为运营商内部私网地址。

    2、集中精力测试DVPN故障

    由于该分舵下的Spoke设备,没有公网地址,运营商也未对其开启telnet及SSH映射。所以只有在DVPN正常的时候,才能通过私网地址去访问到Spoke MSR930设备。当DVPN隧道建立正常的时候,分别登陆到VAM Server和Spoke设备上,查看VAM Server上设备的注册情况,发现此时HUB设备及Spoke设备均注册正常,如下

    但是仔细观察可以看出,Spoke设备的holding time只有0H 1M 47S,而Hub设备的holding time已经达到了23H 34M 9S,说明Spoke状态在之前出现过异常。

    从总部通过私网地址远程登录到Spoke设备,在Spoke设备上查看DVPN Session,如下:

    <H3C>dis dvpn session all

    Interface: Tunnel1 VPN name: system Total number: 1

    Private IP: 192.168.0.1

    Public IP: 124.160.106.130

    Session type: Spoke-Hub

    State: SUCCESS

    Holding time: 0h 4m 23s

    Input: 361 packets, 360 data packets, 1 control packets

    11 multicasts, 0 errors

    Output: 257 packets, 256 data packets, 1 control packets

    9 multicasts, 1 errors

    此时Spoke-Hub Session正常。

    多次观察, DVPN Session依然显示正常,如下:

    <H3C>dis dvpn session all

    Interface: Tunnel1 VPN name: system Total number: 1

    Private IP: 192.168.0.1

    Public IP: 124.160.106.130

    Session type: Spoke-Hub

    State: SUCCESS

    Holding time: 0h 8m 28s

    Input: 700 packets, 699 data packets, 1 control packets

    21 multicasts, 0 errors

    Output: 504 packets, 503 data packets, 1 control packets

    19 multicasts, 1 errors

    此时Holding time已经达到8m 28s,观察设备上的IPsec建立情况,IPsec建立正常,如下:

    但是等到12min时,DVPN Session突然出现异常,DVPN断开。

    再次进行测试,从Spoke的vam client的holding time在10m 34s处开始观察,此时ipsec建立正常,Spoke状态正常,如下:

    连续多次观察:

    可见在11m 39s时,状态还为online在线状态,当再次使用display vam client fsm时,spoke的当前状态已经变成了dumb静默状态,再过一会儿,再次使用该命令时,spoke的当前状态又变作了online在线状态,说明在12min时,Spoke设备出现了中断现象。证明该隧道存在定时12min闪断的情况。

    之后再通过总部VAM Server设备查看Hub和Spoke的注册情况,

    发现Spoke和Hub设备均正常注册,但是观察设备的holding time可以看出,Spoke设备的holding time只有4m 4s,说明Spoke设备存在中断的情况。

    在分支处多次进行测试,当spoke的holding time达到12min时会准时与VAM Server断开连接,怀疑链路可能存在问题。

    3、齐心合力测试链路

    在场所有长老均认为应该是中间的运营商链路存在定时闪断,于是协调该Spoke分支人员,由于分支Spoke MSR930设备是隐藏在nat后面的,只能从分支Spoke设备ping HUB及VAM Server设备进行ping测试,来判定链路情况。

    经过之前的测试,确定时定时12min会出现一次中断。于是乎要求该Spoke MSR930分支人员,当设备的holding time快要达到12min时,从Spoke处长ping HUB&VAM Server设备。

    在Spoke设备上,长Ping 1000个包到VAM Server设备

    一直ping到第一千个包,均未出现丢包情况,如下:

    此时已经跨越了12分钟界限,说明链路并无异常。

    在此时VAM Server上同时观察,当刚跨过12min时,从VAM Server上查看注册上来的设备时,已经只剩下了HUB设备,没有了Spoke设备,如下:

    连续观察,再过一会儿,Spoke设备又注册上来了,如下:

    经过多次观察情况均是如此,由此怀疑是设备上某端做了ipsec或者VAM keepalive超时设置。

    4、认真细致检查配置

    首先检查Spoke MSR930上主要配置情况,并对比HUB及VAM Server的配置,MSR930设备上主要配置如下:

    ike peer 1

    pre-shared-key simple 123456

    nat traversal

    #

    ipsec transform-set 1

    encapsulation-mode tunnel

    transform esp

    esp authentication-algorithm md5

    esp encryption-algorithm 3des

    #

    ipsec profile 1

    ike-peer 1

    transform-set 1

    #

    vam client name spoke

    client enable

    server primary ip-address 124.160.106.130

    user admin password simple 123456

    vpn system

    pre-shared-key simple 123456

    #

    interface Tunnel1

    ip address 192.168.0.3 255.255.255.0

    tunnel-protocol dvpn udp

    source Cellular2/0

    ospf network-type broadcast

    ospf dr-priority 0

    ospf bfd enable

    bfd min-transmit-interval 800

    bfd detect-multiplier 4

    ipsec profile 1

    vam client spoke

    MSR3640的主要配置如下:

    interface Tunnel1 mode advpn udp

    ip address 192.168.0.1 255.255.255.0

    ospf network-type broadcast

    ospf dr-priority 0

    ospf bfd enable

    source GigabitEthernet0/0

    tunnel protection ipsec profile 1

    bfd min-transmit-interval 800

    bfd detect-multiplier 4

    vam client hub compatible advpn0

    #

    domain system

    authentication advpn local

    accounting advpn local

    #

    local-user admin class network

    password simple 123456

    service-type advpn

    authorization-attribute user-role network-admin

    authorization-attribute user-role network-operator

    #

    ipsec transform-set 1

    esp encryption-algorithm 3des-cbc

    esp authentication-algorithm md5

    #

    ipsec profile 1 isakmp

    transform-set 1

    ike-profile 1

    #

    ike profile 1

    keychain 1

    #

    ike keychain 1

    pre-shared-key address 0.0.0.0 0.0.0.0 key simple 123456

    #

    vam client name hub

    advpn-domain system

    server primary ip-address 124.160.106.130

    pre-shared-key simple 123456

    user admin password simple 123456

    client enable

    #

    vam server advpn-domain system id 1

    pre-shared-key simple 123456

    server enable

    hub-group 0

    hub private-address 192.168.0.1

    spoke private-address range 192.168.0.0 192.168.0.255

    确认设备设置无异常,并且未有时间配置,关于keepalive时间均采用了默认配置,然后检查设备版本,MSR3640版本为:Version 7.1.049, Release 0106P02,MSR930设备版本为:Version 5.20, Release 2313,仔细对比版本说明书及配置指导,均未发现存在已知的软件bug和需要什么特殊的配置,说明软件版本无异常。

    5、尽心竭力分析调试信息

    经过之前的测试和配置检查,均未发现有异常之处,所以希望可以从debug信息中找到一些蛛丝马迹,于是协调两端人员同时开启debug调试。

    在Spoke设备上采用:

    <H3C>debugging ike all

    <H3C>debugging ipsec all

    <H3C>debugging vam client all

    在hub及VAM 设备上采用

    <H3C>debugging ike all

    <H3C>debugging ipsec all

    <H3C>debugging vam client all

    <H3C>debugging vam server all

    通过收集debug信息,确认IPsec协商和vam协商在设备注册和隧道建立时,交互并无异常,说明配置IPsec及vam配置并未有异常,也非存在V5与V7对接不兼容的情况。

    但是,过一段时间时间之后,链路还是会出现断开。

    通过长时间两端同时开启debug收集IPsec和vam的debug信息,仔细观察发现,在Spoke设备成功注册到VAM Server上,并与HUB设备建立起隧道之后,本端设备发出vam的keepalive报文,连续三次,均未收到正常回复,于是spoke状态从online转变为dumb,接着将hub设备标记为down,隧道断开。

    此时多位长老依旧怀疑存在有链路问题,然再次长ping多个包,还是一样的情况,未出现丢包。

    通过仔细对比MSR3640上收集的debug信息,发现在MSR36上每隔三分钟就会收到一次错包。

    此时就怀疑存在这样一种情况,Spoke设备所处的运营商处存在动态nat,并且老化时间较短,而keepalive报文的发送时间间隔是180s,这个时间应该超过了运营商的中间nat老化时间,进而导致收到的keepalive报文异常。

    6、众人齐力解决问题

    与各大长老商议之后,尝试将vam的keepalive报文发送时间间隔改小,在VPN域视图下,使用keepalive interval X retry Y命令,当将keepalive的发送时间间隔改为20s以内时,观察超过12分钟以上未发生中断,说明之前的预想是正确的。后再次联系运营商,提交证据,运营商才认可,整改之后,问题彻底解决。

    心法秘籍:

    在缺省情况下VAM Client发送Keepalive报文的时间间隔为180秒,重发次数为3次。

    VAM Client和VAM Server之间通过Keepalive报文保持联系。VAM Client按照VAM Server指定的时间间隔向VAM Server发送Keepalive报文,VAM Server收到Keepalive报文后回复响应报文。当Keepalive报文的重发次数达到指定的值仍没有收到VAM Server的响应时,VAM Client认为与VAM Server的连接中断,不再发送Keepalive报文。当VAM Server在时间间隔×重发次数的时间内没有收到VAM Client的Keepalive报文,则认为与VAM Client的连接中断,会删除该VAM Client的信息并将其下线。

    需要注意的是,如果VAM Server与VAM Client间存在配置了动态NAT的设备,则Keepalive报文的发送时间间隔应小于NAT表项的老化时间,从而保证NAT表项不会老化,以保证通信链路的正常。