场景1业务情况前后端TCP会话分离,AD作为业务B和认证服务器中间的会话代理设备,分别与业务B、认证服务器节点建立会话。
数据分析1、健康检查:监视器发包源IP是90地址,并且没有携带时间戳(没有配置系统时间戳),监视器与认证服务器四层报文交互正常
2、L7 TCP会话建立:
(1) 10.65.248.24先跟虚拟服务vip 10.65.161.90在前端建立TCP会话(图中第176-178报文,前端3次握手);
(2) SNAT地址10.65.161.90(自动SNAT)与10.65.161.82在后端建立TCP会话(图中第179-181报文,后端3次握手);
(3) 从SYN报文(第176号报文和179号报文)可以看出,业务B与AD之间的交互携带了时间戳,而AD与认证服务器之间并没有携带时间戳;
小结L7 TCP发布虚拟服务,分离了前后端的TCP会话连接,后端使用10.65.161.90跟节点池进行健康检查或业务转发都不带时间戳,那么认证服务器就不会进行时间戳校验,业务的流量转发和节点池心跳探测都正常。
场景2业务情况虚拟服务使用L4 TCP类型,使用10.65.161.90:6180发布虚拟服务,SNAT地址使用10.65.161.91。前端业务B与10.65.161.90建立TCP会话,后端10.65.161.91与节点池建立连接。
业务B访问虚拟服务正常,但省厅客户端tcping业务异常。
数据分析1、健康检查:监视器发包源IP是90地址,并且没有携带时间戳(没有配置系统时间戳),监视器正常
2、业务转换手动SNAT地址是10.65.161.91,业务层面发包是时间戳改写(TCP四层优化策略),也就是对于服务器来说,10.65.161.91源IP过来的数据有时间戳并且是有序的,业务正常
(1) 先找到一个业务正常的流量,通过端口来筛选;
(2) 场景2在业务层面配置了seq序列号修改;
(3) 场景2在业务层面配置了时间戳修改,可以看出数据包的时间戳是有序的(10.65.161.91 -> 10.65.161.82的数据包,TSval=2251581309,回包的时候Tsecr=2251581309):
小结健康检查使用10.65.161.90不带时间戳与节点池进行心跳检查;虚拟服务后端使用10.65.161.91与节点池进行TCP会话连接,时间戳按照前端数据包进行改写,认证服务器只校验业务报文的时间戳。
场景2中,健康检查的会话与业务流量的会话本身是隔离的,所以认证服务器只对业务流量进行时间戳校验,并且时间戳有序,节点池健康,业务正常。
场景3业务情况
数据分析1、筛选SYN报文,找到10.65.161.90发送到10.65.161.83的报文时间戳乱序(乱序的位置分别是第15号报文和第26号报文、第110号报文和第121号报文、第161号报文和第172号报文)
2、TCP四层优化策略,进行业务层面的seq和时间戳改写,即经过SNAT转发后的报文改写时间戳(注意:但监视器使用的是系统层面的时间戳,导致了同样通过10.65.161.90进行数据包发送,但是时间戳的参照不同,会存在偏移量)。
小结其实对比场景3(上图)的第26号报文和第121号报文可以看出(监视器默认5s发送一次检查包),负载系统层面发出的报文时间戳是递增的;业务层面转发的业务报文(非重传的那些报文),时间戳也是递增的。但是由于时间戳参照不同,导致发送到认证服务器进行时间戳校验时,发现健康检查的报文是旧数据包,被认证服务器丢弃,导致节点健康检查失败,随即故障状态。