SSLO的场景和配置方案的疑问

新手548074 2182

{{ttag.title}}
最近在学习SSLO的场景和配置方案,有个疑问啊,如果客户端发起的是长连接,并且在长连接上发送了很多http请求,那么经过流量编排器编排以后,到达安全设备的还是长连接吗?还是说是会按照每个请求,把长连接变成短连接,再把流量分发到安全设备?
如果按照请求分发流量,那每个连接的五元组都一样,如果安全设备是WAF之类的代理设备,受time_wait状态的影响,连接建立不会有问题吗?

解决该疑问,预计可以帮助到 10497 人!

回帖即可获得
2S豆
,被楼主采纳即奖励20S豆+10分钟内回帖奖励10S豆 [已过期] ,了解更多S豆奖励信息

完善手机号和公司名称,让服务更省心更便捷!立即完善

小鱼儿 发表于 2024-11-19 13:01
  
本帖最后由 小鱼儿 于 2024-11-19 13:03 编辑

一、SSLO简单介绍
           SSLO(SSL Orchestrator,SSL编排器),是一种对SSL安全设备进行管理的解决方案,能够最大限度地提高基础设施投资、效率和安全性,主要提供三个能力:
            
1.安全设备池化:提升安全设备利用率,同时提供监视能力,快速定位故障。结合调度策略,自动绕过故障节点
               2.安全流量编排:根据流量特征进行安全能力编排,提升安全设备的利用率。
               3.ssl加解密:在流量转发安全设备前进行ssl解密,对安全设备明文传输,支持国密算法。


