NAT环境无法访问云端的深层次分析

2022-02-28 22:33:25

这是一次我维护runningdoctor时候遇到的问题
现象：
1.用户无法打开web.runningdoctor.cn
2.监控状态无异常、无报警
3.tracert结果无异常、丢包率正常
4.用户无法访问的时候，我们能打开网站
5.多地代理访问网站，结果正常
6.有打开网站特别慢的时候，延迟30S

猜测问题

NAT环境无法访问云端的深层次分析

复现问题

NAT环境无法访问云端的深层次分析
偶然的一次 刷到了页面不存在
于是赶紧tracert一下 看看网络连通性
(但是不科学 因为这次请求被拒绝 我tracert并不及时 也许这个时候的tracert结果是能请求到页面时的 所以最后知道结果反推这次尝试应该说是一次失败的尝试)

试着解决问题

![image](https://yqfile.alicdn.com/d0c7

951b00e4c290c043ed9dbb1da4f72d98d93d.png)
做出这种尝试但是还是没有确定问题到底出现在C端还是S端 ，所以只能每种都去试试，推测一下，改了再观察。

Try
plus:

  1. Netstat 看到很多Time_wait
  2. 查看TIME_wait的解决思路
  3. 修改内核参数，重启应用程序

当时的内核一些网络配置参数：
net.ipv4.tcp_syncookies = 1(半开连接攻击？？？？)
打开TCP SYN cookie选项，有助于保护服务器免受SyncFlood攻击。
net.ipv4.tcp_tw_reuse = 1（socket重用）
怀疑是不是socket占用太多导致建立不起tcp链接
net.ipv4.tcp_tw_recycle = 0（罪魁两巨头之一 default=1）
打开socket的快速回收机制
net.ipv4.tcp_fin_timeout = 20
net.ipv4.tcp_keepalive_time = 1200
net.ipv4.tcp_max_syn_backlog = 8192
net.ipv4.tcp_max_tw_buckets = 180000
net.ipv4.icmp_echo_ignore_all=0
（这里无非就是打开一些上限 其实并没有达到上限）
net.ipv4.tcp_timestamps = 0 （罪魁祸首）
校验数据包头的时间戳 乱序的包将会被丢弃 满足递增的条件才保留

后来我被派到了医院里去 于是我打算通过一个小程序去监测我们web的80和443端口，看看他们这边有没有发生请求我们服务器的情况 并且返回时间戳(最后通过这个时间戳去搜索tcpdump出来的日志 去定位这次请求到底是在医院内被拒绝的还是请求走到公网到了我们的服务器被拒绝的)

NAT环境无法访问云端的深层次分析

NAT环境无法访问云端的深层次分析

NAT环境无法访问云端的深层次分析

最后通过程序返回的时间戳去tcpdump搜索附近的连接情况 终于找到了原因。就是被服务器拒绝了！
于是我又去谷歌搜为什么会被服务器拒绝 于是看到了这样一些结论，以及别人遇到的类似问题：

come to conclusion ：
what makes our website server can be succed to ping and tracert but can not open it on broswer?

近来线上陆续出现了一些connect失败的问题，经过分析试验，最终确认和proc参数tcp_tw_recycle/tcp_timestamps相关；

  1. 现象
    第一个现象：模块A通过NAT网关访问服务S成功，而模块B通过NAT网关访问服务S经常性出现connect失败，抓包发现：服务S端已经收到了syn包，但没有回复synack；另外，模块A关闭了tcp timestamp，而模块B开启了tcp timestamp；

第二个现象：不同主机上的模块C（开启timestamp），通过NAT网关（1个出口ip）访问同一服务S，主机C1 connect成功，而主机C2 connect失败；

分析
根据现象上述问题明显和tcp timestmap有关；查看linux 2.6.32内核源码，发现tcp_tw_recycle/tcp_timestamps都开启的条件下，60s内同一源ip主机的socket connect请求中的timestamp必须是递增的。
源码函数：tcp_v4_conn_request(),该函数是tcp层三次握手syn包的处理函数（服务端）；
源码片段：
if (tmp_opt.saw_tstamp &&
tcp_death_row.sysctl_tw_recycle &&
(dst = inet_csk_route_req(sk, req)) != NULL &&
(peer = rt_get_peer((struct rtable *)dst)) != NULL &&
peer->v4daddr == saddr) {
if (get_seconds() < peer->tcp_ts_stamp + TCP_PAWS_MSL &&
(s32)(peer->tcp_ts - req->ts_recent) >
TCP_PAWS_WINDOW) {
NET_INC_STATS_BH(sock_net(sk), LINUX_MIB_PAWSPASSIVEREJECTED);
goto drop_and_release;
}
}
tmp_opt.saw_tstamp：该socket支持tcp_timestamp
sysctl_tw_recycle：本机系统开启tcp_tw_recycle选项
TCP_PAWS_MSL：60s，该条件判断表示该源ip的上次tcp通讯发生在60s内
TCP_PAWS_WINDOW：1，该条件判断表示该源ip的上次tcp通讯的timestamp 大于 本次tcp

