admin/geedge-jira
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
6a8bfef5778fc7ddd06fa05776bf1ecd0f61d4c4
geedge-jira/md/OMPUB-824.md

259 lines
12 KiB
Markdown
Raw Normal View History

first
2025-09-14 21:52:36 +00:00
# 福建项目：功能端命中安全策略但未发rst
| ID | Creation Date | Assignee | Status |
|----|----------------|----------|--------|
| OMPUB-824 | 2023-02-28T14:53:49.000+0800 | 刘学利 | 已解决 |
---
测试网站：https://kf.xn--fiq01iq2nuta337et7ov3wo3y.com
命中策略ID：134
命中object item：*xn--fiq01iq2nuta337et7ov3wo3y.com
问题描述：功能端在tcpdump_meas捕包可以看到访问的流量，同时在管理口捕包没有对应的rst。界面可以看到相应的安全策略日志
说明：该网站有http和https，http命中135策略，正常发rst。https命中134策略，未捕获rst
!image-2023-02-28-14-57-36-655.png|thumbnail!
!image-2023-02-28-14-57-47-786.png|thumbnail! **zhangzhihan** commented on *2023-03-31T21:52:22.351+0800*:
2023.03.31在福州移动4G复测，当流量经过福州移动一厂机房时，穿透较为严重。测试访问自建http网站 http://36.255.221.179 ，策略为IP阻断策略，发现sapp会出现不发rst的情况，例如第一次访问，出现了阻断，但刷新后出现穿透，通过抓tsg-os的日志口包发现，穿透的时候sapp没有发rst，并且穿透的时候界面没有命中日志。
测试流量固定经过192.168.16.12服务器，尝试将16.12的sapp目录备份，并替换为另一台福州移动4G服务器的sapp目录（该服务器测试正常），替换后测试现象仍为sapp未发rst包
---
**liuxueli** commented on *2023-04-01T15:10:21.909+0800*:
* 访问36.255.221.179阿里云自建服务，策略条件为服务端IP(36.255.221.179)，tcp 端口重用导致阻断的效果不佳。
---
**liuxueli** commented on *2023-04-01T16:26:54.195+0800*:
* 测试同时在客户端、功能端、服务端捕包，本次测试客户端均未收到RST包。
** 客户端捕包：[^1-client-36.255.221.179.pcap]
** {^}服务端捕包：{^}[^1-server-36.255.221.179.pcap]
** {^}功能端捕包：{^}[^1-tsg-36.255.221.179.pcap]
* ^3个捕包点捕获的数据包中的连接数一致，共8个链接，使用clientPort、Server IP、clientISN条件在安全事件日志中均找到对应的事件日志。^
** client_port=58408 serverIP=36.255.221.179 clientISN=109015579
client_port=58410 serverIP=36.255.221.179 clientISN=904314205
client_port=58409 serverIP=36.255.221.179 clientISN=1353384079
client_port=58417 serverIP=36.255.221.179 clientISN=2535026249
client_port=58418 serverIP=36.255.221.179 clientISN=1380987268
client_port=58419 serverIP=36.255.221.179 clientISN=2847006069
client_port=58423 serverIP=36.255.221.179 clientISN=3068429057
client_port=58427 serverIP=36.255.221.179 clientISN=3217186535
---
**yangwei** commented on *2023-04-01T17:20:11.384+0800*:
现象
* 附件[^36.255.221.179.ct.port-reused.pcap]中的两个TCP会话（源端口分别为61843和61844），都出现了SYN重传（SYN retransmission）的现象，而非TCP端口复用（TCP port reuse）
* 端口复用的前提是前一个会话结束，并且使用相同的四元组重新协商初始化序列号ISN（Initiate Sequence Number），而pcap包中的会话并没有显式的结束，Client侧的行为是在500+ms的间隔内连续发送了两个ISN相同，但是IPID不同的SYN包，属于SYN重传
分析
* 对于sapp的处理逻辑，syn重传对于发送rst干扰TCP会话原则上并没有影响
* 只要根据第一个syn触发的rst及时到达Client和Server，而Client和Server正常响应，目标会话就会结束
* 在正确性假设成立的情况下，就算重传了第二个syn，sapp认为是重传，而没有补发干扰包，也不影响第一个rst的效果
验证
* 对附件https://jira.geedge.net/secure/attachment/36783/36.255.221.179.ct.port-reused.pcap使用sapp的单测进行读包验证，能够正常的触发RST包发送
PS：值得注意的是，pcap包中的Client IP为192.168.43.84，在京版服务器上进行读包测试时，可能会因为和京版地址段重合（192.168.40.0/21），导致在测试机的管理口上捕不到sapp发给S2C侧的rst包
---
**liuxueli** commented on *2023-04-01T17:34:55.276+0800*:
* 测试同时在客户端、功能端、服务端捕包，第二次测试存在三种现象：
** 客户端正常收到RST包，链接被正常阻断
** 客户端正常收到RST包，链接未被正常阻断
*** 客户端收到RST包后，链接上出现短时间范围内重传SYN包重传的现象
** 客户端未收到RST包，链接正常访问
*** 根据client_port=58860 serverIP=36.255.221.179 clientISN=962091815条件查询，安全事件日志中有记录，说明本链接命中了安全策略。
**** !client_port=58860 serverIP=36.255.221.179 clientISN=962091815.jpg|thumbnail!  
*** sysinfo.log中观察到功能端发送RST较多，可达到1.9万/秒
**** !image-2023-04-02-18-08-57-198.png!
** 参见：
*** 客户端捕包：[^2-client-35.255.221.179.pcap]
*** {^}功能端捕包：{^}[^2-tsg-36.255.221.179.pcap]
*** {^}服务端捕包：{^}[^2-server-36.255.221.179.pcap]
---
**yangwei** commented on *2023-04-02T13:43:18.362+0800*:
根据上述描述的现象和相关数据包，小结如下，有不准确之处，[~liuxueli] 和 [~zhangzhihan] 补充修正：
* *测试过程*
*
** 福建移动网的部分运营商（特定一家？），存在干扰效果不佳的情况（俗称穿透），{*}对应智涵在Description中描述的部分{*}
** 为验证该现象的普遍性，智涵在阿里云自建了一个网站，方便结合拨测客户端，进行自测
** 第一波测试结果显示对于自建网站，仍然存在穿透，{*}对应智涵的第一条评论，{*}在拨测客户端捕包[^36.255.221.179.ct.port-reused.pcap]
*** 为简化条件，将自测的安全策略设置为服务端IP，仍然效果不佳
*** 为了排除部署的原因，将其他没有穿透现象的功能端目录拷贝至该站点，仍然效果不佳
*** PS：上述两个方法基本可以排除穿透原因，是由于服务端的特殊性，或者部署参数不一致导致。
** 学利分析了捕获的数据包，得到“tcp 端口重用导致阻断的效果不佳”的结论，{*}对应学利的第一条评论{*}
** 学利也使用自测条件，进行了一轮复测，分别对客户端，服务端，和功能端接收到的镜像流量，进行了捕包并附在评论中，这一轮测试的结果是功能端“本次测试未发送RST包”，{*}对应学利的第二条评论{*}
** 经过与学利的交流，学利进行了他操作的第二轮复测，同样在相同的位置进行了捕包并附在评论中，这一轮测试加上了对安全事件日志的查询，得出的结果是“安全事件日志中有记录，说明本链接命中了安全策略”，{*}对应学利的第三条评论{*}{*}{{*}}
 