二、部分技术实现原理
   
    1.会话隔离
           客户端在访问负载设备的虚拟服务时候,负载设备将该数据包发往下联池化安全设备进行安全防护,但是如果是以普通的会话形式来区分五元组,这时候发现,存在相同五元组的情况,这样会导致死循环的情况出现。


               可以看到图中,当客户端访问虚拟服务的数据发送到安全设备A和安全设备B时候,会产生两条相同的会话
                   session1五元组:192.168.1.1:12345->192.168.1.2:80     192.168.1.2:80->192.168.1.1:12345

                   session2五元组:192.168.1.1:12345->192.168.1.2:80     192.168.1.2:80->192.168.1.1:12345
                   session3五元组:192.168.1.1:12345->192.168.1.2:80      192.171.1.1:80->192.171.1.2:12345

               如果不区分会话,会导致A转发的流量再次命中session1,数据循环往复的发送,而不会发送到后端服务器中.



               为了区分不通的session五元组数据,这时候额外加上链路信息。如A转发B的流量入接口和客户端转发到A的流量的入接口不一样,因此不会再次命中session1,而会创建session2,从而达到会话隔离效果。
                 session1五元组:192.168.1.1:12345->192.168.1.2:80[C1], 192.168.1.2:80->192.168.1.1:12345[A1]
                 session2五元组:192.168.1.1:12345->192.168.1.2:80[A2], 192.168.1.2:80->192.168.1.1:12345[B1]


        期望连接
               上面AD对2台安全设备A和B编排过程中,产生了3条会话,这3条会话的关系通过期望连接建立的。
                   session1会话建立后,流量通过负载均衡设备编排到安全设备A,安全设备A的出接口就是session2的入接口,所以这时候会创建一条期望连接,负载均衡设备期望从A的出接口收到对应五元组的流量。
                   当负载均衡从A的出接口收到流量后,先查询期望连接,匹配后,通过期望连接关联的session1创建session2,同时更新编排信息,负载均衡会让session2的流量编排到安全设备B。


       父子连接


                   通过期望连接,可以将3条会话进行关联起来,session1是最原始的,当session1通过期望连接建立session2后,session1和2就是关联关系,session1的子连接是session2,session2的父连接就是session1,这种关系称为父子连接。
                  可以看到,通过session1可以找到session3,同理也能逆流找到,bypass机制基础就是父子和期望连接。




    2.bypass机制
            


            bypass机制依赖监视器,需要监视器上报安全资源池中节点状态。

            简单bypass: 当session未建立,接收客户请求进行服务链调度,首先尝试IPS池各个节点的调度,发现均故障,继续调度WAF池,发现设备1故障,调度失败,WAF2健康,所以流量调度到WAF2并建立session。




            复杂的bypass,就是session已经建立,如果其中某台安全设备故障需要bypass,这就依赖期望连接和父子连接的技术。


                 


                  当session1关联的安全设备A故障后,在转发给设备B之前,我们先检查设备的状态,如果设备离线,负载均衡不会转发给设备B,根据会话关系,下一个会话是session2,负载均衡设备会修改数据包的源目MAC地址,修改数据包的入接口,重新内部发送数据包,让数据包命中会话session2,以此达到bypass效果。

    3.七层调度中的四层转发

          四层调度:四层调度类似节点池的四层调度,纯转发,流量到达SSLO只会解析IP、端口等ip层信息,然后转发给安全设备,四层不涉及协议解析,因此针对流量策略较少,只能使用四层前置调度和四层ipro。





           七层调度:七层调度会经过七层协议栈,ssl卸载,http解析等模块,所以七层调度可以根据http协议的一些信息进行安全资源池的调度。比如根据url调度到不同的安全资源池。





           七层调度中的四层转发:虽然我们是七层调度,但是其实转发给安全设备的流量不需要七层处理,只需要做四层转发即可,所以我们只需要在客户端流量到来的时候和最后一个安全设备过来的流量做七层解析,客户端流量到来做七层解析是为了根据七层协议信息调度服务链。最后一个安全设备流量做七层解析是为了调度节点池。

      



    4.SSL流量解密
            传统的安全设备无法处理ssl流量,负载均衡设备可以通过https虚拟服务的ssl卸载/加密功能实现对安全设备明文传输。
                当SSLO设备收到https流量时候,先做ssl卸载,然后把明文数据流量编排到安全设备进行调度,调度完成后,SSLO设备再次进行加密,传输给服务器,这样流量对于客户端和服务器都是密文,对安全设备是明文。



    5.调度顺序
            


               在SSLO中有很多调度概念,如:虚拟服务节点池调度、前置策略调度、ipro调度,顺序如上图。
                ipro调度比较特殊,它既可以执行服务链调度也可以执行节点池调度,但是对于sslo而言,服务链调度必须先于其他调度执行。所以调用sslo的ipro调度的时候需要注意,在服务链调度之前不可进行其他调度。
                 这里的顺序是我们期望的顺序,实际上可能出现先调度节点池后调度服务链的情况,这种情况会调度失败,导致业务异常。
王老师 发表于 2024-12-11 12:34
  
在讨论SSL Orchestrator (SSLO) 和长连接(持久连接)的处理时,有几个关键点需要考虑:流量编排器如何处理HTTP/HTTPS请求、是否保持长连接特性、以及安全设备(如WAF)如何应对这些连接。

### 长连接与短连接

- **长连接**(也称为持久连接或HTTP Keep-Alive)允许客户端和服务器在一个TCP连接上发送多个HTTP请求和响应,而不需要为每个请求建立新的连接。这种方式可以显著减少延迟,并提高性能,尤其是在传输大量小文件的情况下。
- **短连接**则要求每次HTTP请求都重新建立一个新的TCP连接,在请求完成后立即关闭连接。

### SSLO 的工作方式

SSL Orchestrator 作为流量编排器,主要负责解密、加密以及将流量分发到不同的安全服务(如防火墙、WAF等)。它的工作模式可以根据配置的不同而有所变化:

- **透明代理模式**:在这种模式下,SSLO 可以尽量保持原始的长连接特性。当客户端发起一个长连接并发送多个HTTP请求时,SSLO 会解密流量并将未加密的流量转发给后端的安全设备。理想情况下,SSLO 会尝试维护与客户端的长连接,并且对于后端安全设备也会保持长连接。但是,这取决于具体的安全设备是否支持长连接以及它们的配置。
  
