上次说好的SSL VPN问题的分享的文章终于可以赶在2017的最后一天补上了,不得不说年底就是忙啊,好在还能回家过元旦!
开头先致敬所有继续在一线奋战的战友们!
---分割线---分割线---分割线---分割线---分割线---分割线---分割线---分割线---分割线---分割线---
话说遇到问题搞不定,烧三炷香,接下来听天由命!
呵呵,问题客户不管你这套玄学~
上次的VPN问题拉了咱们某公司的TD和机房的驻场运维工程师(华三)一起排查故障。
可能是咱们IT售后传统的套路吧,故障不明确两家来回踢皮球,搞得我自己很被动啊
硬下头皮自己理清思路反复验证推敲,之前某公司TD怀疑是VPN设备的ARP出了问题,请求网关地址不回复,可能是导致网络丢包的原因之一,所以放了free arp脚本,但是之后的测试并不乐观,情况并没有好转,现象仍然一样,网络时断时续。
这个时候我不由的想到了上次在这个机房发生的同样的问题——ADS上架一段时间后就丢包。这个问题的原因是抗DDOS拦截了大流量,当然当前系统的组网也是比较特殊,VPN采用旁路部署,代理外网VPN用户来访问系统,所以整个内网的流量源地址都是两台集群VPN的IP地址(185、186),只是后面跟的端口号不一致而已。这种特性很容易导致内网的安全设备识别VPN业务流量为洪水攻击。由此我开始按照自己的思路开始排查,让机房管员出拓扑图跟着拓扑图走一遍,尤其是安全设备不管是IPS、IDS、防火墙、WAF等等都把内部的配置和log过一遍,查看是否有185和186地址相关的条目。
这个建议提出来肯定遭到了机房运维和管理员的反对,对方给出的理由是把其中一台VPN(185)替换为笔记本,然后配置相同的IP地址进行ping测试,我遵照他们的说法测试,结果发现ping过程无丢包,这样他们深信是VPN的问题,和自己的网络环境没有关系。但是回到VPN看现象,在网关和ARP都正常的情况下丢包现象还是会发生,所以我坚定地认为和安全设备有关系,对方百般无奈之下只好硬着头皮排查设备log。
由于网络环境较大较复杂,而且机房管理员是外包比较不专业,只能负责输入用户名密码,所以安全设备排查用了半天的时间。
好在功夫不负有心人,最后故障定位到了一台华三的IPS,看到日志有185和186的记录顿时很兴奋,和我的推测基本是完全一致的。设备log记录显示【来自源地址185和186的流量识别为扫描攻击被拦截】,看到这个结果我心里的石头算是放下来了,终于舒了一口气。问题定位了,也是很简单的配置问题(庆幸非设备bug ),接下来他们做的就很简单了。
安全策略重新配置后业务恢复正常,真的是心里暗喜,成功了装了一波逼~
这两次网络丢包故障让我发现安全配置虽然很必要但是前期的业务特性一定要弄清楚,否则物极必反。同事在网络故障排查的过程中也要基于业务特征去排查,在这个事件中如果忽略源地址185、186大流量代理访问的特性这个问题一辈子都查不出来。 |