最近项目上两台7150SSL VPN集群出了问题,具体现象如下:
出现问题时集群的两台VPN(IP最后一段分别为185和186,集群IP187),185上的所有用户无法访问发布的资源,而186上的用户可以正常访问没有问题,并且基本会每天持续5~10分钟左右,现象很短,这给问题排查带来了不少难度。
当然了,在第二次出现问题的时候首先想到的就是拨打咱们的强大400售后,和后台工程师大致说明情况后,等到第二次出现问题时粗略看了下,二话不说拉了咱们的TD研发技术支持……
看来问题不简单啊,然后三人拉到一个群,天天有情况就群里吼一声赶紧到VPN后台ping一ping抓抓包什么的。
前几次排查由于问题时间短,操作也比较慌忙,TD在后台ping内网服务器地址——不通,ping网关(190)——不通(第一次ping错了……),好吧那可能是设备到网关链路出了问题。
VPN这边的拓扑很简单,两台VPN分别连接到两台二层交换上,两台二层交换堆叠,也就是说逻辑上两台VPN实际连接到同一台交换机上。到机房检查线路、指示灯发现没什么问题。然后telnet到交换机上查看arp吧……
也没有发现一个IP地址对应多个MAC地址啊,应该是没有IP地址冲突的问题,而且这里IP地址管理严格并且只给VPN划分了/29的掩码为一个VLAN基本上不会出现IP地址冲突的问题,所以这个原因排除。
那是不是交换机端口报错?
看了下errors和collisions数量都为0,这里也没有什么问题。
然后恰巧此时VPN又出现访问不了资源的问题了,而且这次我发现我的VPN在186上,貌似是分配到两台VPN上的用户都无法访问资源。赶紧联系工程师后台排查。
后台ping了一下内部的服务器IP不通……返回来再ping服务器网关结果通了!!再返回去ping内网服务器IP也通了……现象消失了……
这真是难为我们这TD了,到最后也不知道问题出现时网关通不通。
太费劲了,不过后台工程师大致感觉应该是出现问题时VPN与网关之间是无法互通的,那么结合我之前的排查结果应该是VPN这边的问题了,究竟什么问题?后台工程师推测:结合刚才排查的现象,如果ping服务器不通而ping网关才彻底通,则可能是二层ARP没有发包获取网关的MAC地址……从而VPN ping不通网关,也就产生了资源无法访问的故障。(其实也不准确,如果ping不同网段的地址设备不是会先找网关吗,那肯定会找网关的MAC地址然后通信)随后工程师做了个free arp脚本在后台进行观察。
等正式结果出来后我也会在这里跟大家分享!
捎带科普: 免费ARP:主要用于检测网络中IP地址是否冲突,它是一种功能而非协议。当设备重启或代理ARP功能开启时就会向本地网络主动发免费ARP以检测IP地址是否冲突。免费ARP是以源、目的IP都是自己,源MAC也是自己,目标MAC是广播,即向自己所在网络请求自己的MAC地址,当网络中如果有其他主机使用了与自己相同的IP地址,他就会给主机一个ARP回复,此时如果发免费ARP的主机收到了回复就证明自己所用的IP地址有冲突,如果没有收到回复则说明没有IP地址冲突。 |