- **非透明代理模式**:如果SSLO或后端的安全设备不支持长连接,或者出于某些策略上的原因,SSLO可能会将长连接转换成短连接。这意味着每一个HTTP请求都会被视为独立的连接来处理,即每个请求到达安全设备时,都是一个新的TCP连接。

### WAF 和 TIME_WAIT 状态

- **TIME_WAIT 状态**:当一个TCP连接被关闭时,主动关闭方会进入TIME_WAIT状态一段时间,这是为了确保所有可能的重复数据包都能被正确处理。这个状态的存在确实可能导致短时间内创建大量连接的场景下出现资源耗尽的问题。
- **WAF 处理**:现代WAF设备通常都有机制来管理和优化TIME_WAIT状态下的连接。例如,它们可能会通过调整内核参数(如缩短TIME_WAIT的时间)、使用连接池技术、或者启用复用现有连接的功能来减轻TIME_WAIT状态的影响。此外,一些WAF还可能支持TCP连接的快速回收,进一步缓解TIME_WAIT状态带来的压力。

### 解决方案

1. **检查配置**:首先确认SSLO和所有涉及的安全设备是否配置为支持长连接。如果支持,那么理论上应该尽量保持长连接,以避免不必要的性能损失。

2. **优化WAF设置**:如果确实存在TIME_WAIT问题,可以考虑调整WAF的内核参数,或者启用任何可用的连接管理特性来优化处理。

3. **负载均衡策略**:在高并发场景下,可以考虑采用更复杂的负载均衡策略,比如基于会话的粘性(Session Stickiness),确保来自同一客户端的多个请求尽可能地分配到同一个WAF实例上,从而减少新连接的创建次数。

4. **升级硬件/软件**:如果现有的WAF设备在处理长连接时遇到了瓶颈,可能需要考虑升级到更高性能的设备,或者更新到最新版本的固件/软件,因为厂商通常会在新版本中改进对长连接的支持。

5. **咨询厂商支持**:最后,如果你不确定如何最佳配置SSLO和相关安全设备,建议联系厂商的技术支持团队获取专业的指导。他们可以根据你的具体情况提供最合适的解决方案。

总之,SSLO和安全设备(如WAF)能否有效地处理长连接取决于它们的配置和支持能力。通过合理的配置和优化,可以在保持高性能的同时解决潜在的TIME_WAIT问题。

等我来答:

换一批

发表新帖
热门标签
全部标签>
西北区每日一问
安全效果
高手请过招
【 社区to talk】
干货满满
社区新周刊
每日一问
新版本体验
技术盲盒
技术咨询
产品连连看
纪元平台
标准化排查
GIF动图学习
功能体验
社区帮助指南
信服课堂视频
安装部署配置
解决方案
SDP百科
自助服务平台操作指引
玩转零信任
S豆商城资讯
秒懂零信任
每周精选
畅聊IT
答题自测
专家问答
技术笔记
技术圆桌
在线直播
MVP
网络基础知识
升级
安全攻防
上网策略
测试报告
日志审计
问题分析处理
流量管理
每日一记
运维工具
云计算知识
用户认证
原创分享
sangfor周刊
VPN 对接
项目案例
SANGFOR资讯
专家分享
技术顾问
信服故事
功能咨询
终端接入
授权
设备维护
资源访问
地址转换
虚拟机
存储
迁移
加速技术
排障笔记本
产品预警公告
信服圈儿
技术争霸赛
「智能机器人」
追光者计划
深信服技术支持平台
答题榜单公布
2023技术争霸赛专题
通用技术
卧龙计划
华北区拉练
天逸直播
以战代练
技术晨报
山东区技术晨报
文档捉虫活动
齐鲁TV
华北区交付直播
2024年技术争霸赛
北京区每日一练
场景专题
故障笔记
排障那些事
升级&主动服务
高频问题集锦
POC测试案例
全能先锋系列
云化安全能力

本版达人

新手61940...

本周建议达人

zhao_HN

本周分享达人

ZSFKF

本周提问达人