admin/geedge-jira
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
42e3a9ba59612ce57d31021350c437ed48bde35b
geedge-jira/md/OMPUB-1125.md

250 lines
12 KiB
Markdown
Raw Normal View History

first
2025-09-14 21:52:36 +00:00
# bj环境统计单向流比例将近40%
| ID | Creation Date | Assignee | Status |
|----|----------------|----------|--------|
| OMPUB-1125 | 2024-01-24T17:06:36.000+0800 | 杨威 | 已解决 |
---
!image-2024-01-24-16-56-32-263.png|thumbnail!
请[~zhangzhihan]确认bj环境接入流量是否有存在单向流的情况**zhangzhihan** commented on *2024-01-24T17:13:52.817+0800*:
从sapp的sysinfo.log上看，tcp没有单向流，udp有单向流但比例不高
!screenshot-1.png|thumbnail!
---
**doufenghu** commented on *2024-01-24T17:55:10.848+0800*:
单向流计算：(asymmetric_c2s_flows + asymmetric_s2c_flows)/closed_sessions, 选取1月24日最近一小时(16:00-17:00) 单向流比例为38.81%。需Firewall协助排查下。
* asymmetric_c2s_flows + asymmetric_s2c_flows = 130,703
* closed_sessioins = 336,749
---
**yangwei** commented on *2024-01-24T20:44:14.964+0800*:
“选取1月24日最近一小时(16:00-17:00) ” 查询会话日志，共计337008条
!image-2024-01-24-20-31-19-292.png|width=609,height=278!
在这个范围内查询{*}session_record中{*}单向流(filter=“sent_pkts=0 OR received_pkts=0“), 共计130969条，可知{*}单向流比例130969/337008=38.8%，与issue描述一致{*}
!image-2024-01-24-20-32-30-278.png|width=1160,height=526!
统计单向流会话的decode as分布，99.67%为BASE，进一步增加过滤条件，仅统计单向流中BASE的IP分布，发现单向流的Client IP排名第一的为5.5.5.5，其余多为内网地址（10.xx或者192.168.xx），Server IP排名靠前的也基本为内网地址。
!image-2024-01-24-20-38-42-125.png|width=810,height=378!
!image-2024-01-24-20-41-06-328.png|width=814,height=373!
结论：通过查询会话日志，1月24日(16:00-17:00) {*}网关流量中接近40%为单向流，其中99%为UDP会话{*}，且通信的双方大部分为内网地址，{*}推测经过网关的流量存在内网地址间的测试流量{*}。
---
**yangwei** commented on *2024-01-25T09:58:12.184+0800*:
查询1月24日 23:00-24:00)的日志，共计110,232条，其中单向流49,069条，单向流比例44.5%，所有的的Decode path均为BASE。
!image-2024-01-25-09-29-21-037.png|width=721,height=310!
!image-2024-01-25-09-32-07-741.png|width=716,height=322!
!image-2024-01-25-09-33-40-660.png|width=713,height=406!
进一步分析，虽然功能端输出session_record设置需要达到的最小包数和字节数限制（目前限制为包数>3 AND 字节数>5），但是session_record中存在包数为1的记录，
存在该session日志的原因为，该session命中了一条Monitor_ALL的安全策略。
!image-2024-01-25-10-07-37-292.png|width=682,height=375!
 
