☰

Заблокированный порт 443 разблокируется после «nmap 127.0.0.1»

tag-icon • tag-icon linux networking port
Заблокированный порт 443 разблокируется после «nmap 127.0.0.1»

Я сталкиваюсь с очень странным поведением на моей машине CI/CD Linux (работающей 16.04.4 LTS + Gitlab CI в контейнере Docker) и ищу "путь отладки" для этой проблемы. А проблема в том, что после каждой перезагрузки мой контейнер 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запуститьфпросмотрите логи и снова запустите 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 свободен.

Связанный контент