Порты закрываются для входящего трафика.

Вопрос или проблема

У меня чистая установка Ubuntu 24.04 на облачном сервере для запуска iRedMail 1.7.1.

Сервер показывает

sudo ufw status verbose
Status: inactive

и

$ ss -ltn
.
.
LISTEN       0            511                      0.0.0.0:443                      0.0.0.0:*                        
.
.
.

но с внешней машины я получаю

Nmap scan report for xx.xx.xx.xx
Host is up (0.023s latency).
Not shown: 990 filtered tcp ports (no-response)
PORT    STATE  SERVICE
22/tcp  open   ssh
25/tcp  closed smtp
80/tcp  closed http
110/tcp closed pop3
143/tcp closed imap
443/tcp closed https
465/tcp closed smtps
587/tcp closed submission
993/tcp closed imaps
995/tcp closed pop3s

Если я выполню

server:~$ sudo ufw disable
Firewall stopped and disabled on system startup
server:~$ sudo shutdown -r now

то при перезагрузке я получаю

Nmap scan report for xx.xx.xx.xx
Host is up (0.011s latency).
Not shown: 990 filtered tcp ports (no-response)
PORT    STATE SERVICE
22/tcp  open  ssh
25/tcp  open  smtp
80/tcp  open  http
110/tcp open  pop3
143/tcp open  imap
443/tcp open  https
465/tcp open  smtps
587/tcp open  submission
993/tcp open  imaps
995/tcp open  pop3s

как и ожидалось. Это длится пару минут, а затем что-то снова закрывает порты. UFW по-прежнему показывает как неактивный.

Что может быть причиной такого поведения?

Ответ или решение

Закрытые порты для входящего трафика: анализ проблемы

Вы столкнулись с ситуацией, в которой порты на чистой установке Ubuntu 24.04, используемой для работы iRedMail 1.7.1, закрываются для входящего трафика через некоторое время после перезагрузки сервера. Давайте рассмотрим каждый аспект проблемы и выявим возможные причины её возникновения.

1. Статус брандмауэра

Сначала вы проверили статус брандмауэра UFW, который показал, что он неактивен:

Status: inactive

Это означает, что операции с брандмауэром не должны влиять на поведение серверов, и трассировка портов должна отобразить открытые порты.

2. Открытые и закрытые порты

Первичный скан с использованием Nmap показал, что большинство нужных портов были закрыты, в то время как после отключения и повторной перезагрузки сервера они были открыты. Однако, спустя короткое время, состояние портов изменилось вновь на закрытые.

3. Возможные причины

Основные причины, по которым порты могут закрываться после первоначального открытия, следующие:

  • Службы автоматически завершаются: Проверьте, работают ли службы, обслуживающие соответствующие порты. Можно использовать команду systemctl status <service-name> для проверки статуса служб (например, postfix, dovecot и т.д.).

  • Конфликты конфигураций: Проверьте конфигурационные файлы для ваших служб. Некорректно настроенные файлы могут приводить к сбоям в запуске служб. Убедитесь, что все службы корректно запускаются и работают без ошибок.

  • Автоматическое управление в Firewall: Возможно, на вашем сервере активированы другие системы управления брандмауэром, такие как iptables, которые могут автоматически блокировать порты, даже если UFW неактивен. Проверьте текущие правила iptables с помощью sudo iptables -L.

  • Системные обновления или сторонние приложения: Проверьте, нет ли активных процессов или приложений, которые могут изменять настройки сети или брандмауэра. Это могут быть, например, антивирусные программы или системы безопасности.

4. Диагностика и решение

  • Журналы: Изучите системные журналы, такие как /var/log/syslog и /var/log/messages, чтобы увидеть, не производятся ли неожиданные изменения в конфигурации или не активируются ли другие правила брандмауэра.

  • Мониторинг служб: После перезагрузки сервера, следите за запущенными службами. Установите htop или top, чтобы наблюдать за системными процессами в реальном времени. Чтобы узнать, какие процессы слушают на портах, используйте sudo ss -tuln.

  • Проверка сторонних программ: Если вы установили дополнительные программные пакеты, временно отключите их и проверьте, повлияет ли это на поведение портов.

Заключение

Произведенный анализ показывает, что закрытие портов может происходить по нескольким причинам. Убедитесь в том, что ваши службы корректно работают и что нет сторонних вмешательств в настройки сети. Если проблема сохранится, возможно, стоит рассмотреть обращение к опытным системным администраторам или поиск дополнительной документации по iRedMail и используемым сетевым протоколам.

Оцените материал
Добавить комментарий

Капча загружается...