---
**yangwei** commented on *2024-01-25T10:40:01.025+0800*:
综合上述情况，目前Live Traffic Chart和session_record统计指标存在如下问题：
* 问题1：session record过滤小流的限制条件，在session命中安全策略时仍然会被发送，并且在session record中能够被查询和统计，容易给用户造成困惑。
** 方案1：不再设置过滤小流的限制条件，对所有session进行记录
*** 优点：数据口径一致，不存在用户不可感知的隐藏参数
*** 缺点：日志量可能增加（按照各个现场的经验，由于UDP小碎流的存在，预计日志整体增加一个数量级）
** 方案2：界面开放给用户设置记录session record过滤小流的条件，查询session record时olap执行该条件
*** 优点：用户可感知参数，在设置合理的前提下，能够有效减少小流的日志量
*** 缺点：增加从界面同步的参数
* 问题2：Live Traffic Chart的数据源，对所有的session进行统计输出（未执行session record过滤小流的限制条件），会造成Live Traffic Chart计算的单向流比例，与session record不一致（结合问题1，当前Live Traffic Chart为全量统计结果，session record记录的是过滤后的小流+命中策略的所有流）
** 方案1：从Live Traffic Chart中展示单向流的比例目的出发，如果是向用户展示接入流量的完整性趋势，参照24.01版本之前仅根据session record计算的逻辑，Live Traffic Chart中单向流比例仅展示TCP会话相关的结果
*** 优点：单向流比例不受UDP流干扰，更能反应流量中整体的情况
*** 缺点：未统计所有流，与session record查询结果对比时需要增加ip protocol=tcp的过滤条件，可能增加给用户的解释成本
** 方案2：参照问题1的方案2，功能端输出Traffic Metric时，也执行小流过滤条件，仅输出满足条件的流的统计信息
*** 优点：数据输出口径保持一致
*** 缺点：未对所有流进行统计，增加给用户的解释成本
* 问题3：session record中，对于未达到满足app识别最小包数（当前值为20包）的流，功能端Application字段填充为-，在Live Traffic Chart中，Application值为-和unknown都被计算为unknown，该统计结果，与session record中的值不一致，容易给用户造成困惑。
** 方案1：功能端对未满足app识别最小包数的流，统一标识为unknown
*** 优点：数据口径一致
*** 缺点：Application为unknown可以作为策略条件执行，但对于未满足最小识别包数的流，在流结束时（通常为active timeout）执行安全策略无意义，此时产生安全事件日志容易给用户造成歧义（例如deny失效）
** 方案2：将app识别最小包数作为参数开放至界面允许用户配置，未达到最小识别包数的Application仍然被标识为-，同时Live Traffic Chart中增加-的统计行
*** 优点：用户可感知参数，减少解释成本
*** 缺点：当最小识别包数设置为较小的值时（例如1），安全策略不生效的歧义仍然存在
---
**yangwei** commented on *2024-01-29T13:38:51.554+0800*:
经2024-01-29讨论，上述3个问题，对应的解决方案选择如下：
{*}问题1{*}：选择{*}方案2{*}，界面在是否开启session_record的开关处，{*}增加可配置记录最小包数{*}（仅增加一个参数，减少用户配置的负担）的限制，默认值为2；用户查询session record时，UI查询olap时，增加该限制作为过滤条件。
{*}问题2{*}：{*}现有逻辑不做更改{*}。Live Traffic Chart统计的对象为全流量，session_record记录的是过滤后的流信息，两者的结果不能保证完全一致，仍然保留Live Traffic Chart记录所有流的特性
{*}问题3{*}：选择{*}方案1，{*}对于未满足识别长度即结束的流，统一标识为unknown，由于此时已不具备执行安全策略的条件（通常由时间触发active timeout，对应的session状态为closing），在此阶段不再执行安全策略。
---
**zhangwei** commented on *2024-01-31T15:57:17.319+0800*:
{quote}{*}问题1{*}：选择{*}方案2{*}，界面在是否开启session_record的开关处，{*}增加可配置记录最小包数{*}（仅增加一个参数，减少用户配置的负担）的限制，默认值为2；用户查询session record时，UI查询olap时，增加该限制作为过滤条件。
{quote}
在仍然有Management Vsys的版本中实现此功能，UI和CM在Management Vsys查询Session Records设置该限制作为过滤条件比较复杂，打破了现有CM补全Vsys过滤条件的实现逻辑。
* 当前实现：vsys_id in (1,2,3) and ($filter)
* 如增加最小包数限制作为过滤条件：( (vsys_id=1 and recv_pkts+sent_pkts>=$vsys1_min_packets) or (vsys_id=2 and recv_pkts+sent_pkts>=$vsys2_min_packets) or (vsys_id=3 and recv_pkts+sent_pkts>=$vsys3_min_packets) ) and ($filter)
 
