2017-01-06 13 views
-1

==== Основная информация ====Ubuntu 14.01 Host/Ubuntu 14.01 Контейнер; Postfix не отправляет почту; телнет не соединяется с внешним хостом

  • iRedMail версии (проверить/и т.д./iredmail-релиз): iRedMail-0.9.5-1

  • Linux/BSD имя распространения и версии: Ubuntu 14,01 контейнер внутри Ubuntu 14.01 TurnkeyLinux Ядра

  • магазин почтовых учетных записей, в которых бэкенд (LDAP/MySQL/PGSQL): MySQL

  • Web таковой RVer (Apache или Nginx): Apache

  • Postfix журнала Отрывок:

    6 января 10:24:38 iredmail постфикса/представление/smtpd [2631]: подключение от АБВ [127.0.0.1]

    6 января 10:24:38 iredmail postfix/submission/smtpd [2631]: Анонимное соединение TLS, установленное с помощью xyz [127.0.0.1]: TLSv1.2 с шифрованием ECDHE-RSA-AES128-GCM-SHA256 (128/128 бит)

    Jan 6 10:24:38 iredmail postfix/submission/smtpd [2631]: 6EEA060306: client = xyz [127.0.0.1], sasl_method = LOGIN, sasl_username = address @ xyz

    6 января 10:24:38 iredmail постфикса/очистка [2636]: 6EEA060306: сообщение-ID =

    6 января 10:24:38 iredmail RoundCube: Пользователь iaaberga [192.168.121.1]; Сообщение для [email protected]; 250: 2.0.0 Хорошо: в очереди, как 6EEA060306

    6 января 10:24:38 iredmail постфикса/QMGR [2587]: 6EEA060306: от =, размер = 575, nrcpt = 1 (очередь активны)

    Ян 6 10:24:38 iredmail postfix/submission/smtpd [2631]: отключить от xyz [127.0.0.1]

    Jan 6 10:24:38 iredmail postfix/smtpd [2648]: connect from xyz [127.0.0.1 ]

    6 января 10:24:38 iredmail постфикса/smtpd [2648]: C97F262D1B: клиент = хуг [127.0.0.1]

    6 января 10: 24: 3 8 iredmail postfix/cleanup [2636]: C97F262D1B: message-id =

    Jan 6 10:24:38 iredmail postfix/qmgr [2587]: C97F262D1B: from =, size = 1628, nrcpt = 1 (активная очередь)

    6 января 10:24:38 iredmail постфикса/smtpd [2648]: отключение от хуг [127.0.0.1]

    6 января 10:24:38 iredmail AMaViS [одна тысяча семьсот сорок два]: (01742-01) Passed CLEAN {RelayedInternal}, ORIGINATING/MYNETS LOCAL [127.0.0.1]: 35413 ->, Queue-ID: 6EEA060306, Message-ID:, mail_id: 4QjhYZODSHf, Скачиваний: -2.986, размер: 575, queued_as: C97F262D1B, dkim_new = dkim : yz, 328 мс, Тесты: [ALL_TRUSTED = -1, RP_MATCHES_RCVD = -3.199, TVD_RCVD_SINGLE = 1.213]

    Jan 6 10:24:38 iredmail postfix/smtp [2642]: 6EEA060306: to =, relay = 127.0.0.1 [127.0.0.1]: 10026, delay = 0.4, delayays = 0.05/0.01/0.01/0.33, dsn = 2.0.0, статус = отправлено (250 2.0.0 из MTA (smtp: [127.0.0.1]: 10025): 250 2.0.0 ОК: в очередь, как C97F262D1B)

    Jan 6 10:24:38 iredmail постфикса/QMGR [2587]: 6EEA060306: удален

    6 января 10:24:47 iredmail постфикса/SMTP [2618]: подключение к mx6.mail.icloud.com [17.172.34.71]: 25: Время ожидания подключения

    6 янв. 10:24:47 iredmail postfix/smtp [2622]: подключиться к alt1.gmail-smtp-in.l.google .com [173.194.69.27]: 25: Тайм-аут соединения

