問題描述

項(xiàng)目中使用的服務(wù)器是物理機(jī)，使用 centos 7.6 版本的操作系統(tǒng)， 4 個(gè)千兆網(wǎng)口，上架時(shí)間 23 年 8 月份。部署在內(nèi)網(wǎng)機(jī)房，并且在內(nèi)網(wǎng)機(jī)房分配的固定IP 是 172.87.7.249，并在機(jī)器上部署了 docker，

大概在 10 月中旬左右，這臺(tái)機(jī)器出現(xiàn)訪問時(shí)好是壞的問題；前期出現(xiàn)時(shí)一直以為是機(jī)房調(diào)整網(wǎng)絡(luò)環(huán)境導(dǎo)致，短暫性的不可訪問沒有實(shí)際影響業(yè)務(wù)，所以就沒太關(guān)注。但是從 10 月底開始，機(jī)器開始頻繁性出現(xiàn)不可訪問的問題，開始接入排查。

同機(jī)房同機(jī)柜還有其他 3 臺(tái)服務(wù)器，ip 地址分別為 172.87.7.246，172.87.7.247，172.87.7.248。在 172.87.7.249 出現(xiàn)頻繁性不可訪問的同時(shí)，在辦公網(wǎng)環(huán)境其他 3 臺(tái)機(jī)器訪問均無(wú)影響，并在當(dāng)在辦公網(wǎng)通過 ssh 登錄 172.87.7.249 提示 Connection refused 時(shí)，通過其他三臺(tái)機(jī)器的任何一臺(tái) ssh 登錄 172.87.7.249，卻可以登錄。

總結(jié)下現(xiàn)象：

• 1、172.87.7.246，172.87.7.247，172.87.7.248，172.87.7.249 同處一個(gè)機(jī)房，一個(gè)機(jī)柜，連接的也是同一個(gè)核心交換機(jī)，同一個(gè)網(wǎng)關(guān)。
• 2、辦公網(wǎng)環(huán)境訪問 172.87.7.249，前期偶發(fā)性時(shí)好時(shí)壞，后期頻繁不可訪問，間歇性可訪問。
• 3、辦公網(wǎng)環(huán)境訪問 172.87.7.248/247/246，正常。
• 4、172.87.7.248/247/246 訪問 172.87.7.249 前期正常，后期短暫間歇性不可訪問，但大多數(shù)情況下是可以訪問的。
• 5、172.87.7.249 能 ping 通

看到這里，對(duì)于熟悉網(wǎng)絡(luò)的大神應(yīng)該能猜到個(gè)八九不離十的原因了，但是對(duì)于研發(fā)工程師來說，網(wǎng)絡(luò)問題一直都是技術(shù)上的疼點(diǎn)。

下面就從研發(fā)視角來看下排查過程。

排查過程

防火墻配置

一般情況下，IP 能 ping 通，端口無(wú)法訪問，99% 的原因都是出在防火墻；

• 1、先通過 systemctl status firewalld 查看防火墻狀態(tài)，可以看到防火墻正常開啟

[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 查看端口開發(fā)策略，22 端口正常的

[root@localhost ~]# firewall-cmd --list-ports
22/tcp 80/tcp 9080/tcp

 一般情況下，默認(rèn) zone 是 public；

• 3、這里為了避免可能是 zone 策略問題，也看了下 zone 和出網(wǎng)網(wǎng)卡的對(duì)應(yīng)

[root@localhost ~]# firewall-cmd --get-active-zones
public
  interfaces: enp61s0f0
[root@localhost ~]#
[root@localhost ~]# firewall-cmd --get-zone-of-interface=enp61s0f0
public
[root@localhost ~]#

• 這里也沒問題，同時(shí)為了避免環(huán)境差異，對(duì)比了其他三臺(tái)機(jī)器，配置策略都是一樣的。

進(jìn)程是否 OK

之前在使用 onlyoffic 時(shí)遇到的一個(gè)問題，在宿主機(jī)上通過 docker 啟動(dòng) onlyoffic，啟動(dòng)完成之后通過 docker ps 查看鏡像運(yùn)行狀態(tài)是正常的，通過 netstat 查看端口對(duì)應(yīng)的進(jìn)程也存在（宿主機(jī)的），但是也是端口無(wú)法訪問；當(dāng)時(shí)問題是因?yàn)殓R像容器內(nèi)部的 nginx 進(jìn)程沒有被拉起導(dǎo)致的，就是宿主機(jī)的端口正常，但是映射到容器內(nèi)部的端口對(duì)應(yīng)的進(jìn)程不存在。

