問題描述

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

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

同機房同機柜還有其他 3 臺服務器，ip 地址分別為 172.87.7.246，172.87.7.247，172.87.7.248。在 172.87.7.249 出現(xiàn)頻繁性不可訪問的同時，在辦公網(wǎng)環(huán)境其他 3 臺機器訪問均無影響，并在當在辦公網(wǎng)通過 ssh 登錄 172.87.7.249 提示 Connection refused 時，通過其他三臺機器的任何一臺 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 同處一個機房，一個機柜，連接的也是同一個核心交換機，同一個網(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)絡的大神應該能猜到個八九不離十的原因了，但是對于研發(fā)工程師來說，網(wǎng)絡問題一直都是技術(shù)上的疼點。

下面就從研發(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

 一般情況下，默認 zone 是 public；

• 3、這里為了避免可能是 zone 策略問題，也看了下 zone 和出網(wǎng)網(wǎ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)境差異，對比了其他三臺機器，配置策略都是一樣的。

進程是否 OK

之前在使用 onlyoffic 時遇到的一個問題，在宿主機上通過 docker 啟動 onlyoffic，啟動完成之后通過 docker ps 查看鏡像運行狀態(tài)是正常的，通過 netstat 查看端口對應的進程也存在（宿主機的），但是也是端口無法訪問；當時問題是因為鏡像容器內(nèi)部的 nginx 進程沒有被拉起導致的，就是宿主機的端口正常，但是映射到容器內(nèi)部的端口對應的進程不存在。

為了避免重復踩坑，也漲了記性查了下進程

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

是否和 docker 有關(guān)

在排查完防火墻和進程之后，把目標瞄向了 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

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

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

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

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

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

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

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

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

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

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

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

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

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

IP 沖突

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

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

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

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

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

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

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

總結(jié)

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

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

最新評論