☰

被封鎖的連接埠 443 在「nmap 127.0.0.1」之後解除封鎖

tag-icon • tag-icon linux networking port
被封鎖的連接埠 443 在「nmap 127.0.0.1」之後解除封鎖

我在 CI/CD Linux 機器上遇到了一個非常奇怪的行為（在 Docker 容器中運行 16.04.4 LTS + Gitlab CI），我正在尋找該問題的「偵錯路徑」。問題是，每次重新啟動後，我的 Gitlab CI 容器都無法啟動，因為連接埠 443（它應該使用）。網路統計顯示：

~$ netstat -ano | grep 443
tcp6       0      0 :::443                  :::*                    LISTEN      off (0.00/0/0)

我嘗試使用fuser，tcpkill以及我發現的更多解決方案。它們都沒有真正發揮作用。看起來它總是被 PID 1 使用。

但後來我決定執行nmap 127.0.0.1，這件事向我展示了：

~$ nmap 127.0.0.1

Starting Nmap 7.01 ( https://nmap.org ) at 2019-03-18 09:31 CET
Nmap scan report for localhost (127.0.0.1)
Host is up (0.00015s latency).
Not shown: 997 closed ports
PORT     STATE SERVICE
22/tcp   open  ssh
443/tcp  open  https
5900/tcp open  vnc

Nmap done: 1 IP address (1 host up) scanned in 0.15 seconds

之後......連接埠變成空閒 - 該指令的第二次執行顯示：

~$ nmap 127.0.0.1

Starting Nmap 7.01 ( https://nmap.org ) at 2019-03-18 09:31 CET
Nmap scan report for localhost (127.0.0.1)
Host is up (0.00016s latency).
Not shown: 998 closed ports
PORT     STATE SERVICE
22/tcp   open  ssh
5900/tcp open  vnc

Nmap done: 1 IP address (1 host up) scanned in 0.09 seconds

這怎麼可能，nmap能夠釋放繁忙的連接埠？每次都有效。

我很好奇為什麼會發生這種情況，但我不知道從“哪裡”開始調試。或者也許這是一個常見問題，但我找不到任何描述？

答案1

您檢查過 Ubuntu 主機上的系統日誌嗎？您可以使用該journalctl命令來實現此目的。我能想到的一個潛在原因是套接字激活其中 systemd（以 PID 1 運行）偵聽連接埠並在某些東西（如 nmap）嘗試連接到該連接埠時啟動一個進程。

要測試這個理論，您可以重新啟動並journalctl -f運行F依照日誌並在不同的 shell 中再次執行 nmap。

除了檢查日誌之外，您還可以執行systemctl或systemctl status找出哪些服務已啟動或已失敗。

最後，由於缺少依賴項，服務也完全有可能無法在啟動過程中較早啟動。例如，如果您的服務依賴 Docker，但沒有（隱式）聲明它，那麼在引導時啟動它的初始嘗試可能會失敗，而手動啟動可能會很幸運地工作，因為 Docker 已經啟動了。

答案2

@Lekensteyn，謝謝！你的回答讓我找到了解決方案。

因為它可能會幫助其他遇到類似問題的人，所以我做了什麼：

~$ systemctl list-units --state=failed

這表示有 4 個失敗的服務（不再使用，是一些遺留解決方案）。

然後，以 root 身分：

~# systemctl stop <a_failed_service_name> && systemctl disable <a_failed_service_name>

對每個失敗的單元執行。

重啟後，443埠空閒。

相關內容