分析：主机client1和client2通过NAT网关（1个ip地址）访问serverN，由于timestamp时间为系统启动到当前的时间，因此，client1和client2的timestamp不相同；根据上述syn包处理源码，在tcp_tw_recycle和tcp_timestamps同时开启的条件下，timestamp大的主机访问serverN成功，而timestmap小的主机访问失败；

参数：/proc/sys/net/ipv4/tcp_timestamps - 控制timestamp选项开启/关闭
/proc/sys/net/ipv4/tcp_tw_recycle - 减少timewait socket释放的超时时间

解决方法
echo 0 > /proc/sys/net/ipv4/tcp_tw_recycle;
tcp_tw_recycle默认是关闭的，有不少服务器，为了提高性能，开启了该选项；
为了解决上述问题，个人建议关闭tcp_tw_recycle选项，而不是timestamp；因为 在tcp timestamp关闭的条件下，开启tcp_tw_recycle是不起作用的；而tcp timestamp可以独立开启并起作用。
源码函数： tcp_time_wait()
源码片段：
if (tcp_death_row.sysctl_tw_recycle && tp->rx_opt.ts_recent_stamp)
recycle_ok = icsk->icsk_af_ops->remember_stamp(sk);

if (timeo < rto)
    timeo = rto;

if (recycle_ok) {
    tw->tw_timeout = rto;
} else {
    tw->tw_timeout = TCP_TIMEWAIT_LEN;
    if (state == TCP_TIME_WAIT)
        timeo = TCP_TIMEWAIT_LEN;
}

inet_twsk_schedule(tw, &tcp_death_row, timeo,
           TCP_TIMEWAIT_LEN);

linux 服务器 无法建立TCP连接 时间戳 net.ipv4.tcp_timestamps

一.情况表现为
1.在公司内网对站点的http访问：
linux主机出现故障：curl以及抓包分析，发现服务端不响应linux客户端的请求，无法建立TCP连接，浏览器返回“无法连接到服务器”
windows主机正常
2.http访问质量下降：
基调显示，新架构上线后，访问质量下滑，主要表现为
2.1.访问提示“无法连接到服务器”
2.2.仅少数人遇到这种故障，并且一天中不是每次访问都会遇到，而是出现时好时坏的现象

二.处理过程
直接上google搜索关键字“服务器无法建立TCP连接”。
翻了几页后，发现这篇博文：“http://www.sunchis.com/html/os/linux/2012/0518/413.html”。
看了一下，和我们公司内网的表现一模一样，但各种问题（1为这方面基础知识薄弱，2为没有时间验证此配置）
然后这种问题持续了n久…一直以为是内部设备问题
后期搞不定了，大胆在线上启用这个参数“net.ipv4.tcp_timestamps = 0”，做了下测试后，发现故障解除，原故障机每次访问都正常了！
不过还是不明其中原理，只是大意了解，同样处于NAT上网方式的用户里（与别人共用出口IP地址），如果你的时间戳小于别人的，那么服务器不会响应你的TCP请求，要忽略此项，将net.ipv4.tcp_timestamps = 0（/etc/sysctl.conf）

三.总结
后期学习时，看见了一个更加详细的博客，讲的很详细，也引入了新的问题：http://huoding.com/2012/01/19/142

其实，linux服务器原本对时间戳（timestamps）默认是不开启的，Linux是否启用这种行为取决于tcp_timestamps和tcp_tw_recycle，因为tcp_timestamps缺省就是开启的，所以当tcp_tw_recycle被开启后，实际上这种行为就被激活了。
net.ipv4.tcp_tw_recycle又是啥呢，搜索了一下基本上是TIME_WAIT连接的回收参数

