IMAP-Verbindung endet immer auf lokalem Server


Moritz123

Erfahrenes Mitglied
#1
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!
 

Nino14

Erfahrenes Mitglied
#2
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
 

Moritz123

Erfahrenes Mitglied
#3
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.
 

Nino14

Erfahrenes Mitglied
#4
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
 

Nino14

Erfahrenes Mitglied
#6
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...
 

Moritz123

Erfahrenes Mitglied
#7
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.
 

Bratkartoffel

gebratene Kartoffel
Premium-User
#8
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
 

Moritz123

Erfahrenes Mitglied
#9
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...
 

Moritz123

Erfahrenes Mitglied
#10
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?
 

Bratkartoffel

gebratene Kartoffel
Premium-User
#11
Hi,

kannst du auf dem Server mal das Programm "strace" installieren und folgenden Befehl hier posten? (ist relativ viel, evtl ist ein Gist angebrachter)
Bash:
strace -vv -s 10000 getent hosts www.web.de
Für web.de sieht das bei mir zum Beispiel so aus: Klick

Grüsse,
BK
 
Zuletzt bearbeitet:

Bratkartoffel

gebratene Kartoffel
Premium-User
#13
Hi,

ich hab den Befehl nochmals etwas angepasst weil strace Strings nach 32 Zeichen automatisch abschneidet. Das ist zum debuggen etwas zu wenig. Könntest du dein Gist nochmal aktualisieren?

Grüsse,
Simon
 

Bratkartoffel

gebratene Kartoffel
Premium-User
#15
In Zeile 87 (lesen der /etc/hosts) ist doch die IPv6 Adresse eingetragen?

Edit: Wir können das Problem gerne auch per Mail oder privaten Nachrichten fortführen, das anonymisieren der Hostnamen hilft in diesem Fall hier nicht gerade bei der Lösungssuche...

Edit-2: Im strace sieht man, dass der Nameserver mit einer IPv6 Adresse antwortet, Zeile 37
Das Byte 0x37 steht auf 0x1C (28), laut Wiki also ein AAAA record.
Ab Byte 0x45 kommt dann die IPv6 Adresse 2A 01 xx xx xx xx xx 00 00 00 00 00 00 02

Edit-3: In der Anfrage steht ab Byte 0x0B dein FQDN, also meinexternerserver.net. Warum hier aber nochmals hetznerserver.net steht weiss ich jetzt nicht und kann ich im RFC auf die schnelle nicht finden.

Edit-4: Zeile 134. Sieht für mich nach einem Fehler in der DNS-Zone aus: mein.externerserver.net.hetznerserver.net

Grüsse,
BK
 
Zuletzt bearbeitet:

Moritz123

Erfahrenes Mitglied
#16
Hallo BK,

danke für dein Durchsehen des GISTs und deine Hinweise. Deine Anmerkung in Edit-4 beschreibt ja genau mein Dilemma: Ich verstehe nicht, warum das passiert, wenn mein Zielhost nicht über einen v6-Eintrag verfügt.
Wie kann ich dieses Zonenfile einsehen? Ich habe dir auch nochmal eine unmaskierte Version des strace geschickt.

Besten Dank nochmals für deine Unterstützung!

Edit — Da war ich wohl etwas vorschnell... Wo kann man denn in diesem Forum eine private Nachricht schicken? Früher ging das doch mal...
 
Zuletzt bearbeitet:

Bratkartoffel

gebratene Kartoffel
Premium-User
#19
Hi,

falls hier mal jemand anderer drüber stolpert, hier das Problem:

Angenommen der Host hat als FQDN "server.foobar.com" und in der /etc/resolv.conf keine speziellen Einstellungen. Als DNS Lookup wird nach "example.net" gesucht:
- Lookup von example.net, Ergebnis: A 127.0.0.1
- Lookup von example.net.foobar.com, Ergebnis: AAAA ::1

Die beiden Lookups sind soweit ich das aus der man resolv.conf rauslesen kann, Standard und überall gleich.
Das Problem war in diesem Fall, dass die Zone von "foobar.com" einen Wildcard AAAA Record hatte, welcher immer die ominöse IPv6 Adresse geliefert hat.

Lösung:
- Entfernen des Wildcard-Eintrags (wurde vom Fragesteller gewählt)
- Eintragen von "search ." in die /etc/resolv.conf (Nach Tests von mir würde das auch gehen)

Der Fragesteller muss wegen der DNS Änderung erstmal die TTL von 24h abwarten, ich denke aber dass das Thema damit dann geschlossen werden kann.

Grüsse,
BK
 

Moritz123

Erfahrenes Mitglied
#20
Hallo BK,

vielen lieben Dank dir (und natürlich auch allen anderen Unterstützern) für die Lösungsfindung! Ich werde mich morgen hier nochmals melden und berichten, ob alles funktioniert.

Beste Grüße!

PS: Es wird wohl ein Rätsel bleiben, warum der Fehler bzw. das Problem erst dem letzten Reboot besteht und vorher trotz unveränderter Einstellungen seit über einem Jahr problemfrei lief...