* *问题分析*
** 上述测试过程，暂时可以得出以下结论
*** 穿透发生的范围，限于部分运营商的移动站点，而非所有站点
*** 穿透的对象，与策略条件无关（SNI或者IP都穿），与服务端的特殊性也无关（自建网站可以复现）
** 穿透可能性分析 
***  镜像模式下，TSG穿透的现象按是否存在安全日志，和在客户端服务端是否收到RST包，可以分类为：
**** 有日志，有RST->效果不佳
***** 可以排除策略条件和功能端策略执行的问题
***** *原因可能为功能端包处理延迟大，或者干扰链路延迟*
**** 有日志，无RST->无干扰效果
***** 可以排除策略条件和功能端策略执行的问题
***** 原因可能为干扰包封装问题（如包含MPLS或者VLAN），通常在固网环境不存在，{*}移网环境后文进一步展开说明{*}
**** 无日志，无RST->无干扰效果
***** 日志不缺失的前提下，属于安全策略未命中，需要检查策略条件和功能端解析和执行策略的逻辑
**** 无日志，有RST->见鬼了
** 移网环境干扰包原理
*** 发送流程和观察点捕包方法见下图
*** 由于增加了PacketAdapter对干扰包进行修改的流程，加长了干扰包的处理路径
*** 目前图中①和②的数据包暂时没有提供观察手段，因此仅在观察点D捕包未发现RST，不能完全定位功能端的故障点
!移动网观察点-移动网观察点.drawio.png|width=721,height=593!
* 小结
** 根据前述现象和附的相关数据包，目前福建穿透现象的可能性如下
*** *现象1：有日志，有RST->效果不佳，对应智涵在description中的描述和附上的数据包*
**** *可能原因：功能端本身包处理延迟大，或者转发干扰包的链路存在较大转发延迟*
*** *现象2：有日志，无RST->无干扰效果，对应学利进行的两次拨测*
**** *可能原因：*
***** sapp发送干扰包问题（如封装包含MPLS或者VLAN），已通过对比镜像流量和sapp日志排除，未出现sapp相关发送报错的日志
***** PacketAdapter处丢包，观察自测流量经过的功能端，发送RST包的pps已经达到1.9w/s，不确定是否会对PacketAdapter产生性能影响，需要进行压力测试排除该原因
** 下一步将先对这些可能性进行排查和排除
---
**zhangzhihan** commented on *2023-04-02T16:33:26.138+0800*:
根据[~yangwei]描述的【现象2：有日志，无RST】的原因，查看Prometheus发现，测试功能端（16.12、13）发送rst峰值量已经达到了4.5w条/s
!screenshot-1.png|thumbnail!
观察Nezha上的Sapp_Send_RST蜂窝图发现，该局点（福州移动-一厂），不管是4G还是固网，RST的量都是其他局点的几倍
!screenshot-2.png|thumbnail!
---
**yangwei** commented on *2023-04-02T17:12:47.836+0800*:
帮忙确认一下：
* 本issue描述的现象，主要集中在福州移动一厂的4G站点？还是同样有其他运营商的4G站点？
* 福州移动一厂的固网站点（RST包量同样较高），是否也存在本issue描述的现象
建议确认下福州移动一厂RST包高的原因，是否由于部分安全策略命中率过高导致，或者是因为这个站点的流量显著高于其他站点
---
**zhangzhihan** commented on *2023-04-03T09:55:32.374+0800*:
[~yangwei]
1、本issue描述的现象，只要集中在福州移动一厂4G站点；
2、周日粗略测试福州移动一厂固网，发现也有未发rst的问题（可能，因为在客户端和服务端都没看到rst，但是运营商固网的分流不是很固定，有时候会飘到其他站点的功能端），一厂固网的功能端发送RST的量也很大，都在4w/s以上，甚至6-8w/s；
3、福州移动4G有两个站点：一厂、马尾。通过device_group对比一厂4G 和 马尾4G 1小时、24小时deny的日志量，两者日志量相当，但是一厂4G的RST量是马尾4G的量的好几倍
---
**yangwei** commented on *2023-04-03T10:36:53.948+0800*:
[~zhangzhihan] rst包pps 6-8w/s的情况下，运营商提供的干扰链路也不能保证不丢包，这个需要在功能端管理口（观察点D）和客户端（观察点A）or服务端（观察点B）对比，确认干扰链路转发无误
---
**zhangzhihan** commented on *2023-04-04T09:29:52.918+0800*:
[~yangwei] 福州移动一厂4G目前已关闭封堵补救，单台rst数量从平均1.5w/s下降到了1200/s，目前测试效果恢复正常。关闭封堵补救之前观察packetadapter的cpu占用，单核us占用35%，sys占用60%，cpu已经爆满。
---
## Attachments
**36784/1-client-36.255.221.179.pcap**
---
**36785/1-server-36.255.221.179.pcap**
---
**36786/1-tsg-36.255.221.179.pcap**
---
**36787/2-client-35.255.221.179.pcap**
---
**36788/2-server-36.255.221.179.pcap**
---
**36789/2-tsg-36.255.221.179.pcap**
---
**36783/36.255.221.179.ct.port-reused.pcap**
---
**36790/client_port=58860+serverIP=36.255.221.179+clientISN=962091815.jpg**
---
**35597/image-2023-02-28-14-57-36-655.png**
---
**35596/image-2023-02-28-14-57-47-786.png**
---
**36794/image-2023-04-02-18-08-57-198.png**
---
**36792/screenshot-1.png**
---
**36793/screenshot-2.png**
---
**36791/移动网观察点-移动网观察点.drawio.png**
---
Reference in New Issue Copy Permalink