2025-09-14 21:52:36 +00:00
|
|
|
|
# 【P19现场】现场发现URL封堵有穿透现象
|
|
|
|
|
|
|
|
|
|
|
|
| ID | Creation Date | Assignee | Status |
|
|
|
|
|
|
|----|----------------|----------|--------|
|
|
|
|
|
|
| OMPUB-972 | 2023-07-24T23:04:47.000+0800 | 杨威 | 已解决 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
|
|
|
|
在现场发现url封堵有穿透现象，通过wireshark抓包发现：
|
|
|
|
|
|
1.chrome 发起http请求时，同时创建2个会话。
|
|
|
|
|
|
2.封堵对第一个会话有效，对第二个会话失效。
|
|
|
|
|
|
3.第二个会话在三次握手后会很长一段时间没有数据传输（45s以上），此时第一个会话被阻断，第二个会话直接从url请求开始，此时出现穿透
|
|
|
|
|
|
|
|
|
|
|
|
图片中tcp.stream eq 22 为第二个会话, tcp.stream eq 21为第一个会话
|
|
|
|
|
|
https://stackoverflow.com/questions/47336535/why-does-chrome-open-a-connection-but-not-send-anything
|
|
|
|
|
|
**yangwei** commented on *2023-07-31T00:55:02.575+0800*:
|
|
|
|
|
|
|
|
|
|
|
|
问题原因为功能端新增opening timeout参数，默认10s，测试时的会话从syn到第一个data包间隔45s，在opening状态触发超时，导致无法正确阻断
|
|
|
|
|
|
|
|
|
|
|
|
自[TSG-16300] OS支持配置TCP的opening timeout和closing timeout参数 - Geedge Networks Jira后提供opening参数，且功能端同步将opening timeout参数提升至60s
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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: chuantou_1.pcap
|
2025-09-14 22:27:11 +00:00
|
|
|
|
|
2025-09-14 22:26:17 +00:00
|
|
|
|
[chuantou_1.pcap](https://gfwleak.exec.li/admin/geedge-jira/raw/branch/master/attachment/41767/chuantou_1.pcap)
|
2025-09-14 21:52:36 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-09-14 22:26:17 +00:00
|
|
|
|
Attachment: screenshot-1.png
|
2025-09-14 22:27:11 +00:00
|
|
|
|
|
2025-09-14 22:26:17 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-09-14 21:52:36 +00:00
|
|
|
|
|
