2017-01-06 4 views
-1

==== ==== GrundinformationenUbuntu 14.01 Host/Ubuntu 14.01 Container; Postfix sendet keine Mail; Telnet keine Verbindung zum externen Host

  • iRedMail Version (Check/etc/iredmail-release): iRedMail-0.9.5-1

  • Linux/BSD Distribution Name und Version: Ubuntu 14.01 Container innerhalb Ubuntu 14.01 TurnkeyLinux Kern

  • Shop-Mail-Konten, in dem Backend (LDAP/MySQL/PGSQL): MySQL

  • Web se rver (Apache oder Nginx): Apache

  • Postfix Protokollauszug:

    6. Januar 10.24.38 iredmail postfix/Vorlage/smtpd [2631]: Verbindung von xyz [127.0.0.1]

    Jan 6 10:24:38 iredmail postfix/submission/smtpd [2631]: Anonyme TLS-Verbindung aus xyz [127.0.0.1]: TLSv1.2 mit Chiffre ECDHE-RSA-AES128-GCM-SHA256 (128/128 Bit)

    Jan 6 10:24:38 Mailpost postfix/submission/smtpd [2631]: 6EEA060306: Client = xyz [127.0.0.1], sasl_method = LOGIN, sasl_username = Adresse @ xyz

    6. Januar 10.24.38 iredmail postfix/Bereinigungs [2636]: 6EEA060306: message-id =

    6. Januar 10.24.38 iredmail roundcube: User iaaberga [192.168.121.1]; Nachricht für [email protected]; 250: 2.0.0 Ok: eine Warteschlange eingereiht, wie 6EEA060306

    Jan 6 10.24.38 iredmail Postfix/qmgr [2587]: 6EEA060306: from =, size = 575, nrcpt = 1 (Warteschlange aktiv)

    Jan 6 10:24:38 iredmail postfix/submission/smtpd [2631]: trennen von xyz [127.0.0.1]

    Jan 6 10:24:38 iredmail postfix/smtpd [2648]: verbinden von xyz [127.0.0.1

    ]

    Jan 6 10.24.38 iredmail Postfix/smtpd [2648]: C97F262D1B: client = xyz [127.0.0.1]

    Jan 6 10: 24: 3 8 iredmail Postfix/Bereinigung [2636]: C97F262D1B: Nachricht-ID =

    Jan 6 10:24:38 Mailpost postfix/qmgr [2587]: C97F262D1B: von =, Größe = 1628, nrcpt = 1 (Warteschlange aktiv)

    Jan 6 10.24.38 iredmail Postfix/smtpd [2648]: Trennen von xyz [127.0.0.1]

    Jan 6 10.24.38 iredmail amavis [1742]: (01.742-01) Bestanden CLEAN {RelayedInternal}, URSPRUNG/MYNETS LOCAL [127.0.0.1]: 35413 ->, Warteschlangen-ID: 6EEA060306, Nachrichten-ID:, Mail-ID: 4QjhhYZODSHf, Zugriffe: -2.986, Größe: 575, Warteschlange: C97F262D1B, dkim_new = dkim : yz, 328 ms, Tests: [ALL_TRUSTED = -1, RP_MATCHES_RCVD = -3.199, TVD_RCVD_SINGLE = 1.213]

    Jan 6 10:24:38 iredmail postfix/smtp [2642]: 6EEA060306: zu =, Relais = 127.0.0.1 [127.0.0.1]: 10026, Verzögerung = 0.4, Verzögerungen = 0.05/0.01/0.01/0.33, dsn = 2.0.0, status = gesendet (250 2.0.0 von MTA (smtp: [127.0.0.1]: 10025): 250 2.0.0 Ok: eine Warteschlange eingereiht, wie C97F262D1B)

    Jan 6 10.24.38 iredmail Postfix/qmgr [2587]: 6EEA060306:

    entfernt

    Jan 6 10.24.47 iredmail Postfix/SMTP- [2618]: Verbindung zu mx6.mail.icloud.com [17.172.34.71]: 25: Zeitüberschreitung der Verbindung

    Jan 6 10:24:47 iredmail postfix/smtp [2622]: Verbinden Sie sich mit alt1.gmail-smtp-in.l.google .com [173.194.69.27]: 25: Connection timed out

