147 lines
4.3 KiB
Markdown
147 lines
4.3 KiB
Markdown
# 福建项目：现场测试穿透问题
|
||
|
||
| ID | Creation Date | Assignee | Status |
|
||
|----|----------------|----------|--------|
|
||
| OMPUB-814 | 2023-02-22T11:58:10.000+0800 | 刘学利 | 已关闭 |
|
||
|
||
|
||
---
|
||
|
||
*客户端IP*：36.251.161.217（内网地址172.20.10.6）
|
||
*服务端IP*：36.255.221.179（内网地址10.10.10.180）
|
||
*测试网址*：http://36.255.221.179/
|
||
*sapp版本*：sapp-4.2.90.8c77537-1
|
||
|
||
测试客户端链接手机热点，服务端为自建测试服务器
|
||
测试策略为IP阻断策略
|
||
|
||
现象：服务端在syn-ack后收到rst包，未停止链接，继续向客户端回复数据
|
||
**zhangzhihan** commented on *2023-02-23T20:24:24.805+0800*:
|
||
|
||
测试网络：泉州联通5G（城域网出口）
|
||
客户端IP：36.251.161.255（内网地址172.20.10.6）
|
||
服务端IP：36.255.221.179（内网地址10.10.10.180）
|
||
|
||
第一次访问穿透，客户端未收到rst包，服务端在syn后收到rst包，单本次连接并未中断
|
||
!screenshot-1.png|thumbnail!
|
||
!screenshot-2.png|thumbnail!
|
||
[^client.pcap.pcapng] [^server_web.pcap]
|
||
|
||
|
||
|
||
---
|
||
|
||
**zhangzhihan** commented on *2023-02-24T14:00:21.281+0800*:
|
||
|
||
【测试网络】：泉州电信城域网
|
||
【客户端IP】：124.72.197.159（内网地址172.20.0.137）
|
||
【服务端IP】：36.255.221.179
|
||
【策略】：服务端IP阻断策略
|
||
|
||
【客户端捕包】： [^tsetweb_client.pcap]
|
||
【功能端tcpdump_mesa捕包（192.168.35.2）】： [^testweb_rx352.pcap]
|
||
【功能端管理口捕包（192.168.35.2）】： [^testweb_rst352.pcap]
|
||
【功能端tcpdump_mesa捕包（192.168.36.1）】： [^testweb_rx361.pcap]
|
||
【功能端管理口捕包（192.168.36.1）】： [^testweb_rst361.pcap]
|
||
|
||
【客户端第一次访问】：tcp.stream eq 7
|
||
【现象1】：客户端在syn后收到rst包，但仍然穿透，并且收到了一个ICMP不可达的报文，查看策略，并未打开”ICMP不可达“开关，并且本次也未命中其他策略。
|
||
【现象2】：sapp已打开封堵补救，auto remedy=1，目前现象是每次命中策略向一侧连续发2个rst包，并非每个数据包都会对应一个rst
|
||
!screenshot-3.png|thumbnail!
|
||
|
||
【客户端第二次访问】：tcp.stream eq 8
|
||
【现象】：rst到达客户端比syn晚了100ms，穿透
|
||
|
||
|
||
|
||
---
|
||
|
||
**zhangzhihan** commented on *2023-03-02T15:39:14.801+0800*:
|
||
|
||
福建穿透问题已解决，主要穿透原因有以下2点
|
||
|
||
*1、Rst到达客户端延迟问题*
|
||
造成该问题的原因，是因为mrglobal.conf中sz_buffer配置过大，不符合现在的流量大小导致。
|
||
原配置参数值为为32，在2021年建设完成-2022年上半年期间，系统的整体流量很大，sapp压力也很大，为缓解sapp和mrzpd丢包的问题，将该值设置为32，即mrzcpd每间隔32个包向sapp发送一次流量，当时流量的pps很高所以32个包很快就满了，并未对系统产生影响；
|
||
从2022年下半年后，用户逐步增加了汇聚分流上的drop策略，丢弃了更多不需要的流量。流量中的pps降低，增加了32个包的累积速率。
|
||
现场对某个机房的功能端服务器进行改造，使得该服务器可以直接访问互联网，并且保证culr出去的流量经分光-汇聚分流，最后还能回到本机，保证了测试环境无时间误差。通过对比 请求的syn包 和 sapp收到流量的syn包 发现，sapp在收到流量的时候已经有5-20ms的延迟，所以sapp发出去的rst就出现了延迟。
|
||
*将sz_buffer参数调整为0后，再次测试，两个syn包间隔在微秒级别，并且rst也无延迟现象。*
|
||
|
||
*2、运营商问题*
|
||
调研发现：
|
||
泉州联通在2022年下半年扩了链路，导致泉州联通的流量不完整；
|
||
福州移动的4G核心设置了网络隔离，未将rst转发到原始链路中；
|
||
|
||
*3、汇聚分流故障*
|
||
泉州电信汇聚分流端口故障，up状态无法接收流量，导致泉州电信流量不完整
|
||
|
||
|
||
|
||
|
||
---
|
||
|
||
|
||
|
||
## Attachments
|
||
|
||
**35469/client.pcap.pcapng**
|
||
|
||
---
|
||
|
||
**35472/client.pcap-1.pcapng**
|
||
|
||
---
|
||
|
||
**35474/client手机抓包.pcap**
|
||
|
||
---
|
||
|
||
**35467/screenshot-1.png**
|
||
|
||
---
|
||
|
||
**35468/screenshot-2.png**
|
||
|
||
---
|
||
|
||
**35499/screenshot-3.png**
|
||
|
||
---
|
||
|
||
**35470/server_web.pcap**
|
||
|
||
---
|
||
|
||
**35471/server_web-1.pcap**
|
||
|
||
---
|
||
|
||
**35496/testweb_rst352.pcap**
|
||
|
||
---
|
||
|
||
**35498/testweb_rst361.pcap**
|
||
|
||
---
|
||
|
||
**35495/testweb_rx352.pcap**
|
||
|
||
---
|
||
|
||
**35497/testweb_rx361.pcap**
|
||
|
||
---
|
||
|
||
**35494/tsetweb_client.pcap**
|
||
|
||
---
|
||
|
||
**35407/服务端捕包.pcap**
|
||
|
||
---
|
||
|
||
**35406/客户端捕包.pcap**
|
||
|
||
---
|
||
|