问题描绘
项目中运用的服务器是物理机,运用 centos 7.6 版本的操作系统, 4 个千兆网口,上架时刻 23 年 8 月份。布置在内网机房,并且在内网机房分配的固定IP 是 172.87.7.249
,并在机器上布置了 docker,
大概在 10 月中旬左右,这台机器呈现拜访时好是坏的问题;前期呈现时一直以为是机房调整网络环境导致,时间短性的不行拜访没有实践影响业务,所以就没太重视。可是从 10 月底开端,机器开端频频性呈现不行拜访的问题,开端接入排查。
同机房同机柜还有其他 3 台服务器,ip 地址分别为 172.87.7.246,172.87.7.247,172.87.7.248
。在 172.87.7.249
呈现频频性不行拜访的一起,在工作网环境其他 3 台机器拜访均无影响,并在当在工作网经过 ssh 登录 172.87.7.249 提示 Connection refused
时,经过其他三台机器的任何一台 ssh 登录 172.87.7.249
,却能够登录。
总结下现象:
- 1、
172.87.7.246,172.87.7.247,172.87.7.248,172.87.7.249
同处一个机房,一个机柜,衔接的也是同一个中心交换机,同一个网关。 - 2、工作网环境拜访
172.87.7.249
,前期偶发性时好时坏,后期频频不行拜访,间歇性可拜访。 - 3、工作网环境拜访
172.87.7.248/247/246
,正常。 - 4、
172.87.7.248/247/246
拜访172.87.7.249
前期正常,后期时间短间歇性不行拜访,但大多数情况下是能够拜访的。 - 5、
172.87.7.249
能 ping 通
看到这儿,关于了解网络的大神应该能猜到个八九不离十的原因了,可是关于研制工程师来说,网络问题一直都是技术上的疼点。
下面就从研制视角来看下排查进程。
排查进程
防火墙装备
一般情况下,IP 能 ping 通,端口无法拜访,99% 的原因都是出在防火墙;
-
1、先经过
systemctl status firewalld
检查防火墙状况,能够看到防火墙正常敞开[root@localhost ~]# systemctl status firewalld ● firewalld.service - firewalld - dynamic firewall daemon Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled; vendor preset: enabled) Active: active (running) since 二 2023-11-21 00:29:44 CST; 3 days ago Docs: man:firewalld(1) Main PID: 63661 (firewalld) Tasks: 2 Memory: 26.0M CGroup: /system.slice/firewalld.service └─63661 /usr/bin/python2 -Es /usr/sbin/firewalld --nofork --nopid 11月 21 00:29:44 172-87-7-249.brainerd.net systemd[1]: Starting firewalld - dynamic firewall daemon... 11月 21 00:29:44 172-87-7-249.brainerd.net systemd[1]: Started firewalld - dynamic firewall daemon.
-
2、经过
firewall-cmd --list-ports
检查端口开发战略,22 端口正常的[root@localhost ~]# firewall-cmd --list-ports 22/tcp 80/tcp 9080/tcp
一般情况下,默许 zone 是 public;
-
3、这儿为了防止可能是 zone 战略问题,也看了下 zone 和出网网卡的对应
[root@localhost ~]# firewall-cmd --get-active-zones public interfaces: enp61s0f0 [root@localhost ~]# [root@localhost ~]# firewall-cmd --get-zone-of-interface=enp61s0f0 public [root@localhost ~]#
这儿也没问题,一起为了防止环境差异,对比了其他三台机器,装备战略都是一样的。
进程是否 OK
之前在运用 onlyoffic 时遇到的一个问题,在宿主机上经过 docker 发动 onlyoffic,发动完结之后经过 docker ps
检查镜像运转状况是正常的,经过 netstat 检查端口对应的进程也存在(宿主机的),可是也是端口无法拜访;其时问题是由于镜像容器内部的 nginx 进程没有被拉起导致的,便是宿主机的端口正常,可是映射到容器内部的端口对应的进程不存在。
为了防止重复踩坑,也涨了记忆查了下进程
[root@localhost ~]# ps -ef | grep sshd
root 93164 171028 0 14:02 ? 00:00:00 sshd: root@pts/0
root 96871 93211 0 14:18 pts/0 00:00:00 grep --color=auto sshd
root 171028 1 0 11月13 ? 00:00:00 /usr/sbin/sshd -D
sshd 进程也是正常的。实践上到这儿从研制视角的排查根本就到头了,可是这些都是正常的,问题依然存在。
是否和 docker 有关
在排查完防火墙和进程之后,把方针瞄向了 docker 容器了,这儿的依据是:
-
1、履行
systemctl status firewalld
时,有一条告警WARNING: COMMAND_FAILED: '/usr/sbin/iptables -w10 -D FORWARD -i docker0 -o d
-
2、履行
firewall-cmd --get-zones
时,提示block dmz docker drop external home internal nm-shared public trusted work
实践上这两个问题从排查来看,并不是前述问题的原因,可是这两个提示把咱们排查的方向带的有点偏。首先是第一个告警,这个问题是由于 dockerd 发动时,参数 –iptables 默许为 true,表明允许修正 iptables 路由表;其时排查时,我是直接将 docker stop 掉了,因此扫除了这个因素,如果需要修正docker iptables ,能够在 /etc/docker/daemon.json
这个文件修正。
关于第二个,这儿略微介绍下;firewalled 有两个根底概念,分别是 zone 和 service,每个 zone 里边有不同的 iptables 规则,默许一共有 9 个 zone,而 Centos7 默许的 zone 为 public:
-
drop(丢弃)
:任何接纳的网络数据包都被抛弃,没有任何回复。仅能有发送出去的网络衔接。 -
block(约束)
:任何接纳的网络衔接都被IPv4的icmp-host-prohibited信息和IPv6的icmp-adm-prohibited信息所拒绝。 -
public(公共)
:在公共区域运用,不能信赖网络内的其他计算机不会对你的计算机形成损害,只能接纳经过选取的衔接 -
external(外部)
:特别是为路由器启用了假装功用的外部网。你不能信赖来自网络的其他计算,不能信赖它们不会对你的计算机形成损害,只能接纳经过挑选的衔接。 -
dmz(非军事区)
:用于你的非军事区内的计算机,此区域内可公开拜访,能够有限地进入你的内部网络,只是接纳经过挑选的衔接。 -
work(作业)
:用于作业区。你能够根本信赖网络内的其它计算机不会损害你的计算机。只是接纳经过挑选的衔接。 -
home(家庭)
:用于家庭网络。你能够根本信赖网络内的其它计算机不会损害你的计算机。只是接纳经过挑选的衔接。 -
internal(内部)
:用于内部网络。你能够根本上信赖网络内的其它计算机不会威胁你的计算机,只是接纳经过挑选的衔接。 -
trusted(信赖)
:可接纳一切的网络衔接 -
docker
: 这个当咱们在机器上发动 dockerd 时,docker 自己会默许创建一个 zone。
根据前面防火墙部分的排查,咱们的规则是在 public zone 的,是正常的。
IP 抵触
在排查完上面几种情况之后,现已开端置疑是不是硬件问题导致的。并且联系和厂商和机房网管从机房防火墙层面开端排查,可是结论都是正常。这个问题和两位小伙伴闲谈提了下,他们猜测的点中包括了上面的几种情况,此外还说到一个点便是可能是 IP 抵触。
实践上一开端关于 IP 抵触,第一直觉便是不大可能,由于机房里边的机器都是固定分配的,并且不同单位分配的地址也是按段分配,所以不大可能呈现 IP 抵触。DHCP
可是在扫除上述能够排查的一切问题之后,我又把排查思路转义回到了这个问题上,并开端测验。这儿运用的东西是 arp-scan。
履行:sudo arp-scan -I eno1 -l
(eno1 是我运用的测验机器的网卡标识)
能够看到,的确存在两个相同的 IP,并且有一台经过 mac 地址对比是咱们的机器。经过 arping 也能够看到能够收到两台设备回来的数据包。
那至此根本是明确是由于 IP 抵触导致的。一开端由于当时 IP 绑定了一些上下游服务,不大想改咱们的 ip,于是就尝试从 mac 地址来找设备,可是没能实现。如果你的环境允许,你能够先是经过 mac.bmcx.com/ 查了下当时抵触的那个 mac 地址对应的设备类型和厂商来缩小人工排查规模。
最终再回头来盘一下 IP 抵触的问题,由于之前说到,机房内的设备 IP 都是固定分配的,那为什么会存在 IP 抵触呢?这只能是咱们当时环境是如此的糟糕,当找网管要了工作区及机房 IP 段分配标准时发现,机房的 IP 和工作区域的 IP 分段规则是有重合的。比方机房的 172.87.7.xxx 在工作网环境也会存在,并且是基于 DHCP 协议自动分配 IP 的。
总结
本篇主要记录了一次 Linux 服务端口拜访不通问题的排查进程,触及到了 Linux 防火墙、进程/端口、Docker 以及 arp-scan 等方向和东西。事实证明,大多数问题并不是那么复杂,在没有足够的知识积累的情况下,总归是要花这些成本去补偿自己知识短缺的。最终想说的便是,一个消耗相当大精力排查的问题,不一定是复杂的问题,往往这个问题的发生原因是相关简略的。