IMAP-Verbindung endet immer auf lokalem Server

Moritz123

Erfahrenes Mitglied
Hallo zusammen,

ich habe gerade nach langer Zeit meinen Hetzner Rootserver mal wieder neugestartet (wegen CVE-215-7547) und stehe nun vor folgendem Problem: Wenn ich ein
Code:
$ telnet mein.externerserver.net imap
Trying [meineHetznerIPv6Adresse]...
Connected to mein.externerserver.net.meinhetznerserver.net.
Escape character is '^]'.
* OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE STARTTLS AUTH=PLAIN AUTH=LOGIN] Dovecot ready.
mache, wird auch eine Telnet-Verbindung geöffnet, allerdings nicht zu meinem externen Mailserver sondern zu dem lokalen Dovecot. Hier schlägt eine Authentifizierung natürlich fehl, weil der Nutzer lokal nicht existiert. Mache ich das Ganze zu einem externen Server der via IPv6 erreichbar ist (bspw. imap.gmail.com), funktioniert das Ganze wie gewohnt. Gleiches Bild zeigt sich, wenn ich telnet mit "-4" dazu zwinge direkt eine IPv4 Verbindung aufzubauen.

Versuche ich das Ganze dann mit einem anderen Protokoll (zB. pop3) funktioniert auch alles ohne Problem — allerdings habe ich auf meinem Server auch kein Pop3 aktiviert, dh der Port ist zu.

Ich verstehe die Welt nicht mehr...

Achso hier noch meine /etc/resolv.conf:
Code:
### Hetzner Online AG installimage
# nameserver config
nameserver 213.133.100.100
nameserver 213.133.98.98
nameserver 213.133.99.99
nameserver 2a01:4f8:0:a0a1::add:1010
nameserver 2a01:4f8:0:a111::add:9898
nameserver 2a01:4f8:0:a102::add:9999


Vielen Dank!
 
Hallo,

Das klingt schon irgendwie sehr komisch. Wie hast du sicher gestellt, dass du auf deinem lokalen Server raus kommst?

mach mal bitte eine telnet Verbindung direkt auf die IPv6 und prüfe dann, ob du auf dem richtigem Server raus kommst.
Wenn ja, dann geht in deiner Namensauflösung etwas schief.

Sollte es mit der Verbindung über IP auch nicht funktionieren, wäre es interessant den Inhalt deiner lokalen host Datei zu prüfen.
Das du mit pop3 auf dem richtigen Server ankommst spricht aber eigentlich gegen die Theorie mit der host Datei.

Die Zeile 3. bei deinem Telnet Aufruf sieht komisch aus. Steht das da wirklich so?

Hast du auf deinem lokalen Rechner eine Firewall, die unter Umständen die Umleitung bewirken könnte? Oder im Netzwerk eine Firewall die dort irgendwo eingreift?

Dass der Fehler bei dem Server selber liegt kann ich mir nicht wirklich vorstellen.

VG
Nino
 
Hallo Nino,

erst einmal vielen Dank für deine Antwort. Hier meine Infos zu deinen Fragen:

Das klingt schon irgendwie sehr komisch. Wie hast du sicher gestellt, dass du auf deinem lokalen Server raus kommst?
Weil ich die fehlgeschlagenen Anmeldungen im Dovecot Log auf meinem lokalen Server sehe.

mach mal bitte eine telnet Verbindung direkt auf die IPv6 und prüfe dann, ob du auf dem richtigem Server raus kommst. Wenn ja, dann geht in deiner Namensauflösung etwas schief.
Das geht leider nicht, weil mein externer Mailserver (also der zu dem eigentlich verbunden werden sollte) gar nicht mit v6 angebunden ist, sondern nur via v4. Wenn ich ein telnet auf imap.gmail.com mache, lande ich auch bei gmail. Das Problem scheint also darin zu liegen, dass im Fall das ein Dienst auf einem externen Server nicht via v6 erreichbar ist, nicht ein Fallback auf v4 stattfindet, sondern die Namensauflösung den lokalen Server als Ziel ausgibt.

