☰

被阻止的端口 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 显示：

~$ 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，则在启动时首次尝试启动它可能会失败，而手动启动可能会成功，因为 Docker 已经启动。

答案2

@Lekensteyn，谢谢！您的回答让我找到了解决方案。

因为它可能会帮助其他有类似问题的人，所以我做了以下事情：

~$ systemctl list-units --state=failed

这表明有 4 个服务失败（不再使用，是一些遗留解决方案）。

然后，以 root 身份：

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

对每个发生故障的单元执行。

重启后，443端口就空闲了。

相关内容