為了避免重復(fù)踩坑，也漲了記性查了下進(jìn)程

[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 進(jìn)程也是正常的。實(shí)際上到這里從研發(fā)視角的排查基本就到頭了，但是這些都是正常的，問題依然存在。

是否和 docker 有關(guān)

在排查完防火墻和進(jìn)程之后，把目標(biāo)瞄向了 docker 容器了，這里的依據(jù)是：

• 1、執(zhí)行 systemctl status firewalld 時(shí)，有一條告警

WARNING: COMMAND_FAILED: '/usr/sbin/iptables -w10 -D FORWARD -i docker0 -o d

• 2、執(zhí)行 firewall-cmd --get-zones 時(shí)，提示

block dmz docker drop external home internal nm-shared public trusted work

實(shí)際上這兩個(gè)問題從排查來看，并不是前述問題的原因，但是這兩個(gè)提示把我們排查的方向帶的有點(diǎn)偏。首先是第一個(gè)告警，這個(gè)問題是因?yàn)?dockerd 啟動(dòng)時(shí)，參數(shù) –iptables 默認(rèn)為 true，表示允許修改 iptables 路由表；當(dāng)時(shí)排查時(shí)，我是直接將 docker stop 掉了，因此排除了這個(gè)因素，如果需要修改docker iptables ，可以在 /etc/docker/daemon.json 這個(gè)文件修改。

關(guān)于第二個(gè)，這里稍微介紹下；firewalled 有兩個(gè)基礎(chǔ)概念，分別是 zone 和 service，每個(gè) zone 里面有不同的 iptables 規(guī)則，默認(rèn)一共有 9 個(gè) zone，而 Centos7 默認(rèn)的 zone 為 public：

• drop（丟棄）：任何接收的網(wǎng)絡(luò)數(shù)據(jù)包都被拋棄，沒有任何回復(fù)。僅能有發(fā)送出去的網(wǎng)絡(luò)連接。

• block（限制）：任何接收的網(wǎng)絡(luò)連接都被IPv4的icmp-host-prohibited信息和IPv6的icmp-adm-prohibited信息所拒絕。

• public（公共）：在公共區(qū)域使用，不能相信網(wǎng)絡(luò)內(nèi)的其他計(jì)算機(jī)不會(huì)對(duì)你的計(jì)算機(jī)造成危害，只能接收經(jīng)過選取的連接

• external（外部）：特別是為路由器啟用了偽裝功能的外部網(wǎng)。你不能信任來自網(wǎng)絡(luò)的其他計(jì)算，不能相信它們不會(huì)對(duì)你的計(jì)算機(jī)造成危害，只能接收經(jīng)過選擇的連接。

• dmz（非軍事區(qū)）：用于你的非軍事區(qū)內(nèi)的計(jì)算機(jī)，此區(qū)域內(nèi)可公開訪問，可以有限地進(jìn)入你的內(nèi)部網(wǎng)絡(luò)，僅僅接收經(jīng)過選擇的連接。

• work（工作）：用于工作區(qū)。你可以基本相信網(wǎng)絡(luò)內(nèi)的其它計(jì)算機(jī)不會(huì)危害你的計(jì)算機(jī)。僅僅接收經(jīng)過選擇的連接。

• home（家庭）：用于家庭網(wǎng)絡(luò)。你可以基本信任網(wǎng)絡(luò)內(nèi)的其它計(jì)算機(jī)不會(huì)危害你的計(jì)算機(jī)。僅僅接收經(jīng)過選擇的連接。

• internal（內(nèi)部）：用于內(nèi)部網(wǎng)絡(luò)。你可以基本上信任網(wǎng)絡(luò)內(nèi)的其它計(jì)算機(jī)不會(huì)威脅你的計(jì)算機(jī)，僅僅接收經(jīng)過選擇的連接。

