Seit einem halben Jahr gibt es in den (meisten) Studentenwohnheimen (des Studentenwerks) in Rostock schnelleres Internet. Im Hintergrund wurde neben der Hardware auch der Dienstleister getauscht -- die Cisco-ASA fuer die Einwahl wird nicht mehr vom Rechenzentrum, sondern einer Firma betreut. Und seitdem ist es nicht mehr moeglich, ESMTP zu nutzen. Ob nun Absicht -- oder Versehen -- ich weiss es nicht.

Zur Sache

Die Symptome sind einfach:

[ad001@glas /usr/home/ad001]$ telnet mail.gmx.de smtp
Trying 213.165.64.20...
Connected to mail.gmx.net.
Escape character is '^]'.
220 *******************************************
EHLO tralala
250-mail.gmx.net GMX Mailservices
250-8BITMIME
250-ENHANCEDSTATUSCODES
250-SIZE
250-AUTH=LOGIN PLAIN
250-AUTH LOGIN PLAIN
250 XXXXXXXA
quit
221 2.0.0 GMX Mailservices {mp005}
Connection closed by foreign host.
Zum Vergleich: Wenn ich das ganze durch einen Tunnel, den ich mit ssh -L 3333:mail.gmx.net:25 catalina.informatik.uni-rostock.de einrichten kann schiebe, dann erhalte ich die folgenden Antworten vom Server:
[ad001@glas /usr/home/ad001]$ telnet 127.0.0.1 3333
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 mail.gmx.net GMX Mailservices ESMTP {mp003}
EHLO tralalal
250-mail.gmx.net GMX Mailservices
250-8BITMIME
250-ENHANCEDSTATUSCODES
250-SIZE
250-AUTH=LOGIN PLAIN
250-AUTH LOGIN PLAIN
250 STARTTLS
quit
221 2.0.0 GMX Mailservices {mp003}
Connection closed by foreign host.
Ganz offensichtlich schnueffelt da irgendwer oder -was in meinen Daten umher und macht sich froehlich daran zu schaffen. Indem bestimmte Zeichenketten einfach mal durch Sternchen ersetzt werden. Nicht die feine englische Art.
Die Folge ist, dass mein Mailer glaubt, dass der Server nicht erlaubt, eine verschluesselte Session zu beginnen -- hierzu wird das Schluesselwort STARTTLS genutzt. Welches (tada!) durch Sternchen ersetzt wurde. Also meldet mir mein Mailer ... naja, irgendwas. Zum Beispiel, dass der Server die von mir gewaehlte Technik nicht unterstuetzt. Das ist natuerlich ganz besonders Klasse, wenn man selbst einen Mailserver einrichtet. Ich moechte ungenannt bleiben sollender Firma sehr gerne fuenf Stunden frustrierendster Fehlersuche in Rechnung stellen, die ich anderen nicht in Rechnung stellen wollte (weil sie ja nix dafuer koennen).
Zurueck zum Problem und zurueck zur Loesung.

Um dem Problem lokal mit nur einem Rechner zu entgehen, greife man zu einem Editor und der /etc/hosts (sowas gibts auch unter Windows. Irgendwo.). Dort kann man Zuordnungen von IP-Adressen zu Hostnamen eingeben, die immer Vorrang vor einer DNS-Abfrage haben werden. Also koennen wir hiermit dafuer sorgen, dass unser Mailer nicht wissen muss, was wir geaendert haben. Alternativ kann man sich diesen Schritt natuerlich auch sparen und dem Mailer gleich die Loopback-Adresse 127.0.0.1 als Serveradresse geben... aber das macht nicht den gleichen Spass.
Der Eintrag in der /etc/hosts kann z.B. so aussehen:

127.0.0.1               mail.gmx        mail.gmx.de
Anschliessend sollte eine Aufloesung entsprechend so aussehen:
[ad001@glas /usr/home/ad001]$ ping mail.gmx.de
PING mail.gmx (127.0.0.1): 56 data bytes
Ich habe hier uebrigens ganz bewusst ping und nicht host zum Testen der Aufloesung eingesetzt -- letzteres haette naemlich unbeirrt das Ergebnis einer DNS-Abfrage geliefert.
Zu diesem Zeitpunkt sollte sich der Server beschweren, dass er gar keine Verbindung mehr zum Server aufbauen kann -- es sei denn, auf der lokalen Maschine laeuft ein SMTPd. Also auf zu Teil 2 -- dem Tunnel. Hierzu nutze ich einfach ssh. Denn das kann wirklich viel ;)
[ad001@glas /usr/home/ad001]$ sudo ssh -L 25:mail.gmx.net:25 catalina.informatik.uni-rostock.de
Wenn die Verbindung aufgebaut ist, werden Verbindungen zum lokalen Port 25 zu Catalina weitergegeben und von dort wird eine Verbindung zu mail.gmx.net auf Port 25 aufgebaut und die Daten weitergegeben. Das hilft in oben geschildertem Szenario in soweit, als dass der Tunnel nun durch die Cisco-ASA verschluesselt hindurchgeht -- und die ASA so keine Chance hat, zu bemerken, wann die Antwort auf ein EHLO hindurchflitzt. Im Ergebnis kann man wieder verschluesselte Mails verschicken. Der ssh-Aufruf muss uebrigens mit Root-Rechten erfolgen, da der gestartete Prozess auf Port 25 Verbindungen annehmen soll. Das geht bekanntermassen nur mit bestimmten Privilegien.
In der Praxis wird es mehr als eine Weiterleitung brauchen -- schliesslich wollen gegebenenfalls ja auch Mails abgeholt werden, die hierzu genutzten Protokolle (z.B. pop3 und imap) laufen aber auf weiteren Ports. Das ist aber kein Problem -- ssh koennen mehrere Weiterleitungen mitgegeben werden. Einfach die naechste dahinterschreiben...

Da ich aber nicht nur einen Rechner habe und ueber einen kleinen Router (siehe auch amd-geode-based-fbsd-router.html) mit dem Internet verbunden bin, kann ich die Tunnelei auch dort abhandeln -- und muss mich so gar nicht mehr mit meinen einzelnen Rechnern in der Sache auseinandersetzen :)
Dazu muss ich nur dafuer sorgen, dass alle Verbindungen, die mein Netz mit dem Ziel mail.gmx.net und dem Zielport 25 verlassen auf einen anderen Port auf meinem Router umgeleitet werden, wo ein ssh-Prozess wartet. Das hat auch den Vorteil, dass die anderen Protokolle nicht angefasst werden und dass ich keine Manipulation an der Domainnamensaufloesung vornehmen muss. Ausserdem muss der Tunnel nicht auf Port 25 bereitstehen. Im Beispiel nehme ich Port 3129 -- auf 3128 lauert bereits ein squid-Proxy, der analog eingebunden ist.
Auf meinem Router werkelt ein kleines ipnat, um meine Rechner ins Netz zu bringen. Um nun oben beschriebene Umleitung hinzubekommen reicht ein

rdr vr0 from any to 139.30.8.210 port=25 -> 192.168.0.1 port 3129 tcp
Vorsicht: Ich habe hier als Beispeil nicht die IP des GMX-Servers sondern des Uni-eigenen Servers eingesetzt. Ansonsten: Kurz und elegant. Nun noch ein entsprechender ssh-Prozess (siehe oben) und schon kann ich wieder auch verschluesselt Mails verschicken.
Kurioserweise mache ich hier etwas, was gar nicht so weit von dem entfernt ist, was umgangen werden soll. Mit ein paar ipnat-Zeilen mehr waere es kein Problem geworden, Verbindungsinhalte zu manipulieren. Mein squid tut sowas zum Beispiel. Indem er eine Handvoll Domains kennt, die er einfach nur blockiert. Darunter Diverses, was mit adserv beginnt...

Zur Situation

Natuerlich habe ich mich mit der Sache an den Sprecher des RSN (nein, Uwe und ich machen das nicht mehr...) als Ansprechpartner fuer die Studenten gewandt. Und auch mit der Bitte um die abschliessende Liste aller Untersuchungen und Manipulationen, denen meine Datenpakete ausgesetzt sind. Ich bekam... nun ja, seit mehr als 4 Monaten keine Antwort auf meine Frage.

Die Kommunikation mit dem beteiligten, nicht genannt werden sollenden, Unternehmen war nicht viel erquicklicher. Traurige Hoehepunkte waren die Fragen, ob ich denn ueber SMTP meine Mails wenigstens abrufen, wenn schon nicht verschicken koenne. Oder die Frage, wo denn email.uni-rostock.de physikalisch stuende.

Einmal mit Profis arbeiten. Was wuerde das Rechenzentrum wohl verlangen, damit es die Administration der ASen wieder uebernimmt?

Stichworte:


Impressum