我有一个这样的系统设置 -
互联网 <--------------> (eno1) 公司 A (192.168.151.19)(eth1) <----------> (eth1) 公司 B (192.168.151.15)
eno1 和 eth1 桥接。计算机 B 通过计算机 A 访问互联网
考虑场景 1:
Comp A 上没有防火墙规则。这就像常规的端到端 TLS 连接
对 facebook.com 的 curl 请求需要以下流程 -
sudo SSLKEYLOGFILE=/home/test/FINALDEMO/keylog.txt ./sslkeylog.sh curl -S -k -v -w "@curl-format.txt" --tlsv1.2 https://facebook.com
time_namelookup: 0.022945
time_connect: 0.043648
time_appconnect: 0.117821
time_pretransfer: 0.117884
time_redirect: 0.000000
**time_starttransfer: 0.137791** (Imp)
size_download: 0
size_header: 312
----------
**time_total: 0.137868**
场景 2:
Comp A 上有一些防火墙规则
- 丢弃所有 TLS 应用程序数据包(允许 TLS 握手和更改密码规范)
- 当计算机 A 通过 rsync 从计算机 B 接收文件时,允许一对 IP 地址的应用数据包。处理该文件并通过 ipset 添加防火墙规则(从计算机 A 发送的文件包含要添加到防火墙的 ipaddress)
为了实现这两个步骤,我使用 Bash 脚本自动执行。通过rsync 为 0.29 秒平均而言,处理文件和添加防火墙规则所需的时间为0.03 秒
对 facebook.com 的 curl 请求需要以下流程 -
time_namelookup: 0.010086
time_connect: 0.024921
time_appconnect: 0.096774
time_pretransfer: 0.096860
time_redirect: 0.000000
**time_starttransfer: 1.851846** (Imp)
size_download: 0
size_header: 312
----------
**time_total: 1.851923**
我无法理解这两种场景之间的时间信息差异。在场景 2 中运行脚本和允许数据包连接所花的时间不相符。
有人可以建议更好的调试技术或了解为什么会发生这种情况吗?
编辑 1:在场景 2 中,TLS 应用程序数据包通过 u32 模块丢弃。我使用 u32 模块检查数据包的 TLS 标头,并据此丢弃数据包。
编辑 2:捕获 curl 请求的数据包https://yts.ag在这儿
https://drive.google.com/open?id=0Bz5corUPBatBdXhCZldxUWp6S2c