Wer seine Dienste hinter einem vorgelagerten Server betreibt, kennt das
Problem: Der eigentliche Dienst sieht als Absender nur noch den Proxy. Für
Protokolle im Netz ist das ein Problem, denn Sperrlisten, Begrenzungen und
Auswertungen brauchen die echte Adresse.
Bei Web-Verkehr löst man das mit einem zusätzlichen Kopf in der Anfrage. Bei
reinem TCP geht das nicht — dort gibt es keine Köpfe. Die Antwort darauf ist das
PROXY-Protokoll: Der Proxy schickt vor allen Nutzdaten eine kurze Zeile, in der
steht, von wem die Verbindung ursprünglich kam. Der Dienst liest diese Zeile
zuerst und behandelt alles Weitere als normalen Verkehr.
Die stillschweigende Voraussetzung
Das funktioniert, solange der Client zuerst spricht. Bei
verschlüsseltem Web-Verkehr ist das so: Der Browser eröffnet mit seinem
Aushandlungspaket. Der Proxy stellt seine Zeile davor, der Dienst liest sie und
findet dahinter die erwarteten Daten.
Es gibt aber Protokolle, bei denen der Server zuerst spricht.
Klassisch ist der Mailversand über den Port, der mit unverschlüsselter Verbindung
beginnt und erst auf Zuruf umschaltet. Dort meldet sich der Server mit einer
Begrüßungszeile, und der Client wartet auf sie, bevor er irgendetwas sendet.
Der Stillstand
Setzt man das PROXY-Protokoll auf so einen Port, entsteht eine Umklammerung.
Der Dienst wartet auf die Kopfzeile des Proxys, bevor er den Begrüßungstext
schickt. Der Client wartet auf den Begrüßungstext, bevor er etwas sendet. Kommt
die Verbindung von einem Client, der die Kopfzeile nicht kennt — jedes normale
Mailprogramm —, warten beide, bis eine Zeitüberschreitung die Sache beendet.
Das Tückische daran: Es sieht nicht nach einem Konfigurationsfehler aus,
sondern nach einem Netzproblem. Keine Fehlermeldung, kein abgelehnter
Verbindungsaufbau. Die Verbindung steht, es passiert nur nichts. Wer an dieser
Stelle die Firewall prüft, sucht lange.
Was ich daraus gemacht habe
Der Port mit sofortiger Verschlüsselung ist der primäre Sendeweg. Dort
spricht der Client zuerst, dort funktioniert das PROXY-Protokoll, dort kommt die
echte Absenderadresse an.
Der Port mit nachträglicher Umschaltung läuft bewusst ohne. Er bleibt
erreichbar, der Dienst sieht dort eben nur den Proxy. Das ist verschmerzbar,
solange die Auswertung am anderen Port hängt.
Wichtig ist, dass beide Seiten dieselbe Annahme haben. Schickt der Proxy die
Kopfzeile, obwohl der Dienst sie nicht erwartet, landet sie als Müll im
Protokollverkehr — und die Fehlersuche beginnt von vorn, nur mit umgekehrten
Vorzeichen.
Die allgemeine Regel
Bevor man einem Port ein Vorspann-Protokoll verpasst, lohnt eine einzige
Frage: Wer spricht zuerst? Spricht der Client, kann man ihm
etwas voranstellen. Spricht der Server, kann man es nicht — jedenfalls nicht,
ohne dass beide Seiten es wissen.
Dieselbe Frage erklärt eine ganze Familie von Fehlern, bei denen eine
Verbindung steht und trotzdem nichts geschieht.