---
**doufenghu** commented on *2024-01-31T16:28:20.330+0800*:
[~yangwei] 界面增加min_packets阈值后，UI查询OLAP默认为什么要增加过滤条件？Session Records 还会有小于min_packets的日志？
---
**yangwei** commented on *2024-01-31T16:34:39.265+0800*:
24.01以后，功能端生成session_record与策略日志合并，对于命中策略的会话，即使不满足min_packets的条件，依然会向session_record的topic发送该会话的信息（例如上述分析中提到的命中monitor_all策略，但仅传输1个包的情况）。
---
**doufenghu** commented on *2024-02-01T10:05:28.718+0800*:
建议命中策略并且小于min_packets的会话，查询时默认不对其增加过滤条件。目前会话日志设计上以流量为中心，以全局视角应看到所有命中策略的日志。
---
**gitlab** commented on *2024-02-05T18:47:12.855+0800*:
[刘学利|https://git.mesalab.cn/liuxueli] mentioned this issue in [a commit|https://git.mesalab.cn/tango/firewall/-/commit/9407dcda1f755ac66eac9ce8a9f986bd20de7cb3] of [TSG Appliance / firewall|https://git.mesalab.cn/tango/firewall] on branch [feature-tunnel-rename-encapsulation|https://git.mesalab.cn/tango/firewall/-/tree/feature-tunnel-rename-encapsulation]:{quote}TSG-18800, OMPUB-1125: Supports user-specified packet number limit for sending logs{quote}
---
**gitlab** commented on *2024-02-05T19:07:56.344+0800*:
[刘学利|https://git.mesalab.cn/liuxueli] mentioned this issue in [a commit|https://git.mesalab.cn/tango/firewall/-/commit/ce64026bca82435d3f594ebe84e03378d6ab8222] of [TSG Appliance / firewall|https://git.mesalab.cn/tango/firewall] on branch [feature-tunnel-rename-encapsulation|https://git.mesalab.cn/tango/firewall/-/tree/feature-tunnel-rename-encapsulation]:{quote}TSG-18800, OMPUB-1125: session is not identified app, and unknown is filled by default.{quote}
---
attachment link
2025-09-14 22:26:17 +00:00
# Attachments
first
2025-09-14 21:52:36 +00:00
attachment link
2025-09-14 22:26:17 +00:00
Attachment: image-2024-01-24-16-56-32-263.png
![image-2024-01-24-16-56-32-263.png](https://gfwleak.exec.li/admin/geedge-jira/raw/branch/master/attachment/50981/image-2024-01-24-16-56-32-263.png)
first
2025-09-14 21:52:36 +00:00
attachment link
2025-09-14 22:26:17 +00:00
Attachment: image-2024-01-24-20-31-19-292.png
![image-2024-01-24-20-31-19-292.png](https://gfwleak.exec.li/admin/geedge-jira/raw/branch/master/attachment/51016/image-2024-01-24-20-31-19-292.png)
first
2025-09-14 21:52:36 +00:00
attachment link
2025-09-14 22:26:17 +00:00
Attachment: image-2024-01-24-20-32-30-278.png
![image-2024-01-24-20-32-30-278.png](https://gfwleak.exec.li/admin/geedge-jira/raw/branch/master/attachment/51017/image-2024-01-24-20-32-30-278.png)
first
2025-09-14 21:52:36 +00:00
attachment link
2025-09-14 22:26:17 +00:00
Attachment: image-2024-01-24-20-38-42-125.png
![image-2024-01-24-20-38-42-125.png](https://gfwleak.exec.li/admin/geedge-jira/raw/branch/master/attachment/51018/image-2024-01-24-20-38-42-125.png)
first
2025-09-14 21:52:36 +00:00
attachment link
2025-09-14 22:26:17 +00:00
Attachment: image-2024-01-24-20-41-06-328.png
![image-2024-01-24-20-41-06-328.png](https://gfwleak.exec.li/admin/geedge-jira/raw/branch/master/attachment/51019/image-2024-01-24-20-41-06-328.png)
first
2025-09-14 21:52:36 +00:00
attachment link
2025-09-14 22:26:17 +00:00
Attachment: image-2024-01-25-09-27-24-206.png
![image-2024-01-25-09-27-24-206.png](https://gfwleak.exec.li/admin/geedge-jira/raw/branch/master/attachment/51021/image-2024-01-25-09-27-24-206.png)
first
2025-09-14 21:52:36 +00:00
attachment link
2025-09-14 22:26:17 +00:00
Attachment: image-2024-01-25-09-27-46-507.png
![image-2024-01-25-09-27-46-507.png](https://gfwleak.exec.li/admin/geedge-jira/raw/branch/master/attachment/51022/image-2024-01-25-09-27-46-507.png)
first
2025-09-14 21:52:36 +00:00
attachment link
2025-09-14 22:26:17 +00:00
Attachment: image-2024-01-25-09-29-21-037.png
![image-2024-01-25-09-29-21-037.png](https://gfwleak.exec.li/admin/geedge-jira/raw/branch/master/attachment/51023/image-2024-01-25-09-29-21-037.png)
first
2025-09-14 21:52:36 +00:00
attachment link
2025-09-14 22:26:17 +00:00
Attachment: image-2024-01-25-09-32-07-741.png
![image-2024-01-25-09-32-07-741.png](https://gfwleak.exec.li/admin/geedge-jira/raw/branch/master/attachment/51024/image-2024-01-25-09-32-07-741.png)
first
2025-09-14 21:52:36 +00:00
attachment link
2025-09-14 22:26:17 +00:00
Attachment: image-2024-01-25-09-33-40-660.png
![image-2024-01-25-09-33-40-660.png](https://gfwleak.exec.li/admin/geedge-jira/raw/branch/master/attachment/51025/image-2024-01-25-09-33-40-660.png)
Attachment: image-2024-01-25-09-54-21-743.png
![image-2024-01-25-09-54-21-743.png](https://gfwleak.exec.li/admin/geedge-jira/raw/branch/master/attachment/51029/image-2024-01-25-09-54-21-743.png)
Attachment: image-2024-01-25-10-06-49-337.png
![image-2024-01-25-10-06-49-337.png](https://gfwleak.exec.li/admin/geedge-jira/raw/branch/master/attachment/51033/image-2024-01-25-10-06-49-337.png)
Attachment: image-2024-01-25-10-07-17-442.png
![image-2024-01-25-10-07-17-442.png](https://gfwleak.exec.li/admin/geedge-jira/raw/branch/master/attachment/51035/image-2024-01-25-10-07-17-442.png)
Attachment: image-2024-01-25-10-07-37-292.png
![image-2024-01-25-10-07-37-292.png](https://gfwleak.exec.li/admin/geedge-jira/raw/branch/master/attachment/51034/image-2024-01-25-10-07-37-292.png)
Attachment: screenshot-1.png
![screenshot-1.png](https://gfwleak.exec.li/admin/geedge-jira/raw/branch/master/attachment/50985/screenshot-1.png)
first
2025-09-14 21:52:36 +00:00
Reference in New Issue Copy Permalink