Utilice el atributo de proxy de Zimbra zimbraReverseProxyMailModepara redirigir las solicitudes web de HTTP a HTTPS. Configúrelo redirecten cada nodo de Zimbra Proxy, reinicie el servicio de proxy y verifique que la respuesta HTTP contenga una Location: https://...cabecera. Antes de hacerlo, asegúrese de que el nombre de host HTTPS público ya se resuelva en su proxy o balanceador de carga y presente un certificado válido.
Esta configuración permite el acceso web a través de Zimbra Proxy. No configura automáticamente el servidor de correo HTTPS, no instala un certificado ni garantiza que todas las aplicaciones de correo sigan una redirección. Si necesita que las solicitudes HTTP se rechacen directamente, considere usar el modo proxy solo HTTPS en lugar de la redirección.
| Modo de correo proxy | ¿Qué sucede con HTTP? | Cuándo usarlo |
|---|---|---|
redirect | El servidor proxy devuelve una respuesta HTTP 302 que dirige al cliente a HTTPS. | Útil cuando las personas aún ingresan una URL HTTP y deben ser redirigidas a la dirección web segura. |
https | El servidor proxy atiende al cliente web a través de HTTPS; no proporciona el mismo flujo de redirección de HTTP a HTTPS. | Prefiera esta opción cuando los clientes nunca deban iniciar una sesión a través de HTTP. |
bothomixed | Se trata de modos de proxy independientes con un comportamiento HTTP/HTTPS diferente. | Úselo solo cuando la implementación requiera específicamente el comportamiento documentado; no asuma que imponen una redirección HTTP. |
Las directrices de seguridad de Zimbra advierten que algunos clientes, incluidos los de ActiveSync, podrían no respetar una redirección HTTP y podrían enviar credenciales en la solicitud inicial sin cifrar. Por lo tanto, la redirección facilita la navegación, pero no sustituye el acceso exclusivamente HTTPS cuando todos los clientes deben evitar HTTP. Si elige el modo de redirección, proteja el receptor HTTP en el perímetro de la red según corresponda y comunique la URL HTTPS a los usuarios.
mail.example.com, debe resolverse en el proxy público o el balanceador de carga. HTTPS debe funcionar correctamente en el nombre de host y puerto esperados.Utilice la cuenta de Zimbra para los comandos administrativos que se muestran a continuación. Reemplace proxy1.example.comcon el nombre exacto del servidor Zimbra de su nodo proxy y reemplace mail.example.comcon el nombre de host público del correo web. No copie los nombres de ejemplo tal cual en un sistema de producción.
En un host Zimbra con las herramientas de línea de comandos disponibles, consulte la configuración actual del proxy:
zmprov gs proxy1.example.com zimbraReverseProxyMailModeRegistra la salida para poder compararla después del cambio o restaurar el modo anterior si es necesario. El gscomando lee los atributos del servidor; msel que se usa a continuación los modifica.
Establezca el atributo en el objeto del servidor proxy:
zmprov ms proxy1.example.com zimbraReverseProxyMailMode redirectLa documentación de configuración de Zimbra Proxy identifica redirecteste modo para redirigir las solicitudes HTTP a HTTPS. Aplique el mismo comando a cada nodo proxy que acepte tráfico web público. Si un balanceador de carga puede enviar una solicitud HTTP a varios proxies, cada proxy elegible debe comportarse de manera consistente.
No confunda esta configuración con zimbraMailMode. Zimbra documenta ese atributo por separado para la conexión del servidor de correo. Cambiar el modo de almacenamiento de correo no es el paso que habilita una redirección HTTP visible en el navegador en el proxy.
redirect; repita con cada nombre de servidor proxy en una implementación de varios nodos.Reinicie el servicio proxy en el nodo donde modificó la configuración:
zmproxyctl restartLuego, verifique su estado de servicio:
zmproxyctl statusReinicia cada nodo proxy, uno a la vez si tienes una capa redundante. Sigue las instrucciones operativas de tu versión de Zimbra instalada si tu entorno tiene un proceso de actualización de caché de configuración o de orquestación de servicios predefinido. Evita editar directamente los archivos Nginx generados: Zimbra gestiona la configuración del proxy desde la configuración de su servidor, y las ediciones manuales pueden sobrescribirse.
Los ejemplos utilizan la Guía de administración de Zimbra Daffodil v10 y la documentación de seguridad y proxy publicada por Zimbra. Las versiones anteriores de ZCS pueden diferir en cuanto al empaquetado o los procedimientos compatibles, por lo que le recomendamos consultar la guía de administración para verificar la versión exacta instalada en su entorno antes de aplicar cualquier cambio.
Desde un sistema que pueda acceder al punto final público, solicite la URL HTTP sin seguir redirecciones:
curl -sS -D - -o /dev/null http://mail.example.com/En modo de redirección, busque una respuesta 302 y un Locationencabezado cuyo valor comience con https://mail.example.com/. Los encabezados exactos y el manejo del estado pueden variar según su versión de Zimbra, ruta y cualquier balanceador de carga o puerta de enlace web que se encuentre delante del proxy. La siguiente captura de pantalla es un ejemplo ilustrativo del patrón de encabezado esperado, no una prueba capturada de un servidor en vivo.
Realice una solicitud por separado a la URL segura:
curl -sS -D - -o /dev/null https://mail.example.com/Confirme que el certificado TLS sea válido para el nombre de host y que la respuesta sea la página de correo web o la redirección de la aplicación esperada. No utilice este método curl -kpara omitir la verificación del certificado, ya que esto ocultaría el problema que los usuarios podrían percibir. Una página de inicio de sesión puede devolver una redirección o un estado distinto de 200, según la versión del producto y el flujo de autenticación; por lo tanto, evalúe la respuesta junto con la comprobación del navegador.
Abra la página http://mail.example.comen una nueva sesión del navegador. La dirección debería cambiar a la URL HTTPS antes de introducir las credenciales. A continuación, abra la URL HTTPS directamente y confirme que la página de inicio de sesión se carga sin ninguna advertencia de certificado. Repita el proceso desde fuera de su red interna si el DNS público, las reglas del cortafuegos o un balanceador de carga pudieran generar resultados diferentes.
No intente introducir una contraseña real mientras la barra de direcciones aún muestre HTTP. Si la redirección falla, deténgase y corrija primero la configuración del proxy, del servidor perimetral o del certificado.
| Síntoma | Qué comprobar |
|---|---|
| HTTP permanece en la misma URL | Consultar zimbraReverseProxyMailModeel proxy que gestionó la solicitud; verificar que cada nodo con balanceo de carga tenga el valor previsto y se haya reiniciado. |
| El encabezado Location utiliza un nombre de host o puerto incorrecto. | Verifique la URL pública, las reglas del proxy inverso o del balanceador de carga, y la configuración del nombre de host, protocolo y puerto del servicio público de Zimbra que se utiliza para generar los enlaces públicos. |
| El navegador informa de una advertencia de certificado. | Verifique que el certificado esté instalado en el punto de terminación TLS, que cubra el nombre de host público y que incluya los certificados de cadena necesarios. |
| Los usuarios ven un bucle de redireccionamiento. | Verifique si el balanceador de carga frontal finaliza TLS pero reenvía HTTP a Zimbra, y confirme que el proxy puede identificar correctamente el protocolo de solicitud externo. Sincronice la configuración de TLS y reenvío en el borde de la red. |
| Un cliente de correo aún envía HTTP | No asuma que el cliente sigue una redirección 302. Prefiera el acceso solo mediante HTTPS para los clientes que nunca deben enviar credenciales a través de HTTP, y configure cada cliente con la URL del servidor HTTPS. |
zimbraReverseProxyMailModeestá configurado redirecten cada nodo proxy aplicable.Location, y una solicitud HTTPS directa valida el certificado.Compara 10 herramientas de escaneo de ping para la detección rápida de redes LAN, el escaneo multiplataforma y la gestión de direcciones IP. Descubre qué puede (y qué no puede) revelarte un escaneo.
Compare seis herramientas de gestión de red para la monitorización del rendimiento, incluyendo la cobertura SNMP, la asignación de mapas, las alertas, los modelos de implementación y las ventajas y desventajas en cuanto a costes.
Compara las mejores aplicaciones de análisis Wi-Fi para Windows, iPhone y Android, incluyendo herramientas para la congestión de canales, la cobertura de la señal, los mapas de calor y la resolución de problemas de red.
Compara siete monitores de ping gratuitos y de código abierto, desde suites de red completas hasta sondas de latencia específicas, y elige el que mejor se adapte a tus necesidades en cuanto a disponibilidad, pérdida de paquetes e historial.
Aprenda qué significa QoS en redes, cómo las marcas DSCP y las colas de tráfico priorizan las aplicaciones de voz, vídeo y empresariales, y qué problemas no puede solucionar la QoS.
Compare siete herramientas de administración de direcciones IP para el descubrimiento de subredes, la coordinación de DNS y DHCP, el inventario de red y la gestión de direcciones IP de código abierto.
Compara software de servidor SFTP fiable para Windows y Linux, incluyendo OpenSSH, Bitvise, SolarWinds y SFTPGo. Encuentra la solución ideal para tus necesidades de seguridad y transferencia de archivos.
Cree un sistema práctico de monitorización de red con una cobertura clara de los dispositivos, métricas de rendimiento útiles, alertas procesables y una comparación de SolarWinds NPM, PRTG y OpManager.
Compare las herramientas de escaneo de red para la detección rápida de dispositivos, escaneos de IP multiplataforma y gestión de direcciones IP (IPAM) empresariales, con orientación sobre cómo adaptar cada opción a su red.
Utilice la opción --traceroute de Nmap para asignar saltos a un host autorizado, comprender la salida de saltos y RTT, y solucionar problemas de respuestas faltantes sin realizar un escaneo excesivo.