====

Привет!

Я установил iRedmail как контейнер lxc в систему хоста/контейнера Ubuntu 14.01/Ubuntu 14.01.

Хотя я могу получать электронные письма, Postfix не отправляет сообщения (которые, как представляется, отправляются в клиенте электронной почты, но никогда не приходят в dest).

С подключением на уровне контейнера, похоже, работает в целом: я могу использовать ssh для некоторого хоста, к которому у меня есть доступ; Я могу использовать инструменты apt-get для установки новых sw и т. Д.

Попытка выполнить telnet alt1.gmail-smtp-in.l.google.com на порт 25 не получается (если это делается изнутри контейнера).

[email protected] ~# telnet alt1.gmail-smtp-in.l.google.com 25 
Trying 173.194.69.26... 

В конечном итоге соединение не удастся.

Если я выйти из контейнера и попробовать то же самое соединение Telnet, все хорошо

[email protected] ~# telnet alt1.gmail-smtp-in.l.google.com 25 
Trying 173.194.69.27... 
Connected to alt1.gmail-smtp-in.l.google.com. 
Escape character is '^]'. 
220 mx.google.com ESMTP t19si1302495wrb.232 - gsmtp 
QUIT 
221 2.0.0 closing connection t19si1302495wrb.232 - gsmtp 
Connection closed by foreign host. 

Это контейнер Iptables конфигурация:

*mangle 
:PREROUTING ACCEPT [0:0] 
:INPUT ACCEPT [0:0] 
:FORWARD ACCEPT [0:0] 
:OUTPUT ACCEPT [0:0] 
:POSTROUTING ACCEPT [0:0] 
COMMIT 
*filter 
:FORWARD ACCEPT [0:0] 
:INPUT DROP [0:0] 
:OUTPUT ACCEPT [0:0] 
-A INPUT -i lo -j ACCEPT 
-A INPUT -p icmp -m icmp --icmp-type echo-request -j ACCEPT 
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT 
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT 
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT 
-A INPUT -p tcp -m tcp --dport 443 -j ACCEPT 
-A INPUT -p tcp -m tcp --dport 12320 -j ACCEPT 
-A INPUT -p tcp -m tcp --dport 12321 -j ACCEPT 

# Mail SMTP 
-A INPUT -p tcp -m tcp --dport 25 -j ACCEPT 
-A FORWARD -p tcp -d 192.168.121.1 --dport 25 -j ACCEPT 

# POP3 
-A INPUT -p tcp -m tcp --dport 110 -j ACCEPT 

# SMTPS 
-A INPUT -p tcp -m tcp --dport 465 -j ACCEPT 
# IMAPS 
-A INPUT -p tcp -m tcp --dport 587 -j ACCEPT 
# IMAPS - 2 
-A INPUT -p tcp -m tcp --dport 993 -j ACCEPT 

COMMIT 

Я не знаком с контейнерами сети , поэтому я вполне мог бы пропустить что-нибудь очевидное!

Это делает не взгляд, проблема с Postfix конфигурации ..

Спасибо за любую помощь,

Aldo

+0

Итак, напомним: «хост Ubuntu» может использовать telnet для Google. Контейнер Ubuntu не может использовать telnet для Google, но не имеет проблем с SSH или apt-get. И он получает электронную почту через хост (то есть на AWS). – aaberga

+0

правила flush iptables в контейнере, изменение политик для принятия и повторной попытки. если есть проблемы с вашими правилами iptables, ваш telnet должен работать. другое дело - перезапустить службу контейнеров на узле ubuntu и запустить контейнер и повторить попытку. –

+0

