2025-09-14 21:52:36 +00:00
|
|
|
|
# 【E21现场】tv.cctv.com无法正常访问
|
|
|
|
|
|
|
|
|
|
|
|
| ID | Creation Date | Assignee | Status |
|
|
|
|
|
|
|----|----------------|----------|--------|
|
|
|
|
|
|
| OMPUB-899 | 2023-04-13T14:56:59.000+0800 | 杨威 | 已关闭 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
|
|
|
|
埃塞tv.cctv.com突然无法正常访问，中电要求排查确认是否和我们系统有关。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-02-17 有部分用户向中电反馈该网站无法正常访问使用，询问是否和TSG系统有关。
|
|
|
|
|
|
|
|
|
|
|
|
当时中电也咨询了业主，业主回复未对该网站进行deny。
|
|
|
|
|
|
|
|
|
|
|
|
当天测试访问的情况是，部分终端首页就无法访问成功，要不首页刷新加载成功了但是点击首页视频视频加载失败。
|
|
|
|
|
|
|
|
|
|
|
|
pcap包是上次2023-02-17 反馈问题给洋姐时捕的数据包
|
|
|
|
|
|
|
|
|
|
|
|
[ https://tv.cctv.com/|https://tv.cctv.com/]目前存在以下情况：
|
|
|
|
|
|
|
|
|
|
|
|
[2023-04-13|https://tv.cctv.com/] 刚访问的结果，是首页访问加载刷新比较慢，首页加载成功后，点击视频然后视频加载10秒钟左右，可加载成功正常播放。
|
|
|
|
|
|
|
|
|
|
|
|
**chengsiyuan** commented on *2023-04-24T16:14:41.897+0800*:
|
|
|
|
|
|
|
|
|
|
|
|
2023-04-24 10:30:00 to 2023-04-24 10:56:59测试：
|
|
|
|
|
|
测试环境：电脑连接手机热点，电脑访问[https://tv.cctv.com/；|https://tv.cctv.com/]
|
|
|
|
|
|
测试结果：1、电脑无痕模式下访问[https://tv.cctv.com/]，首次无法访问，点击刷新后2分钟左右，访问成功，但是首页加载速度很慢，点击视频无法加载；
|
|
|
|
|
|
2、测试时间段的Security Events可以查到对应日志，Session Records未查到日志。
|
|
|
|
|
|
|
|
|
|
|
|
附件cctv.com.zip为：测试时间段的pcap包、对应的session record和security event log日志情况截图、以及security event log日志详情
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
|
|
|
|
**yangwei** commented on *2023-04-25T09:17:36.121+0800*:
|
|
|
|
|
|
|
|
|
|
|
|
* 使用wireshark条件tls.handshake.extensions_server_name == "tv.cctv.com"对pcap进行过滤，一共可以查询到6次包含“tv.cctv.com”的SSL Client Hello请求，其中前4次的ja3 hash，与Security Events中的一一对应
|
|
|
|
|
|
|
|
|
|
|
|
!image-2023-04-25-09-05-31-302.png|width=1046,height=539!
|
|
|
|
|
|
* 查看第一个在客户端捕获的SSL会话，第8个包发起的Client Hello出现了多次重传后，客户端主动发送rst断开，与NPB收到C2S单向流量，并命中策略执行deny->reset动作时，由于缺乏S2C侧信息，执行动作退化为Drop相符，最终客户端在多次重试后，主动结束会话。
|
|
|
|
|
|
|
|
|
|
|
|
!image-2023-04-25-09-07-32-104.png|width=1096,height=214!
|
|
|
|
|
|
* 最后两个SSL会话，使用服务端IP+SNI条件，在TSG界面查询，未查询到日志可能由以下原因导致：
|
|
|
|
|
|
** 对应处理的NPB（10.227.11.9）处理能力过载，bypass掉了对应的流量没有进行业务处理，可以通过查询NZ界面排除该原因
|
|
|
|
|
|
** 测试过程中，对应会话的流量没有完整分发给NPB，或者NPB出现丢包，导致不包含SNI为tv.cctv.com的请求（被Deny的会话，不会被包含在会话日志中），可以通过修改查询条件为ClientIP+ServerIP进行排除
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
|
|
|
|
**yangwei** commented on *2023-05-04T17:40:01.829+0800*:
|
|
|
|
|
|
|
|
|
|
|
|
4.25更新：
|
|
|
|
|
|
* 使用思源提供的NZ监控记录，未发现对应的NPB有bypass现象，排除上述可能性1
|
|
|
|
|
|
* 观察思源提供的测试时段，按服务端IP+客户端IP查询会话记录日志的结果，未见上图在客户端捕包中过滤出来包编号为133和139的两次SSL会话（ja3hash分别为0ff609d8da5f262fbf853192d219b638和4b147568c463e2c44acbacf41c59986f）
|
|
|
|
|
|
* !image-2023-05-04-17-37-09-358.png|width=866,height=454!
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
初步结论为，存在测试客户端部分流量没有经过TSG系统的现象，从而导致deny效果不佳
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
|
|
|
|
**yangwei** commented on *2023-05-06T09:25:25.262+0800*:
|
|
|
|
|
|
|
|
|
|
|
|
更新描述后，发现是用户是想确认为什么TSG系统没有下发相关阻断或干扰策略的前提下，[ https://tv.cctv.com/|https://tv.cctv.com/]访问效果不佳。
|
|
|
|
|
|
|
|
|
|
|
|
结合前述分析，更新描述如下：
|
|
|
|
|
|
* 2023-04-24 10:30:00 to 2023-04-24 10:56:59测试
|
|
|
|
|
|
** 客户端数据分析
|
|
|
|
|
|
*** 客户端共发起6次包含“tv.cctv.com”的SSL Client Hello请求，其中前4次访问失败，后2次访问成功
|
|
|
|
|
|
*** 分析失败的前4次访问可以发现，发起Client Hello后，出现了多次重传，最后客户端主动发送rst断开。该现象与被中间网络设备丢弃数据包类似。
|
|
|
|
|
|
** TSG系统日志数据分析
|
|
|
|
|
|
*** 在TSG系统查询客户端公网IP+前4次访问的服务端IP（95.101.22.161），可以找到对应ja3hash的会话日志，说明该会话经过TSG系统，且TSG系统并未做出相应的丢弃数据包行为
|
|
|
|
|
|
*** 分析TSG系统记录的前4个会话信息，发现为C2S侧单向流，且pkt_send数量为3，TSG系统仅能看到C2S侧的SYN，ACK，和首个Client Hello数据包，对于客户端后续的重传包未有记录，{*}推测执行丢弃的系统部署位置相对TSG系统，更靠近客户端侧{*}
|
|
|
|
|
|
*** 对于后2次访问成功的会话，未见到对应的TSG日志查询结果返回，请[~chengsiyuan] 补充查询对应测试时段测试客户端IP+服务端IP（95.101.22.177）的会话日志，以便进一步进行分析
|
|
|
|
|
|
**** 根据补充的会话日志信息，可以在TSG系统查询到后2次使用TLS1.3访问的日志，可知测试客户端的流量经过TSG系统
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
结论：
|
|
|
|
|
|
* tv.cctv.com的访问，存在被其他(除TSG之外的)网络审计系统{*}丢弃{*}的情况
|
|
|
|
|
|
* 根据TSG记录的会话日志，{*}推测该系统的部署位置，较TSG更靠近客户端{*}
|
|
|
|
|
|
* 客户端捕包结果显示，当tv.cctv.com的访问切换为TLS1.3后，访问成功，对应2023-04-13 测试时首先无法访问，一段时间后可以正常播放的现象，{*}推测该系统对TLS1.3的过滤能力不佳{*}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
|
|
|
|
**zhengchao** commented on *2023-05-15T10:34:20.222+0800*:
|
|
|
|
|
|
|
|
|
|
|
|
cctv.com被误识别为tiktok
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
|
|
|
|
**yangwei** commented on *2023-06-27T19:29:15.831+0800*:
|
|
|
|
|
|
|
|
|
|
|
|
原因同https://jira.geedge.net/browse/OMPUB-799，已向现场提供修改配置文件的临时解决方案，伺机实施
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-09-14 22:26:17 +00:00
|
|
|
|
# Attachments
|
2025-09-14 21:52:36 +00:00
|
|
|
|
|
2025-09-14 22:26:17 +00:00
|
|
|
|
Attachment: cctv.com.zip
|
|
|
|
|
|
[cctv.com.zip](https://gfwleak.exec.li/admin/geedge-jira/raw/branch/master/attachment/37627/cctv.com.zip)
|
2025-09-14 21:52:36 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-09-14 22:26:17 +00:00
|
|
|
|
Attachment: cctv.pcap
|
|
|
|
|
|
[cctv.pcap](https://gfwleak.exec.li/admin/geedge-jira/raw/branch/master/attachment/37242/cctv.pcap)
|
2025-09-14 21:52:36 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-09-14 22:26:17 +00:00
|
|
|
|
Attachment: image-2023-04-25-09-05-31-302.png
|
|
|
|
|
|
|
2025-09-14 21:52:36 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-09-14 22:26:17 +00:00
|
|
|
|
Attachment: image-2023-04-25-09-07-32-104.png
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Attachment: image-2023-05-04-17-37-09-358.png
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Attachment: 微信图片_20230413095232.png
|
|
|
|
|
|
|
2025-09-14 21:52:36 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