Sollte es mit der Verbindung über IP auch nicht funktionieren, wäre es interessant den Inhalt deiner lokalen host Datei zu prüfen. Das du mit pop3 auf dem richtigen Server ankommst spricht aber eigentlich gegen die Theorie mit der host Datei.
Code:
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts
Hier (der relevante) Teil der meiner Hosts.
Das es mit POP3 funktioniert liegt m.E. daran, dass ich lokal keinen POP3 betreibe, daher also keine Verbindung aufgebaut werden kann und so ein korrekter Fallback auf v4 stattfindet, der korrekt funktioniert.
Wie ich gerade feststellen durfte, gibt es bei SMTP das gleiche unangenehme Problem. Auch hier lande ich statt auf meinem nur via v4 angebundenen externen auf meinem lokalen SMTP.

Die Zeile 3. bei deinem Telnet Aufruf sieht komisch aus. Steht das da wirklich so?
Jap — exakt so sieht sie aus.

Hast du auf deinem lokalen Rechner eine Firewall, die unter Umständen die Umleitung bewirken könnte? Oder im Netzwerk eine Firewall die dort irgendwo eingreift?
Ja ich nutze ufw bzw. iptables. Da ich aber weder an der einen, noch an der anderen etwas geändert habe und das Problem fortbesteht, wenn ich beide deaktiviere, glaube ich nicht, dass es daran liegt. Im Netzwerk gibt es — so weit ich weiß — keine Firewall die in dieser Art in den Netzwerkverkehr eingreift.

Ich habe mir bis dato damit beholfen, sowohl meinen lokalen IMAP als auch SMTP nicht mehr über v6 bereitzustellen. Das ist natürlich äußerst unbefriedigend, daher würde ich mich sehr über weitere Hinweise freuen.
 
Okay ich vermute immernoch ein Problem beim DNS. Das würde das "Fallback" verhalten erklären..

Mach bitte einmal ein
Code:
host mein.externerserver.net
und poste die Ausgabe
 
Okay das macht DNS unwahrscheinlich, klingt aber immer noch als beste Erklärung für dein Problem.
Tut mir Leid, dann gehen mir von hier aus die Ideen aus.

Irgendetwas veranlasst dein Telnet dazu eine IPv6 Verbindung aufzubauen, obwohl der Host keine AAAA record hat. (Das macht keinen Sinn.)
Vermutlich versucht er immer erst die IPv6 und dann die IPv4. Kann er auf IPv6 nicht verbinden nimmt er halt IPv4. Das erklärt, warum es bei Protokollen funktioniert, die lokal nicht verfügbar sind.

Du musst jetzt raus bekommen, was dein Telnet denken lässt, dass mein.externerserver.net einen AAAA record auf deinen lokalen Server hat. Woran das liegen könnte habe ich mit den Infos aktuell keine Idee. Ansätze die man untersuchen könnte sind: DNS-Caches/DNS-Forwarder/DNS-Server, Firewalls, Lokale Systeme zum Umgehen von DNS, evtl. Konfiguration von telnet

Eventuell hat hier ja noch jemand anders einen Ansatz, wo man suchen könnte...
 
Hallo Nino,

vielen Dank für deine Mühen — ich werde die von dir genannten Anhaltspunkte mal durchgehen und zurück melden, bin aber tatsächlich auch total ratlos. Noch ein Hinweis: so wie es aussieht ist das Problem nicht auf Telnet beschränkt, da ich — und das war der Grund warum mir das Problem überhaupt aufgefallen ist — mein Webmailer (Rainloop), der ebenfalls auf dem Hetznerserver läuft sich nicht mehr zu meinem externen Mailserver verbinden konnte.
 
Hi,

nachdem ich den Thread bisher so überflogen habe und eigentlich alle meine Vorschläge bereits abgehandelt wurden, hier noch etwas abstruses:
Wie sehen deine iptables aus? Hast du da evtl ein NAT drin?
Was steht in deiner /etc/nsswitch.conf? Hier könnte man ausser "files" und "dns" bei den hosts noch was anderes eintragen.
Was liefert ein "getent hosts dein.telnet.hostname"? Hier wird die Namensauflösung über die libc gemacht, also 1:1 wie telnet.

