openvpn 链接问题分析
到新环境熟悉内部接口，postman 去调试内部服务接口发现接口没有返回，换个电脑调用正常。初步怀疑是自己电脑问题，遂打开 wireshark 根据目标主机 ip 结合路由信息判断的走的utun1接口出流量。
上图通过 wireshark 看到我获取 cube 接口GET请求发出去，多次尝试依然都是http的 response 的没有被用户进程收到，wireshark 报错tcp previos sgement not captured 。单独点开tcp segment可以在 wireshark 中看到 response 是回来了但是没有成功的被应用层接收到 (如下图)。
换个更直观的 tcp flow 的图（忽略里面的 ECN 协商的）：在 tcp 握手过完成过后，客户端发送请求，服务端返回数据，在17:48:34.242222时间片之前丢了一个 wireshark 说没有抓到（可能是丢了），也就是说在服务端响应过后可能丢了一个包，然后看到三次握手时候的 ack 重复出现。
之后是一堆的 keeplive ack 的报文，keeplive 超时时间到了过后服务端 reset 了 tcp connection。
通过 Google 发现网络上的文章都是说存在网络链路质量问题导致丢包。但是我的环境是使用的openvpn链接到开发环境，也就是说openvpn提供的链路可能有问题，遂尝试点开 vpn 客户端探索一下可配置项，发现openvpn版本是使用 v2.3.17 版本。
无脑尝试换到 2.4.3。
居然发现一切正常了。非常可能和openvpn的版本有关系。
猜想验证 1
搜索发现一个 wireshark 的issue,猜想会不会和 mac 的enc实现有关系？
尝试在 mac 通过sudo sysctl -w net.inet.tcp.ecn_initiate_out=0和sudo sysctl -w net.inet.tcp.ecn_negotiate_in=0关闭ecn，发现 wireshakre 显示的 tcp 的握手时符合预期，但是网络时依然不通的，初步排除了 mac os tcp ecn 的可能。(rst 是我 C-c 了 curl 发出的
猜想尝试 2
打开客户端的配置文件发现openvpn的配置模式是tun+udp,看上去是构建一个overlay的网络，猜测可能是服务端和客户端的ssl版本不兼容，在 overlay 网络数据解密的时候出现异常。如果是这样那么应该是所有走tun设备的 tcp 流量都有问题（和之前错误的 tcp 行为一致），结合之前同事让我ssh登录服务器也没有正常登录。
因为没有搜索到openvpn相关的兼容性的changelog，短时间无法验证暂时搁置。