Спасибо, Фархад, но это не поможет. Теперь я знаю, что происходит не так. Поскольку я подозревал, что редактировал параметры iptables контейнера неконтролируемым образом, я создал второй контейнер и узнал, какие параметры iptables выглядят там. Как я был у него, я попробовать корень @ iredmail2 ~ # телнет alt1.gmail-smtp-in.l.google.com 25 команду ... Попытка ... Подключен к alt1.gmail-smtp-in.l.google.com. Символ выхода - '^]'. ESMTP Postfix QUIT 221 2.0.0 Bye Соединение закрыто иностранным хостом. – aaberga

ответ

0

Как это часто бывает (как только вы знаете, решение проблемы) был тривиальным ...

Вкратце: неправильная настройка NAT в хосте была перехвата и пересылки трафика из всех источников, ВКЛЮЧАЯ КОНТЕЙНЕРЫ !!

Это соответствующая часть правил Iptables хозяина, как это было:

*nat 
:PREROUTING ACCEPT [22532:1479233] 
:INPUT ACCEPT [22432:1472721] 
:OUTPUT ACCEPT [11623:812922] 
:POSTROUTING ACCEPT [2959:155572] 
-A PREROUTING -p tcp -m tcp --dport 25 -j DNAT --to-destination 192.168.121.174:25 
-A PREROUTING -p tcp -m tcp --dport 110 -j DNAT --to-destination 192.168.121.174:110 
-A PREROUTING -p tcp -m tcp --dport 143 -j DNAT --to-destination 192.168.121.174:143 
-A PREROUTING -p tcp -m tcp --dport 465 -j DNAT --to-destination 192.168.121.174:465 
-A PREROUTING -p tcp -m tcp --dport 587 -j DNAT --to-destination 192.168.121.174:587 
-A PREROUTING -p tcp -m tcp --dport 993 -j DNAT --to-destination 192.168.121.174:993 
-A PREROUTING -p tcp -m tcp --dport 995 -j DNAT --to-destination 192.168.121.174:995 
-A POSTROUTING -o br0 -j MASQUERADE 
-A POSTROUTING -s 192.168.121.0/24 ! -o natbr0 -j MASQUERADE 
COMMIT 

Это говорит IPTables передавать весь трафик сказать к порту 25 на виртуальный адрес контейнера почтового сервера. Это происходит даже для трафика из самого контейнера.

BINGO !!

Теперь это правильная настройка, где br0 - это сетевой интерфейс AWS, который связывается с внешним миром. Таким образом, только первые пакеты, поступающие туда, должны быть перенаправлены на NAT-адрес виртуального адреса почтового сервера.

*nat 
:PREROUTING ACCEPT [22532:1479233] 
:INPUT ACCEPT [22432:1472721] 
:OUTPUT ACCEPT [11623:812922] 
:POSTROUTING ACCEPT [2959:155572] 
-A PREROUTING -p tcp -m tcp --in-interface br0 --dport 25 -j DNAT --to-destination 192.168.121.174:25 
-A PREROUTING -p tcp -m tcp --in-interface br0 --dport 110 -j DNAT --to-destination 192.168.121.174:110 
-A PREROUTING -p tcp -m tcp --in-interface br0 --dport 143 -j DNAT --to-destination 192.168.121.174:143 
-A PREROUTING -p tcp -m tcp --in-interface br0 --dport 465 -j DNAT --to-destination 192.168.121.174:465 
-A PREROUTING -p tcp -m tcp --in-interface br0 --dport 587 -j DNAT --to-destination 192.168.121.174:587 
-A PREROUTING -p tcp -m tcp --in-interface br0 --dport 993 -j DNAT --to-destination 192.168.121.174:993 
-A PREROUTING -p tcp -m tcp --in-interface br0 --dport 995 -j DNAT --to-destination 192.168.121.174:995 
-A POSTROUTING -o br0 -j MASQUERADE 
-A POSTROUTING -s 192.168.121.0/24 ! -o natbr0 -j MASQUERADE 
COMMIT 

Очевидно, что без петли перехвата сервер электронной почты внутри контейнера легко отправляет почту!