Mailversand scheitert beim Verbindungsaufbau des VPN: die Stufe finden

Ein Timeout, ein TLS-Fehler und eine 5xx-Antwort scheitern auf verschiedenen Stufen. Klassifizieren Sie den Fehler, bestätigen Sie den TLS-Modus des Ports und vergleichen Sie dann Pfade, nicht Passwörter.

Mail, die den ganzen Morgen funktioniert hat, bricht in dem Moment ab, in dem der Tunnel hochkommt, und der erste Reflex ist, das Passwort erneut einzugeben. Dieser Reflex überspringt die nützlichere Frage: Hat der Client den Server überhaupt erreicht, und ist er weit genug gekommen, um Anmeldedaten anzubieten? Ein Timeout, ein Zertifikatsfehler und eine Ablehnungsantwort sind drei verschiedene Fehler, und nur der dritte betrifft das Konto. Gehen Sie die Stufen der Reihe nach durch, und das VPN wird zu einer Variablen, die Sie testen können, statt zu einem Verdächtigen, dem Sie die Schuld geben.

Schritt 1: Klassifizieren Sie den Fehler, bevor Sie Anmeldedaten anfassen

Lesen Sie den Fehler, den die Anwendung tatsächlich erzeugt hat, und ordnen Sie ihn einem von drei Körben zu. Ein Timeout oder ein Verbindungsabbruch bedeutet, dass der TCP-Pfad gescheitert ist; ein TLS- oder Zertifikatsfehler bedeutet, dass der Pfad funktioniert hat und der Handshake nicht; eine SMTP-Antwort mit einem Code bedeutet, dass ein Mailserver geantwortet und eine Entscheidung getroffen hat. Jeder Korb zeigt auf einen anderen Verantwortlichen.

Die Körbe sollten getrennt werden, weil sich die Korrekturen widersprechen. Ein Timeout zu verlängern hilft nichts, wenn der Server den Absender ablehnt, und ein Passwort zu ändern bewirkt nichts, wenn die Route blockiert ist. Ein Antwortcode ist der wertvollste Beweis auf der Liste, weil er belegt, dass die gesamte Transportkette funktioniert hat und das Problem in der Richtlinie oder der Identität liegt. Speichern Sie den genauen Text, einschließlich eines erweiterten Statuscodes, bevor Sie es erneut versuchen.

Halten Sie hier an, wenn Sie den Fehler außerhalb des VPN nicht reproduzieren können. Ein Problem, das in einer Anwendung auf einem Rechner auftritt, ist noch kein Netzwerkproblem.

Schritt 2: Bestätigen Sie den Endpunkt und den TLS-Modus

Die Nachrichteneinlieferung ist ein eigener Dienst und nicht dasselbe wie die Weiterleitung von Server zu Server. Bestätigen Sie Hostname, Port und TLS-Modus anhand der Dokumentation des Anbieters für die Einlieferung, denn ein vertrauter Port, der aus einer anderen Mailkonfiguration entlehnt ist, ist kein Beweis. Port 587 erwartet eine Klartextbegrüßung, gefolgt von STARTTLS, während Port 465 TLS ab dem ersten Byte erwartet.

openssl s_client -connect smtp.example.com:465 -servername smtp.example.com -quiet
openssl s_client -starttls smtp -connect smtp.example.com:587 -servername smtp.example.com -quiet
nc -vz smtp.example.com 587

Die falsche der beiden Prüfungen auszuführen, ist genau der Fehler, den der Client macht, wenn er für den anderen Modus konfiguriert ist. Wenn die Prüfung auf implizites TLS auf 587 hängen bleibt oder die STARTTLS-Prüfung auf 465 scheitert, stimmen Port und Modus nicht überein. Korrigieren Sie den Modus im Client, statt die Zertifikatsprüfung zu deaktivieren, was einen Konfigurationsfehler in eine ungeprüfte Verbindung verwandelt. Die Unterscheidung ist alt genug, um standardisiert zu sein: implizites TLS auf Port 465 ist die Anordnung, die in RFC 8314 beschrieben wird.

Ein Zertifikatsfehler ist hier eine Information und kein Hindernis. Er benennt die Identität, die der Server vorgelegt hat, und die Identität, die der Client erwartet hat, und beide lassen sich beheben, ohne die Verbindung zu schwächen.

Schritt 3: Vergleichen Sie Pfade, ohne das Konto zu ändern

Halten Sie Endpunkt, Konto und Client-Einstellungen konstant und ändern Sie nur den Pfad. Senden Sie einmal mit abgebautem Tunnel und einmal mit aufgebautem Tunnel und notieren Sie die Route und die Quelladresse, die der Server sehen würde. Wenn der Fehler dem Pfad folgt, haben Sie ihn isoliert; wenn er dem Rechner folgt, nicht.

ip route get smtp.example.com
curl -v --ssl-reqd --url smtp://smtp.example.com:587 --user "$SMTP_USER" \
  --mail-from [email protected] --mail-rcpt [email protected] --upload-file msg.txt

Ein voller Tunnel ändert die Quelladresse, die der Anbieter sieht, und manche Anbieter behandeln eine unbekannte Quelle strenger als ein unbekanntes Passwort. Das ist eine Richtlinienentscheidung auf ihrer Seite, und es kann eine Greylist, eine Ratenbegrenzung oder eine Sperre sein. Verallgemeinern Sie nicht von einem Anbieter auf alle und nehmen Sie nicht an, dass eine fehlende NAT-Regel jeden Fehler erklärt. Das curl-Protokoll zeigt, welche Stufe gescheitert ist, auch wenn das eigene Protokoll der Anwendung es nicht tut.

Wenn der Tunnel Internetverkehr tragen soll, müssen sowohl seine Weiterleitung als auch seine Ausgangsrichtlinie dieses Ziel zulassen. Ein Tunnel, der nur private Routen trägt, lässt die Mailverbindung auf dem lokalen Pfad, was ein anderer Vergleich ist.

Schritt 4: Senden Sie eine harmlose Nachricht und notieren Sie die Antwort

Beheben Sie die Stufe, die gescheitert ist, und liefern Sie dann eine harmlose Nachricht über dieselbe Anwendung ein, nicht über eine Webmail-Seite. Sie testen den eigenen Sendepfad der Anwendung, einschließlich ihrer gespeicherten Einstellungen und ihres TLS-Modus. Eine Webmail-Sitzung beweist nichts darüber.

Notieren Sie die Antwort, den Port, den TLS-Modus und den verwendeten Pfad, damit die nächste Person das Ergebnis reproduzieren kann. Ein funktionierender Browser und ein grünes VPN-Symbol sind Beobachtungen über andere Dinge. Wenn die Nachricht ankommt, bleibt die Aufgabe, diese Konfiguration zum Standard für jeden Rechner zu machen, der über dieses Konto sendet.

Die Checkliste ist vollständig, wenn Sie die gescheiterte Stufe, den vom Client verwendeten Port und TLS-Modus, den Pfad der Nachricht und die vom Server zurückgegebene Antwort benennen können. Diese vier Fakten verwandeln ein vages Postausgangsproblem in eine Änderung, die jemand prüfen kann.

Ähnliche Artikel