当 net.ipv4.tcp_timestamps 没有设置（缺省为开启），并且 net.ipv4.tcp_tw_recycle 也开启时，这个坑爹的错误就出现了，但是注意，只表现在NAT网络环境中。而且，大多数博客，以及一些大牛们，都有说过要开启 net.ipv4.tcp_tw_recycle …

启示录

1.三种网络模式
The network in hospital (our clients)
NAT环境无法访问云端的深层次分析

Nat mode ,ipaddr exchange

NAT环境无法访问云端的深层次分析

这是事故的出现就是因为医院内部是一个巨大的局域网(每个使用我们SaaS的医院都是数千人员工的医院)，他们访问外网是通过nat来实现的。也就是所有请求都要从外端路由到达公网，所以最终会被服务器认为是一个用户在请求。一旦某个包头时间戳乱序，就会造成其他的请求被拒绝。而其他一些针对个人用户的Saas不会出现这种情况的原因就是因为用户分散在各个场景，各个网络中，并不由一个路由把包从公网传到服务器上。

另外两种网络模式简述一下怎么用的吧：
HOST 可以用一张图来理解：
NAT环境无法访问云端的深层次分析
NAT环境无法访问云端的深层次分析

这种模式我觉得就相当于你的每台主机与路由都是平行地址，外部能ping到你的路由就能ping你的主机，这种做法在云端的话非常占有ip地址资源，所以一般是内部环境才能用用。一般你拉一条专线只会给你几个公网地址，如果你都用brige的话服务器又多，不可能每个都配一个公网地址的。所以这种网络模式我一般就是在虚拟机上做做实验的时候会使用到，当然服务器内部比如docker之类的也用docker0与eth0桥接 从而达到一个share的作用 你才能再真机上ping172的那些网络地址。

2.三次握手协议
解决这次问题也帮我回顾了一下三次握手协议。作为一个运维，我觉得有一大块的工作重心就在“”what happend when you input a url in your broswer?“ 排除故障要是这个思路，请求到没有到服务器？服务器给你的状态码是什么？通过状态码判断是资源不存在还是程序错误？资源不存在的话是路由的问题还是权限的问题，是路由的问题的话是开发与你沟通的nginx转发配置的问题还是程序内部路由的问题；是代码的问题的话你就要去判断是启动报错还是什么情况？当然有了这种思路你就要通过去排查日志或者网络抓包去定位问题，从而解决问题。
当然，我们这次故障就是出现在握手协议上，所以这里
也顺便温习一下握手协议

NAT环境无法访问云端的深层次分析

男：妹子我喜欢你
女：我知道你喜欢我了，帅哥我也喜欢你
男：你知道我喜欢你了啊！你喜欢我我也喜欢你啊！
于是俩人就。。。。。。。。。。了
。。。。。。。。。。之后
男：睡觉吧
女：哦
女：那我也睡了
男: 好

前文能够定位到问题就是握手没建立起来 一直是妹子我喜欢你 喜欢你 喜欢你 。。。其实妹子是个聋子，根本不晓得你说的什么，也就没了后文………

专业一点：TCP状态迁移：CLOSED->SYN_SENT->ESTABLISHED->FIN_WAIT_1->FIN_WAIT_2->TIME_WAIT->CLOSED服务服务器TCP状态迁移：CLOSED->LISTEN->SYN收到->ESTABLISHED->CLOSE_WAIT->LAST_ACK->CLOSED

不管是程序员还是运维都要关注这个问题，比如你http不设置超时，那么服务器就会有大量的连接被占用，linux万物皆文件，高并发情况下资源损耗就会比较大，每个连接都是要占用句柄的。调优的话就是要依据这些来做，是启用长连接还是短连接？keepalive时间设置多少，请求频率做不做限制，内核如何调优？http返回什么状态码才友善等等，这都是要关注的细节问题。

3.经验都是惨痛的代价走出来的

以前从来没有遇到过这种场景，这次故障基于业务线的url监控，系统层级的监控全部没有发现医院出现的访问故障。这个问题也一直持续了很长一段时间，如果这是一个高频，高价值的生产线出现这种故障必定是致命的。未来的路还长，要学的东西还有很多很多……….

以下是我的csdn的地址：
https://blog.csdn.net/qq_15800363/article/details/78424101
版权声明：本文为博主原创文章，转载请附上博文链接！

上一篇：阿里云服务器ECS该如何开放Linux端口(安全组端口)？


下一篇：Kubernetes in action (deployed)