Назад | Перейти на главную страницу

Почтовый сервер Dovecot / Postfix отвечает на [SYN] с помощью [RST, ACK], когда пользователь пытается подключиться (POP3). Вероятно, iptables?

В настоящее время я пытаюсь решить проблему с почтовым сервером, который позволит пользователям отправлять электронную почту, но не может входить на сервер (POP3) или получать электронную почту с помощью своих клиентов Outlook. Раньше это было возможно, но перемещение сервера в его текущее местоположение сломало его. По понятным причинам я подозреваю, что проблемы возникают из-за брандмауэра.

Во-первых, вот как выглядело рукопожатие (или попытка) до того, как я внес какие-либо изменения в брандмауэр:

почтовый сервер: 192.168.25.26 клиент: 192.168.25.50

     Source     |     Destination     |   PROTO  |     INFO
192.168.25.50        192.168.25.26         TCP        50861 > pop3 [SYN] seq=0 win=65535 len=0
192.168.25.26        192.168.25.50         TCP        pop3 > 58601 [RST, ACK] seq=1 win=1 len=0
192.168.25.50        192.168.25.26         TCP        [TCP Retransmission] 58061 > pop3 [Syn] etc....

и танец [rst, ack], [tcp retransmission] происходит еще раз, прежде чем завершиться неудачей.

Правила межсетевого экрана (Cisco), касающиеся 192.168.25.26 и pop3, следующие:

внутри:

   source     |     destination     |        service     
     any           192.168.25.0/24          tcp/pop3
192.168.25.0/24          any                tcp/smtp
                  208.105.121.196

вне:

   source     |     destination     |        service     
     any           192.168.25.26            tcp/pop3
                        any                 tcp/smtp

Для меня это выглядит нормально.

Чтобы быть уверенным, на почтовом сервере (Zentyal) я выполнил следующие команды:

(IP-таблицы были ТЯЖЕЛО настроены. Я подозреваю, что проблема здесь. Есть ли способ разрешить все трафик, просто для тестирования?)

sudo iptables -F
sudo iptables -P INPUT ACCEPT
sudo iptables -P FORWARD ACCEPT
sudo iptables -P OUTPUT ACCEPT

Однако до сих пор нет возможности подключения к Outlook. На этом этапе на почтовом сервере я выполнил команду:

telnet 127.0.0.1 110

и смог войти на почтовый сервер. От клиента внутри сети я выполнил ту же команду и получил сообщение «сбой подключения».

После этих изменений, когда я пытаюсь «протестировать настройки» в Outlook, вот как выглядит рукопожатие. Я заметил кое-что особенное.

     Source     |     Destination     |   PROTO  |     INFO
192.168.25.50        192.168.25.26         TCP        apollo-status > pop3 [SYN] seq=0 win=65535 len=0
192.168.25.26        192.168.25.50         TCP        pop3 > apollo-status [RST, ACK] seq=1 win=1 len=0
192.168.25.50        192.168.25.26         TCP        [TCP Retransmission] apollo-status > pop3 [Syn] etc....

и делает это еще дважды, как в прошлый раз. На панели ИНФОРМАЦИЯ я теперь вижу apollo-status вместо номера порта. Следующие два раза я запустил его и увидел соответственно npep_messaging и synapse. Я подозреваю, что это случайные порты, выбранные dovecot, потому что в dovecot.config я изменил прослушиватель по умолчанию на звездочку «*» с ранее указанного порта, который казался произвольным портом из 4000 и не имел правил в брандмауэр.

Чтобы подтвердить, кажется, что порт, который он использует каждый раз, меняется в зависимости от (рекомендованной) конфигурации. К порту 110 интерфейса обратной петли явно прикреплен слушатель, но с другого компьютера он кажется закрытым.

Любая помощь вообще ценится. Я ломал себе голову над этим и надеюсь, что у сообщества serverfault появятся новые идеи.

Спасибо!