• trusted（信任）：可接收所有的網(wǎng)絡(luò)連接

• docker: 這個(gè)當(dāng)我們?cè)跈C(jī)器上啟動(dòng) dockerd 時(shí)，docker 自己會(huì)默認(rèn)創(chuàng)建一個(gè) zone。

根據(jù)前面防火墻部分的排查，我們的規(guī)則是在 public zone 的，是正常的。

IP 沖突

在排查完上面幾種情況之后，已經(jīng)開始懷疑是不是硬件問題導(dǎo)致的。并且聯(lián)系和廠商和機(jī)房網(wǎng)管從機(jī)房防火墻層面開始排查，但是結(jié)論都是正常。這個(gè)問題和兩位小伙伴閑聊提了下，他們猜測(cè)的點(diǎn)中包括了上面的幾種情況，此外還提到一個(gè)點(diǎn)就是可能是 IP 沖突。

實(shí)際上一開始關(guān)于 IP 沖突，第一直覺就是不大可能，因?yàn)闄C(jī)房里面的機(jī)器都是固定分配的，而且不同單位分配的地址也是按段分配，所以不大可能出現(xiàn) IP 沖突。DHCP

但是在排除上述可以排查的所有問題之后，我又把排查思路轉(zhuǎn)義回到了這個(gè)問題上，并開始測(cè)試。這里使用的工具是 arp-scan。

執(zhí)行：sudo arp-scan -I eno1 -l （eno1 是我使用的測(cè)試機(jī)器的網(wǎng)卡標(biāo)識(shí)）

可以看到，確實(shí)存在兩個(gè)相同的 IP，并且有一臺(tái)通過 mac 地址對(duì)比是我們的機(jī)器。通過 arping 也可以看到能夠收到兩臺(tái)設(shè)備返回的數(shù)據(jù)包。

那至此基本是明確是因?yàn)?IP 沖突導(dǎo)致的。一開始因?yàn)楫?dāng)前 IP 綁定了一些上下游服務(wù)，不大想改我們的 ip，于是就嘗試從 mac 地址來找設(shè)備，但是沒能實(shí)現(xiàn)。如果你的環(huán)境允許，你可以先是通過https://mac.bmcx.com/ 查了下當(dāng)前沖突的那個(gè) mac 地址對(duì)應(yīng)的設(shè)備類型和廠商來縮小人工排查范圍。

最后再回頭來盤一下 IP 沖突的問題，因?yàn)橹疤岬剑瑱C(jī)房?jī)?nèi)的設(shè)備 IP 都是固定分配的，那為什么會(huì)存在 IP 沖突呢？這只能是我們當(dāng)前環(huán)境是如此的糟糕，當(dāng)找網(wǎng)管要了辦公區(qū)及機(jī)房 IP 段分配標(biāo)準(zhǔn)時(shí)發(fā)現(xiàn)，機(jī)房的 IP 和辦公區(qū)域的 IP 分段規(guī)則是有重合的。比如機(jī)房的 172.87.7.xxx 在辦公網(wǎng)環(huán)境也會(huì)存在，并且是基于 DHCP 協(xié)議自動(dòng)分配 IP 的。

總結(jié)

本篇主要記錄了一次 Linux 服務(wù)端口訪問不通問題的排查過程，涉及到了 Linux 防火墻、進(jìn)程/端口、Docker 以及 arp-scan 等方向和工具。事實(shí)證明，大多數(shù)問題并不是那么復(fù)雜，在沒有足夠的知識(shí)積累的情況下，總歸是要花這些成本去彌補(bǔ)自己知識(shí)欠缺的。最后想說的就是，一個(gè)耗費(fèi)相當(dāng)大精力排查的問題，不一定是復(fù)雜的問題，往往這個(gè)問題的產(chǎn)生原因是相關(guān)簡(jiǎn)單的。

以上就是Linux服務(wù)器端口不可訪問問題的排查及解決方法的詳細(xì)內(nèi)容，更多關(guān)于Linux服務(wù)器端口不可訪問的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章！

最新評(píng)論