当前位置:首页 » 《关注互联网》 » 正文

疑难杂症:同网段ping不通,跨网段建不了链,怎么破?_Python爱好者的专栏

3 人参与  2021年03月17日 16:43  分类 : 《关注互联网》  评论

点击全文阅读


 

笔者之前分享过两篇有关生产中疑难杂症的解决问题,效果出乎意料的好,其实工作这么多年,有关疑难杂症的素材真是遇到得很多,也值得好好总结一下,那么今天就继续和大家分享一下在日常工作中碰到的难解问题,当然具体的敏感信息我会略去,只是把问题的现象和经验总结一下,避免大家再踩坑。

近年来由于云计算的不断盛行,很多企业的数据中心都开始了大规模的扩容之旅,其中不少网络规划中都将用于部署备份、监控设备的网络区域,单独划分成一个大的子网,没有进行进一步的规划,在监控服务器随着生产业务服务节点一并扩容时,实际中发现两个问题,

  1. 是在子网内部无法互相ping通
  2. 跨子网可以Ping通,但是却无法建立连接。

这两个现象其实对应了两个问题,如果单拿出来一个问题都很很快解决,但是两个简单问题混杂在一起,解决起来还真是费了一番周折。具体问题情况如下图:

同子网缘何ping不通?

首先我们最开始先尝试将两个问题合并,认为是由同一个原因引起的,这里我们做了很多尝试,后来发现一个关键的信息,

一、arpping的提示

即使用arpping命令互ping,可以让同一子网内的两台节点恢复连通性。即先在两台机器上执行

1.ping 对端ip,结果不通:

2.arpping 对端ip

3.ping 对端ip:结果恢复通讯

二、系统日志输出为何无异常

即我们基本定位到这是由于arp表的原因造成的,我们知道同子网内的节点互访是不过网关的,因此arpping刷新本机arp表即可恢复连通性的情况,让我们基本排除了网络设备的问题,而把目光集中到了节点自身的arp配置。

但是奇怪的是如果真是arp配置错误造成网络不通,那么系统的syslog为何没有反应呢?我首先排除这个日志的问题,经排查发现,Linux对于内核日志的打印是有限制的,具体如下:

1. /proc/sys/kernel/printk_ratelimit 限制的时间间隔,默认值是5

2. /proc/sys/kernel/printk_ratelimit_burst 时间间隔内的最大打印条数,默认值是10

也就是默认的打印速率是每5秒最多打印10条。

因此基本确定报错日志受到限制而未输出。

三、Linux默认arp表的大小才是主因

排查到这步已经相对比较明确了,就是同子网内相关服务器的配置问题,经进一步确认Linux默认arp表大小为1024,而一般将所有备份、监控的网络区域全部划归为一个子网的做法,导致只有1024大小的arp表溢出,而且发生问题的监控、备份服务器中还安装了很多安全类的软件,都通过printk输出syslog,Linux内核日志打印限制速度的情况下,arp表满的问题并没有通过系统syslog报出来。

四:整改措施

1.调整内核参数

vi /etc/sysctl.conf

修改以下配置进行修改:

net.ipv4.neigh.default.gc_thresh1 = 512

net.ipv4.neigh.default.gc_thresh2 = 2048

net.ipv4.neigh.default.gc_thresh3 = 10240

2、更新配置

sysctl -p

当然我们确定了arp表的问题是造成同子网内部机器不通的原因后,其实也就基本确定了跨网段还是无法telnet建链的问题另有原因。因为跨网是要通过网关的。

跨网为何无法telnet?

在解决了同网段的问题之后,跨网无法telnet的问题还是存在问题,其实从结果上看这是一个比较典型的低级错误,简要分享一下相关排查过程。

  • 跨网ping可通,但新部署的节点无法建立到对应端口的连接,老部署长链接未断,但是无法实际传送数据

1.ping 跨网的对端ip,结果通:

2.新监控节点:telnet 对端ip 监控响应端口 不通

3.老监控节点:netstat -an|grep 监控响应端口,状态为ESTABLISHING,但此链路无流量

二、检查监控节点service列表发现iptables被启动

1.执行chkconfig --list

2.发现iptables服务的状态为running

3.停止iptables发现过一段时间还会被自动拉起

三、确认是安全软件策略的配置问题

由于我们的规范中iptables是默认不开启的,最终确认是由于安全软件误将备份、监控子网纳入iptables的启动清单中所导致。而iptables的白名单配置为空,这也导致了他们到生产节点的监控端口不通,其实这与跨不跨网没有关系。

四、iptables本质是基于hook机制的内核模块

什么hook可以参考笔者前文《疑难杂症:Linux下杀毒软件CPU占用率为何持续升高》,iptables本身其实也是一个基于netfilter的hook软件,不过他不会对于已经建立好链接强行断链,只是会将相应流量阻止,因此对于老服务来说他的长链接早在iptables启动之前就已经建立了,因此这个链接虽然不在iptables的白名单还可以存续一段时间,但无法发包,而新服务器干脆链接都建立不了。


点击全文阅读


本文链接:http://m.zhangshiyu.com/post/16327.html

子网  节点  监控  
<< 上一篇 下一篇 >>

  • 评论(0)
  • 赞助本站

◎欢迎参与讨论,请在这里发表您的看法、交流您的观点。

关于我们 | 我要投稿 | 免责申明

Copyright © 2020-2022 ZhangShiYu.com Rights Reserved.豫ICP备2022013469号-1