Verwenden Sie das Zimbra-Proxy-Attribut zimbraReverseProxyMailMode, um Webanfragen von HTTP auf HTTPS umzuleiten. Aktivieren Sie es redirectauf jedem Zimbra-Proxy-Knoten, starten Sie anschließend den Proxy-Dienst neu und überprüfen Sie, ob die HTTP-Antwort einen Location: https://...Header enthält. Stellen Sie vorher sicher, dass der öffentliche HTTPS-Hostname bereits zu Ihrem Proxy oder Load Balancer aufgelöst wird und ein gültiges Zertifikat vorliegt.
Diese Einstellung dient dem Webzugriff über den Zimbra-Proxy. Sie konfiguriert nicht automatisch HTTPS für den Mailstore, installiert kein Zertifikat und garantiert nicht, dass jede E-Mail-Anwendung einer Weiterleitung folgt. Wenn HTTP-Anfragen grundsätzlich abgelehnt werden sollen, verwenden Sie den reinen HTTPS-Proxy-Modus anstelle der Weiterleitung.
| Proxy-Mail-Modus | Was passiert mit HTTP? | Wann man es verwendet |
|---|---|---|
redirect | Der Proxy sendet eine HTTP-302-Antwort zurück, die den Client auf HTTPS weiterleitet. | Nützlich, wenn Benutzer noch eine HTTP-URL eingeben und auf die sichere Webadresse weitergeleitet werden sollen. |
https | Der Proxy bedient den Webclient über HTTPS; er bietet keinen HTTP-zu-HTTPS-Umleitungsablauf. | Diese Option ist vorzuziehen, wenn Clients niemals eine Sitzung über HTTP starten sollen. |
bothodermixed | Dies sind separate Proxy-Modi mit unterschiedlichem HTTP/HTTPS-Verhalten. | Verwenden Sie dieses Verhalten nur, wenn die Bereitstellung das dokumentierte Verhalten ausdrücklich erfordert; gehen Sie nicht davon aus, dass eine HTTP-Weiterleitung erzwungen wird. |
Die Sicherheitshinweise von Zimbra weisen darauf hin, dass einige Clients, darunter ActiveSync-Clients, eine HTTP-Weiterleitung möglicherweise nicht berücksichtigen und Anmeldeinformationen in der ersten unverschlüsselten Anfrage senden könnten. Die Weiterleitung ist daher zwar für den Browserkomfort hilfreich, ersetzt aber nicht den ausschließlichen HTTPS-Zugriff, wenn alle Clients HTTP vermeiden müssen. Wenn Sie den Weiterleitungsmodus wählen, schützen Sie den HTTP-Listener am Netzwerkrand entsprechend und teilen Sie den Benutzern die HTTPS-URL mit.
mail.example.com, muss zum öffentlichen Proxy oder Load Balancer aufgelöst werden. HTTPS muss auf dem erwarteten Hostnamen und Port bereits funktionieren.Verwenden Sie das Zimbra-Konto für die folgenden administrativen Befehle. Ersetzen Sie proxy1.example.com<Zimbra-Servername> durch den genauen Namen Ihres Proxy-Knotens und mail.example.com<Webmail-Hostname> durch den Hostnamen Ihres öffentlichen Webmail-Servers. Kopieren Sie die Beispielnamen nicht unverändert in ein Produktivsystem.
Auf einem Zimbra-Host mit verfügbaren Befehlszeilentools kann die aktuelle Proxy-Einstellung abgefragt werden:
zmprov gs proxy1.example.com zimbraReverseProxyMailModeNotieren Sie die Ausgabe, um sie nach der Änderung vergleichen oder gegebenenfalls den vorherigen Modus wiederherstellen zu können. Der gsBefehl liest Serverattribute; msder unten verwendete Befehl ändert diese.
Setzen Sie das Attribut im Proxy-Server-Objekt:
zmprov ms proxy1.example.com zimbraReverseProxyMailMode redirectDie Zimbra-Proxy-Konfigurationsdokumentation beschreibt redirectden Modus zur Umleitung von HTTP-Anfragen auf HTTPS. Wenden Sie denselben Befehl auf jeden Proxy-Knoten an, der öffentlichen Webverkehr akzeptiert. Wenn ein Load Balancer eine HTTP-Anfrage an mehrere Proxys senden kann, muss sich jeder geeignete Proxy einheitlich verhalten.
Verwechseln Sie diese Einstellung nicht mit zimbraMailModeden Zimbra-Dokumenten, die die Verbindung zum Mailbox-Server separat zuweisen. Das Ändern des Mailstore-Modus ist nicht der Schritt, der eine HTTP-Weiterleitung für den Browser über den Proxy aktiviert.
redirect; wiederholen Sie dies für jeden Proxy-Servernamen in einer Multi-Node-Bereitstellung.Starten Sie den Proxy-Dienst auf dem Knoten neu, auf dem Sie die Einstellung geändert haben:
zmproxyctl restartÜberprüfen Sie anschließend den Servicestatus:
zmproxyctl statusFühren Sie den Neustart auf jedem Proxy-Knoten einzeln durch, falls Sie eine redundante Ebene verwenden. Befolgen Sie die Betriebsanweisungen Ihrer installierten Zimbra-Version, wenn Ihre Umgebung einen vorgeschriebenen Aktualisierungsprozess für den Konfigurationscache oder eine Service-Orchestrierung vorsieht. Vermeiden Sie die direkte Bearbeitung generierter Nginx-Dateien: Zimbra verwaltet die Proxy-Konfiguration über die Servereinstellungen, und manuelle Änderungen können überschrieben werden.
Die Beispiele basieren auf dem Zimbra Daffodil v10-Administratorhandbuch und der veröffentlichten Proxy-/Sicherheitsdokumentation von Zimbra. Ältere ZCS-Versionen können sich hinsichtlich Paketierung oder unterstützter Verfahren unterscheiden. Prüfen Sie daher vor der Anwendung einer Änderung das Administratorhandbuch für die in Ihrer Umgebung installierte Version.
Von einem System aus, das den öffentlichen Endpunkt erreichen kann, fordern Sie die HTTP-URL an, ohne Weiterleitungen zu folgen:
curl -sS -D - -o /dev/null http://mail.example.com/Im Redirect-Modus erwarten Sie eine 302-Antwort und einen LocationHeader, dessen Wert mit „“ beginnt https://mail.example.com/. Die genauen Header und die Statusbehandlung können je nach Zimbra-Version, Pfad und vorgeschaltetem Load Balancer oder Web-Gateway variieren. Der folgende Screenshot zeigt beispielhaft das erwartete Header-Muster und ist kein Testdatensatz von einem Live-Server.
Stellen Sie eine separate Anfrage an die sichere URL:
curl -sS -D - -o /dev/null https://mail.example.com/Prüfen Sie, ob das TLS-Zertifikat für den Hostnamen gültig ist und ob die Antwort die erwartete Webmail-Seite oder Anwendungsweiterleitung ist. Verwenden Sie diese Methode nicht, curl -kum die Zertifikatsprüfung zu umgehen: Dadurch wird das Zertifikatsproblem, das Benutzer bemerken würden, verschleiert. Eine Anmeldeseite kann je nach Produktversion und Authentifizierungsablauf eine Weiterleitung oder einen anderen Status als 200 zurückgeben. Beurteilen Sie daher die Antwort zusammen mit der Browserprüfung.
Öffnen Sie http://mail.example.comeinen neuen Browser. Die Adresse sollte sich vor der Eingabe Ihrer Anmeldedaten auf die HTTPS-URL ändern. Öffnen Sie anschließend die HTTPS-URL direkt und prüfen Sie, ob die Anmeldeseite ohne Zertifikatswarnung geladen wird. Wiederholen Sie den Vorgang von außerhalb Ihres internen Netzwerks, falls öffentliche DNS-Server, Firewall-Regeln oder ein Load Balancer zu abweichenden Ergebnissen führen könnten.
Testen Sie nicht mit einem echten Passwort, solange in der Adressleiste noch HTTP angezeigt wird. Falls die Weiterleitung fehlschlägt, stoppen und korrigieren Sie zuerst die Proxy-, Edge- oder Zertifikatskonfiguration.
| Symptom | Was zu überprüfen ist |
|---|---|
| HTTP bleibt bei derselben URL | Abfrage zimbraReverseProxyMailModedes Proxys, der die Anfrage bearbeitet hat; Überprüfung, ob jeder Load-Balanced-Knoten den beabsichtigten Wert hat und neu gestartet wurde. |
| Der Location-Header verwendet den falschen Hostnamen oder Port. | Überprüfen Sie die öffentliche URL, die Reverse-Proxy- oder Load-Balancer-Regeln sowie die Hostnamen-/Protokoll-/Port-Einstellungen des öffentlichen Zimbra-Dienstes, die zur Generierung öffentlicher Links verwendet werden. |
| Der Browser meldet eine Zertifikatswarnung. | Prüfen Sie, ob das Zertifikat am TLS-Endpunkt installiert ist, den öffentlichen Hostnamen abdeckt und die erforderlichen Zertifikatsketten enthält. |
| Die Nutzer sehen eine Weiterleitungsschleife. | Prüfen Sie, ob ein Frontend-Loadbalancer TLS beendet, HTTP aber an Zimbra weiterleitet, und stellen Sie sicher, dass der Proxy das externe Anfrageprotokoll korrekt erkennt. Passen Sie die TLS- und Weiterleitungskonfiguration am Netzwerkrand an. |
| Ein E-Mail-Client sendet weiterhin HTTP | Gehen Sie nicht davon aus, dass der Client einem 302-Redirect folgt. Bevorzugen Sie den HTTPS-Zugriff für Clients, die niemals Anmeldeinformationen über HTTP senden dürfen, und konfigurieren Sie jeden Client mit der HTTPS-Server-URL. |
zimbraReverseProxyMailModeredirectist auf jedem anwendbaren Proxy-Knoten eingestellt .LocationHeader zurück, und eine direkte HTTPS-Anfrage validiert das Zertifikat.Vergleichen Sie 10 Ping-Sweep-Tools für die schnelle LAN-Erkennung, plattformübergreifende Scans und IP-Adressverwaltung. Erfahren Sie, was ein Sweep liefern kann – und was nicht.
Vergleichen Sie sechs Netzwerkmanagement-Tools für die Leistungsüberwachung, einschließlich SNMP-Abdeckung, Mapping, Warnmeldungen, Bereitstellungsmodelle und Kosten-Nutzen-Verhältnisse.
Vergleichen Sie die besten Wi-Fi-Analyseprogramme für Windows, iPhone und Android, einschließlich Tools für Kanalüberlastung, Signalabdeckung, Heatmaps und Netzwerk-Fehlerbehebung.
Erfahren Sie, was QoS in der Netzwerktechnik bedeutet, wie DSCP-Markierungen und Datenverkehrswarteschlangen Sprach-, Video- und Geschäftsanwendungen priorisieren und was QoS nicht beheben kann.
Vergleichen Sie zuverlässige SFTP-Server-Software für Windows und Linux, darunter OpenSSH, Bitvise, SolarWinds und SFTPGo. Finden Sie die passende Lösung für Ihre Sicherheits- und Dateitransferanforderungen.
Vergleichen Sie 10 Tools zum Scannen und Analysieren drahtloser Netzwerke für Windows, iOS und Android mit klaren Hinweisen zu Wi-Fi-Kanälen, Abdeckungskarten, LAN-Prüfungen und Plattformbeschränkungen.
Erstellen Sie eine praktische Netzwerküberwachung mit klarer Geräteabdeckung, nützlichen Leistungskennzahlen, umsetzbaren Warnmeldungen und einem Vergleich von SolarWinds NPM, PRTG und OpManager.
Vergleichen Sie sieben IP-Adressverwaltungstools für Subnetzerkennung, DNS- und DHCP-Koordination, Netzwerkinventarisierung und Open-Source-IPAM.
Vergleichen Sie Netzwerk-Scanner-Tools für die schnelle Geräteerkennung, plattformübergreifende IP-Scans und Enterprise IPAM mit Hinweisen zur Auswahl der passenden Option für Ihr Netzwerk.
Verwenden Sie die Option --traceroute von Nmap, um Hops einem autorisierten Host zuzuordnen, die Hop- und RTT-Ausgabe zu verstehen und fehlende Antworten zu beheben, ohne übermäßig zu scannen.
