某专线用户无法打开网页故障处理

1某专线用户无法打开网页故障处理一、问题描述2015年8月，XX移动反馈有一电厂用户访问新浪等网站子页面时，一定概率（20％～39%）出现无法访问。组网结构：用户PC-交换机-E1000E防火墙(双机热备)-城域网SR-互联网二、我公司的排障思路1、下挂用户终端问题，感染同类病毒等；2、二层网络问题；3、DNS问题；4、E1000E防火墙问题；5、其它原因；三、详细解决过程1、通过测试排除了1-3项的问题；2、分析现网客户端的抓包文件，发现部分业务故障的报文是因为TCP窗口为0导致无法发送数据报文。3、分析当时采集的防火墙日志信息，发现日志中有大量的的syn-flood攻击防范日志，说明当时syn报文速率大于配置的阈值。2015-08-2713:25:18CCFW02BHW%%01SEC/4/ATCKDF(l):AttackType:SYNfloodattack;ReceiveIfIndex:Eth-Trunk1.991Eth-Trunk2;from10.153.143.11410.155.142.18310.158.185.1310.149.102.22710.153.17.1110.159.38.16610.154.13.710.154.213.4910.153.39.11610.193.185.11510.201.139.17710.155.188.118;to221.179.18.180120.204.201.21658.250.132.79210.22.123.742123.126.62.85125.39.24.73111.13.12.25211.136.236.7117.135.130.154113.31.82.163222.35.252.10961.182.131.37;begintime:2015/8/2713:24:46;endtime:2015/8/2713:25:17;totalpackets:45887;maxspeed:1891(packet/s);……2015-08-2713:24:16CCFW02BHW%%01SEC/4/ATCKDF(l):AttackType:SYNfloodattack;ReceiveIfIndex:Eth-Trunk1.991Eth-Trunk2;from10.158.141.62117.136.9.23410.154.54.27111.155.209.17610.155.46.12510.201.200.4510.201.12.14810.154.233.14910.155.188.9910.154.195.610.193.139.7710.150.25.186;to23.21.171.71117.136.6.69111.30.130.100117.136.6.70183.221.245.29111.30.130.104219.141.183.51111.13.12.162223.87.1.5869.28.54.212117.135.130.186121.37.43.40;begintime:2015/8/2713:23:46;endtime:2015/8/2713:24:14;totalpackets:43999;maxspeed:1897(packet/s);……4、检查防火墙攻击防范配置,开启了syn-flood攻击防范，基于接口的默认阀值为1000pps，当syn报文的速率超过1000pps时，防火墙会启用TCP代理功能。firewalldefendsyn-floodenable5、检查防火墙双机热备配置,双机组网配置为负载分担，在这种组网下存在来回路径不一致的情况。interfaceEth-Trunk0ipaddress192.168.30.156255.255.255.248vrrpvrid103virtual-ip192.168.30.153mastervrrpvrid104virtual-ip192.168.30.154slaveinterfaceEth-Trunk2ipaddress211.x.x.x255.255.255.248vrrpvrid105virtual-ip211.x.x.xslavevrrpvrid106virtual-ip211.x.x.xmaster36、从现网采集的会话信息也证实业务报文有来回路径不一致的现象，即如下：正向会话从备防火墙经过，而反向会话是从主防火墙经过。HRP_M[FW02BHW]displayfirewallsessiontableverbosesourceinside10.159.0.213:37:592015/08/16Currenttotalsessions:1tcpVPN:public-publicRemoteZone:gitrust-untrustTTL:00:20:00Left:00:19:57Interface:G0/0/0Nexthop:0.0.0.0MAC:00-00-00-00-00-00--packets:176bytes:11928--packets:0bytes:010.159.0.3:55124[117.136.6.67:9607]--58.240.47.50:5008HRP_S[FW01BHW]displayfirewallsessiontableverbosesourceinside10.159.0.213:38:022013/04/16Currenttotalsessions:1tcpVPN:public-publicZone:gitrust-untrustTTL:00:20:00Left:00:19:51Interface:E2Nexthop:211.x.x.xMAC:00-25-9e-2e-ea-18--packets:0bytes:0--packets:349bytes:2198410.159.0.3:55124[117.136.6.67:9607]--58.240.47.50:50087、防火墙TCP代理的原理如下图，前三次握手客户端跟防火墙完成，其中防火墙给客户端的syn+ack报文会话TCP窗口置0，后三次握手防火墙跟服务器完成，当防火墙跟服务完成后，防火墙会发送窗口更新报文给客户端，把原来为0的TCP窗口恢复。当存在来回路径不一致的时候（比如：客户端syn报文给主防火墙，主防火墙回syn+ack4给客户端，客户端又发送ack报文给主防火墙完成前三次握手，然后主防火墙发送syn报文给服务器，此时服务器回应的syn+ack报文没有走主防火墙，而是回给了防火墙），由于synfloodTCP代理的相关状态不支持备份，导致TCP代理失败从而影响业务。8、查看防火墙配置手册发现其中明确描述了在来回路径不一致的情况下，需要使用TCP反向源探测来防范synflood，而不是使用TCP代理。此外，在现网的抓包文件中发现部分报文在客户端收到防火墙发送的窗口更新报文后没有发送数据报文，而是服务器直接发送了FIN报文断开连接。9、解决方法客户端防火墙服务器①SynSyn-ackwindowsize=0②③Ack④Syn⑤Syn-ack⑥Ackwindowsize=65535⑦Ack51)调整syn-flood配置阈值，从1000pps调整至16000pps。2)对syn-flood攻击防范选择source-detect配置反向源探测。HRP_M[Firewall]firewalldefendsyn-floodEth-Trunk2max-rate16000source-detect四、故障结论及总结综上分析，业务故障中因为TCP窗口为0导致客户端无法发送数据报文的原因是防火墙开启了syn-flood功能，当syn报文速率超过1000pps时，防火墙启动TCP代理功能，在来回路径不一致的情况下，由于TCP代理的相关状态没有备份导致TCP代理失败，客户端TCP窗口没有恢复引起业务故障在处理防火墙设备下挂用户打开网页异常的问题中，除了进行常规的DNS解析是否正常、转发是否丢包等判断外，更多的要考虑防火墙的特性，如防攻击、ASPF、双机热备来回路径等相关机制对业务的影响。