Grüsse,
BK
 
Hallo Bratkartoffel,

hier die Ausgabe der /etc/nsswitch.conf:
Code:
passwd:         compat
group:          compat
shadow:         compat

hosts:          files dns
networks:       files

protocols:      db files
services:       db files
ethers:         db files
rpc:            db files

netgroup:       nis

Und hier die Ausgabe von "iptables --list" bzw. "ip6tables --list" (der Länge wegen als Gist).

Danke auch für den Tipp mit dem getent! Hier zeigt sich folgendes Bild
Code:
$ getent hosts mein.externerserver.net
[meineHetznerIPv6Adresse] mein.externerserver.net.meinhetznerserver.net.

Ich bekomme also die falsche IPv6 Adresse zurück. Statt einer "null" Antwort (da mein externer Server ja keinen IPv6 Record hat) kommt die lokale v6 Adresse zurück. Wenn hier die libc für die Namensauflösung veranwortlich ist, würde das erklären warum das Problem erst besteht, seit dem ich die libc wegen CVE-20156-7547 aktualisiert habe.
Bleibt nur die Frage, woher um alles in der Welt die libc dann die v6 Adresse nimmt...
 
Also ich bin noch kein Stück weiter leider, habe aber mal einen tcpdump gemacht.
Hier die Ergebnisse:

Code:
$> dig AAAA mein.externerserver.net
16:55:42.764542 IP (tos 0x0, ttl 64, id 45170, offset 0, flags [none], proto UDP (17), length 66)
    [meineHetznerV4ip].39386 > 213.133.100.100.53: [udp sum ok] 40292+ AAAA? mein.externerserver.net. (38)
16:55:42.765553 IP (tos 0x0, ttl 60, id 4042, offset 0, flags [none], proto UDP (17), length 111)
    213.133.100.100.53 >[meineHetznerV4ip].39386: [udp sum ok] 40292 q: AAAA? mein.externerserver.net. 0/1/0 ns: externerserver.net. [1h52m41s] SOA ns5.externerserver.net. root.externerserver.net. 2016022467 28800 7200 1209600 7200 (83)
und dann noch:
Code:
$> getent hosts mein.externerserver.net
16:55:53.777837 IP (tos 0x0, ttl 64, id 45171, offset 0, flags [DF], proto UDP (17), length 63)
    [meineHetznerV4ip].48268 > 213.133.100.100.53: [udp sum ok] 35272+ AAAA? mein.externerserver.net. (35)
16:55:53.778593 IP (tos 0x0, ttl 60, id 5479, offset 0, flags [none], proto UDP (17), length 121)
    213.133.100.100.53 > [meineHetznerV4ip].48268: [udp sum ok] 35272 q: AAAA? mein.externerserver.net. 0/1/0 ns: externerserver.net. [1h59m16s] SOA ns3.externerserver.net. root.externerserver.net. 2015121743 28800 7200 1209600 7200 (93)
16:55:53.778724 IP (tos 0x0, ttl 64, id 45172, offset 0, flags [DF], proto UDP (17), length 76)
    [meineHetznerV4ip].42108 > 213.133.100.100.53: [udp sum ok] 51108+ AAAA? mein.externerserver.net.meinhetznerserver.net. (48)
16:55:53.778932 IP (tos 0x0, ttl 60, id 5480, offset 0, flags [none], proto UDP (17), length 104)
    213.133.100.100.53 > [meineHetznerV4ip].42108: [udp sum ok] 51108 q: AAAA? mein.externerserver.net.meinhetznerserver.net. 1/0/0 mein.externerserver.net.meinhetznerserver.net. [23h59m17s] AAAA [meineHetznerIPv6Adresse] (76)

Stellt sich nur die Frage, warum die DNS Abfrage zwei unterschiedliche Ergebnisse zurück liefert je nachdem ob ich "getent hosts" oder "dig" verwende. Und das obwohl offensichtlich die gleichen DNS Server abgefragt werden. Kann man via /etc/resolv.conf irgendwie v6 lookups deaktivieren?
 
Zurück