PRE.前置知识

1.何为 反向代理(Reverse Proxy) 呢?

反向代理是对应正向代理来说的,那什么是正向代理呢? (正向代理是对应反向代理来说的,那什么是正向...🐶)

a.正向&反向的理解

通俗来讲,所谓的正向与反向是相对于代理服务架设的位置来说的.

先看看无代理的样子👇

i.无代理

可见链路中没有什么东西,干净得很.

ii.正向代理

代理服务架设在客户端侧,通过一个代理服务,即可控制通向多个服务的流量,代理服务与服务端的关系为一对多

iii.反向代理

代理服务架设在服务端侧,客户端通常是无感的,代理服务与服务端的关系通常为一对一

b.正向&反向的对比

代理方式	架设端	配置端	代理内容	数量关系(通常)
正向代理	客户端	客户端(服务端无感)	客户端发出的请求	一个代理服务对接多个服务端
反向代理	服务端	服务端(客户端无感)	到达服务端的请求	一个代理服务对接一个服务端

思考:客户端发出的请求 =? 到达服务端的请求

c.不管正向还是反向,能抓到包的都是好代理

通过上边的解释,大家可以发现,不管正向、反向,都是在链路中加入一个代理服务,他们的部署也不一定是在上图所示的网络环境内.在实践中,我们更多要考虑的,是如何把代理服务插入到请求链路里边!

2.何为 抓包 呢?

通俗认为,抓包就是抓取数据包,一个请求的发送和响应的接收,可以理解为在传输时会把它们拆分成一个一个数据包再进行发送和接收,而抓包就是希望能 看到、组合、解析、甚至修改 这些小包包.常见的抓包工具有 Fiddler、Charles、Wireshark及今天要使用的mitmproxy等.

这里需要提一下Wireshark这类是偏观测型的抓包工具,它们不需要起一个代理服务,也不需要修改客户端、服务端的配置,只需要能Accept进入网卡,就能 看到、组合、解析 数据,能让人们以肉眼看到解析后的数据,如明文的http协议,但是缺点也比较明显,一是功能略显单薄,不支持回放、修改等,二是一些加密类型的协议如https用起来就比较麻烦.

一、我们的业务场景

1.设备及协议

• 设备:Android整机
• 协议:https
• 域名:多套域名,每套域名下有部署所有服务

2.测试大佬们的抓包需求

• 确认问题归属:通过参数/返回值等,判断是安卓端大佬的问题,还是后端小弟的问题
• 提供问题数据:对开发解bug来说,提供接口出入参简直不要太重要
• 保留证据/协助复现:对一些偶现、不容易触发的问题,也需要用到抓包的数据
• 数据篡改:模拟一些特殊数据来验证问题和逻辑

3.多域名并行送测

目前我们每个需求送测都会使用一个特殊的域名,并且域名下会部署完整的所有服务,而测试也常常需要进行域名切换,host切换等!

二、抓包现状

1.链路图示

用的Fiddler,看起来貌似很简单,实则不是,抓过Https的小伙伴都知道,解析Https是需要证书的,而Android的证书是个难搞的东西!

2.实施流程

• 刷入对应送测固件的 debug 版本
• 给设备root
• 推送证书
• 连接wifi并设置代理
• 打开Fiddler开始抓包

看着好像还可以? 看看我们遇到了什么问题!

3.遇到问题

• 业务需求导致经常需要刷机
• 正式版系统搞不了,只能搞搞 debug 版
• 推证书流程很麻烦,并且需要多次重启
• 有些CDN请求(非业务域名)走代理很慢,甚至会失败
• 有些应用的请求是不走wifi中配置的代理的
• 每次域名切换需要重启设备
• Fiddler使用的脚本语言比较特殊,写起来很痛苦

综上,当前的抓包方式还有提升的空间.

三、新玩法

1.配置支持

我们做的是整机,系统也是自己的,并且我们已经有了两项重要的支持

• 域名配置: 除了变更域名外,也支持变更协议,如https变成http
• Host配置: 同SwitchHost的功能一样 这些在系统层级做了支持,不需要root.

2.思路:

a.仅观测行不行? 不行

服务端不支持http协议,用Wireshark直接看不到,所以必须要介入请求的网络链路中.

b.如何介入到网络链路呢? 配Host

如果用老办法,配置wifi中的代理,也能介入,但是这样部分旧问题还是会存在,所以我们选择用Host来介入,这种方式通常会比wifi代理更彻底,生效范围更广.

介入方式	生效范围	协议覆盖
wifi代理	需要看应用有没有使用	http、https...
host配置	一般都会使用	所有(不可自定义,可能会误杀)

使用host来控制流量:

c.证书能不能省? 能

这时候就要用到域名切换功能了,我们可以把协议切换成http的,但是服务端不是不支持http协议嘛?是的,但是反向代理可以解决这个问题;

以mitmproxy为例,它能做到: mitmweb --mode reverse:https://a.seewo.com:443@80

• 承接因host配置而过来的流量(这种方式跟wifi配置方式过来的流量是不一样的)
• 变更协议:从http变成https

如图,跟服务端的通信用的还是https,但是android用的则是http

d.二次切换域名能否不重启了? 能

首先第一次的域名切换和host配置是省不了的,而且也需要重启,但是后续的域名切换都在pc端完成,所以不再需要重启.

3.新的流程

• 配置host、域名
• 启动mitmproxy开始抓包

4.局限性

• 代理服务对接的服务端只能用一个域名
• 需要设备支持切换成http协议
• 需要设备支持host配置

四、其它

1.安全性

如果屏幕前的你想要参考这套流程,那么:

• 首先配置的入口、权限一定要保护好,因为如果开放给普通用户,那么他们也可以用同样的流程进行抓包,这往往是不安全的
• 其次也可以对接口进行验签保护,可以防止普通用户进行篡改、回放等

2.退而求其次

如果你的设备不支持域名切换,默认使用的也是https协议,那么你就必须要装证书了,但是host配置应该可以用自定义的DNS服务来实现类似的效果,这样也能做到抓包,但似乎没有那么便捷!

3.扩展

如果这个代理服务部署的是公网,那么技术上是可以看到真实用户的请求的,这样在排查一些疑难杂症也许会有帮助,但需要做到这种地步的排查目前还没有遇到过.

4.总结

总的来说,这种方式使用的场景很苛刻,但是又能恰好能适配上业务场景和现有的功能,正所谓 糯米治木虱,一物治一物

感谢您的阅读,如有不当,欢迎指出!