号主:老杨丨11年资深网络工程师,更多网工提升干货,请关注公众号:网络工程师俱乐部
上午好,我的网工朋友
连接建立失败并不仅仅包含无响应问题,还有一种常见的情况,即RST(Reset)包的发送。
了解RST包的发送原因,是维护网络稳定性和安全性的重要技能。通过细致的RST包分析,可以有效地分析网络故障、优化网络性能和提升网络的安全性。
RST包是TCP协议中用来进行“连接重置”的数据包,今天就来围绕RST包进行详细展开讨论。
今日文章阅读福利:《 TCP协议详解及实战解析》
私信发送暗号“TCP”,即可获取此份独家资料。
01 TCP连接中为何会有RST包?
TCP RST包,即TCP头部中RST位设置为1的数据包。根据RFC 793,TCP RST包用于终止一个现有的连接或拒绝一个连接请求。
当一个TCP端点希望立即终止一个连接时,它会发送一个RST包。
因此,当客户端或服务器的任意一方需要拒绝连接,或认为连接出现错误时,即可以发送RST包重置当前TCP连接。
RST包在TCP时序图中的体现如图1所示:
图1:时序图中的TCP RST包
02 连接建立阶段的RST包如何分析?
在连接建立阶段,服务器可发送RST包拒绝连接建立,如图2所示,在连接建立阶段,服务器发送RST包,表示服务器拒绝连接。
图2:服务器拒绝连接
如果服务器发送RST包拒绝连接,一般可能由如下原因导致:
-
服务器端口未开放:服务器在该端口未运行网络服务,或服务器上客户所请求的服务失效,则服务器会通过RST拒绝新连接。
-
服务器TCP连接数达到极限:如果服务器设置了tcp_abort_on_overflow=1,那么服务器在队列满时会发送RST包拒绝连接。
-
Time_Wait状态:如果客户端使用的当前socket在上一个连接刚刚结束,且服务器当前socket处于time_wait状态,则此时使用该socket的新连接请求会被服务器拒绝,返回RST包。
-
SYN包格式错误:客户端发送的SYN包携带了其它未经允许的标记(例如FIN、URG或其他标记),则服务器会拒绝连接并直接返回RST
-
防火墙策略不允许:如果客户端IP被禁止连接,则会话中会出现RST包,此种情况在后文中具体讨论。
如果在会话连接建立阶段出现了服务器RST的情况,建议从服务器位置分析流量,或在系统层面排查连接建立失败的原因。
除服务器外,在连接建立阶段,客户端也有可能发送RST包,如图3、图4所示,在连接建立已经经历了SYN包、SYN/ACK包的交互后,甚至三次握手完成后,客户端突然发送RST包,表示客户端拒绝连接。
图3:客户端在收到SYN/ACK包后发送RST
图4:客户端在三次握手成功后立即发送RST
对于图3、图4中出现的情况,可以直接判断为客户端发生异常或客户端正在发起端口扫描攻击。
其中图3的流量为典型客户端发起TCP SYN端口扫描时序图,图4的流量为典型的客户端发起TCP Connect端口扫描时序图,如遇到此类时序图,请使用策略封禁该客户端IP地址,并检查客户端IP地址的其它流量,观察其有无其它攻击行为。
03 数据传输阶段的RST包如何分析?
在数据传输阶段,客户端和服务器均可能随时发出RST,此时RST的原因一定是连接出现异常。
对于此类故障,常见如下原因:
-
重传次数超限:TCP具有重传机制,当TCP尝试多次重传而无法收到对方的确认(或对方发来的确认无法被接收处理,例如序列号错误、校验和错误等种种字段错误)后,重传的一方将会认为连接出现错误,停止重传并发送RST包重置连接。如图5所示。
图5:多次重传后,服务器认为会话错误发送RST
-
连接长时间无数据交互:当客户端和服务器之间长时间(例如120秒)无数据交互时,其中一方可能认为会话超时,会向发送RST包重置连接。如图6所示。在客户端和服务器中间流量经过负载均衡或防火墙的场景,RST包也可能由负载或防火墙发出。
图6:120秒无交互后,服务器认为会话超时发送RST
如果在会话交互阶段出现了RST的情况,建议通过分析时序图判断重置的原因是错误或超时。如果怀疑RST包是从中间设备发出,可以通过对比多个位置的同时段流量,确定RST包来源,从而进一步排查故障原因。
04 被防火墙阻断的会话时序图是什么样的?
当ACL或安全策略匹配后的动作为Reject时,或安全设备是旁路部署无法直接丢弃流量时,安全设备会采用发送RST包方式去处理策略命中的会话,被RST的会话会因此中断。被安全策略阻断的会话如图7所示
图7:连接被其他设备RST阻断
通过图7可以看出,服务器响应了SYN/ACK包,而立刻回复了一个RST,这是由于发送RST包的设备为中间的安全设备,在进行旁路阻断时,只能通过发送RST进行阻断,而无法拦截服务器已发出的SYN/ACK包。
因此,从客户端处能够看到服务器“同时回复”了SYN/ACK包和RST包。
如果要问,为什么能判断这个RST一定是旁路阻断包,那可以仔细观察这些RST包,本文图1、图2、图4、图5、图6中的RST包,均为携带RST,ACK这两个标志位的“真RST包”,而图3、图7中的RST包是仅携带RST标志位的“假RST包”。
另外,如果能够对比RST包和SYN/ACK包的IP TTL,则可以发现这两个包的IP TTL可能不同(也有部分设备能对TCP RST包的IP TTL拟真),说明其来自于两个不同的网络位置,如图8所示:
图8:“假RST”与“真RST” 的TTL不同
图9则描述了一种更加容易理解的旁路阻断:客户端发送ClientHello包后,中间的旁路设备阻断了客户端,但未向服务器发送RST,导致服务器认为会话未中断,还在继续发送后续ServerHello数据包:
图9:旁路阻断RST
总之,如果会话过程中出现RST包,需要考虑该RST包是否由中间旁路阻断设备发出,可以通过该RST包的RST位、序列号、IP TTL等方式,或是直接多点抓包对比分析,综合判断。
05 连接断开阶段的RST包如何分析?
在连接断开阶段,也可能出现RST包,这种情况一般是由于接收FIN包的一方或中间的负载、安全设备存在关于连接断开的优化机制。
因为会话如果经过FIN包四次断开结束,先发FIN包的一方会经过TCP TIME_WAIT状态,经过2MSL时间才会进入到close状态,彻底关闭连接。
在2MSL时间段内,此socket不可用。而被RST重置的会话,则不存在TIME_WAIT状态,因此,一些连接在出现FIN包后,负载/安全设备认为该连接已经可以被结束,于是发送RST包快速关闭会话。
这种方法虽然快捷但不符合TCP协议标准。被RST加速断开的会话如图10和图11所示:
图10:客户端FIN后出现RST快速断开连接
图11:服务器FIN后出现RST快速断开连接
在TCP连接的生命周期中,RST包扮演了一个关键角色,通过时序图观察RST包出现时机的分析,我们可以看到RST包在连接建立、数据传输、异常阻断、连接断开阶段的出现原因和影响。
整理:老杨丨11年资深网络工程师,更多网工提升干货,请关注公众号:网络工程师俱乐部