問題描述

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

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

同機(jī)房同機(jī)柜還有其他 3 臺服務(wù)器，ip 地址分別為 172.87.7.246，172.87.7.247，172.87.7.248。在 172.87.7.249 出現(xiàn)頻繁性不可訪問的同時，在辦公網(wǎng)環(huán)境其他 3 臺機(jī)器訪問均無影響，并在當(dāng)在辦公網(wǎng)通過 ssh 登錄 172.87.7.249 提示 Connection refused 時，通過其他三臺機(jī)器的任何一臺 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 同處一個機(jī)房，一個機(jī)柜，連接的也是同一個核心交換機(jī)，同一個網(wǎng)關(guān)。
• 2、辦公網(wǎng)環(huán)境訪問 172.87.7.249，前期偶發(fā)性時好時壞，后期頻繁不可訪問，間歇性可訪問。
• 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 通

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

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

排查過程

防火墻配置

一般情況下，IP 能 ping 通，端口無法訪問，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)卡的對應(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 ~]#

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

進(jìn)程是否 OK

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

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

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

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

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

關(guān)于第二個，這里稍微介紹下；firewalled 有兩個基礎(chǔ)概念，分別是 zone 和 service，每個 zone 里面有不同的 iptables 規(guī)則，默認(rèn)一共有 9 個 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ī)造成危害，只能接收經(jīng)過選取的連接

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

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

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

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

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

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

• docker: 這個當(dāng)我們在機(jī)器上啟動 dockerd 時，docker 自己會默認(rèn)創(chuàng)建一個 zone。

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

IP 沖突

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

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

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

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

可以看到，確實(shí)存在兩個相同的 IP，并且有一臺通過 mac 地址對比是我們的機(jī)器。通過 arping 也可以看到能夠收到兩臺設(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)前沖突的那個 mac 地址對應(yīng)的設(shè)備類型和廠商來縮小人工排查范圍。

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

總結(jié)

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

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

最新評論