====

Hallo!

Ich habe iRedmail als lxc Container auf einem Ubuntu 14.01/Ubuntu 14.01 Host/Container System installiert.

Während ich E-Mails empfangen kann, sendet Postfix keine Nachrichten (die anscheinend im Webmail-Client versendet werden, aber nie zu dest kommen).

Von der Container-Ebene scheint die Konnektivität im Allgemeinen zu funktionieren: Ich kann ssh zu einem Host, auf den ich Zugriff habe; Ich kann apt-get-Tools verwenden, um neue sw usw. zu installieren.

Der Versuch, telnet alt1.gmail-smtp-in.l.google.com auf Port 25 zu verwenden, ist nicht erfolgreich (wenn dies über den Container erfolgt).

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

Schließlich wird die Verbindung fehlschlagen.

Wenn ich Austritt aus dem Behälter zu tun und versuchen, die gleiche Telnet-Verbindung, die alle gut sind

[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. 

Die iptables config Container ist:

*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 

Ich bin nicht vertraut mit Containern Networking , also vermisse ich sehr wahrscheinlich etwas Offensichtliches!

Es tut nicht Blick ein Problem mit Postfix config sein ..

Vielen Dank für jede Hilfe,

Aldo

+0

Also, zur Erinnerung: der Ubuntu 'Host' kann telnet zu Google. Der Ubuntu 'Container' kann nicht mit Google telnet werden, hat aber kein Problem mit SSH oder apt-get. Und es erhält E-Mails über den Host (das ist auf AWS). – aaberga

+0

flush iptables Regeln im Container, ändern Sie die Richtlinien zum Akzeptieren und erneut versuchen. Wenn es ein Problem mit Ihren iptables-Regeln gibt, sollte Ihr Telnet funktionieren. Eine andere Sache wäre, den Container-Dienst auf dem Ubuntu-Host neu zu starten und den Container zu starten und es erneut zu versuchen. –

+0

Danke Farhad, aber das hilft nicht. Ich weiß jetzt grob was schief geht. Da ich vermutete, dass ich die iptables-Einstellungen des Containers unkontrolliert bearbeitet habe, habe ich einen zweiten Container erstellt und gesehen, wie die iptables-Einstellungen dort aussehen. Als ich es war, habe ich versuche, die root @ iredmail2 ~ # telnet alt1.gmail-smtp-in.l.google.com 25 Befehl ... Der Versuch ... Verbunden mit alt1.gmail-smtp-in.l.google.com. Escape-Zeichen ist '^]'. ESMTP Postfix BEENDEN 221 2.0.0 Tschüss Verbindung vom fremden Host geschlossen. – aaberga

Antwort

0

Wie es passiert oft das Problem (wenn man die Lösung wissen) war trivial ...

Kurz gesagt: eine falsche NAT-Einstellung im Host war Abfangen und Weiterleiten von Datenverkehr aus allen Quellen, CONTAINERS INCLUDED !!

Dies ist der relevante Teil der iptables-Regeln'S HOST, wie es war:

*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 

Es erzählt iptables der gesamte Verkehr auf Port 25 an die virtuelle Adresse des Mail-Server-Container sagen zu übergeben. Dies geschieht sogar für den Verkehr aus dem Container selbst.

BINGO !!

Jetzt ist dies die richtige Einstellung, wobei br0 die AWS-Netzwerkschnittstelle ist, die mit der Außenwelt verbunden ist. Daher sollten nur Pakete, die zuerst dort ankommen, an die NATted virtuelle Adresse des E-Mail-Serverpakets weitergeleitet werden.

*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 

Offensichtlich ohne die Überwachungsschleife der E-Mail-Server innerhalb des Containers sendet einfach Mail aus !!

Verwandte Themen