Blog de Amazon Web Services (AWS)

Ejecución de Microsoft Exchange Server en la nube de Amazon Web Services (AWS): distribución uniforme de la carga de trabajo

Por Caio Ribeiro César, Arquitecto de Soluciones na AWS
Daniel Pires, Sr. Technical Account Manager na AWS

 

Microsoft Exchange Server es una solución de mensajería y colaboración que admite buzones, calendarios, cumplimiento de normas y archivado electrónico. Cuando implementamos Microsoft Exchange Server en AWS, podemos escalar ese entorno de acuerdo a la demanda. Esto le ofrece la funcionalidad de Microsoft Exchange Server y la flexibilidad y seguridad de la nube de AWS.

Existen varios motivos por los que los administradores eligen administrar los servidores Exchange en la nube de AWS (EC2), como:

  • Controlar el respaldo y la restauración en la capa de base de datos, junto con el control del respaldo y restauración en la capa de buzón (usuario).
  • Cumplimiento de normas y administración de datos de servidores Exchange, requeridas por empresas de servicios financieros
  • Integración de Exchange EC2 con SES para campañas de marketing con Amazon SES sin necesidad de contratar un servicio externo o una lista negra de correo saliente.
  • Mantener los registros de Mailflow durante intervalos superiores a 90 días.
  • Factores de costo, escalabilidad, implementación y seguridad.

En esta publicación, analizaremos cómo implementar un entorno de Microsoft Exchange Server en la nube de AWS y también cómo distribuir la carga de trabajo de manera uniforme:

 

 

  1. Virtual Private Cloud (VPC): configurado con subredes públicas y privadas en diferentes zonas de disponibilidad. Esto proporcionará la infraestructura de red para su implementación. Siempre que sea posible, se recomienda elegir una tercera zona de disponibilidad para el servidor testigo del recurso compartido de archivos (File Share Witness, Grupo de disponibilidad de base de datos) o para un nodo adicional de Microsoft Exchange Server. El uso de tres zonas de disponibilidad permite la conmutación por error automática de grupos de disponibilidad de bases de datos (DAG) sin necesidad de intervención manual.
  2. Direcciones IP Elásticas (Elastic IPs, EIPs) asociadas a un NAT Gateway saliente de Internet.
  3. En subredes privadas, controladores de dominio de Microsoft Active Directory y como instancias de EC2 basadas en Windows Server como servidores de Microsoft Exchange.
  4. En subredes privadas, Exchange Server Enterprise Edition en cada nodo. Esta arquitectura proporciona redundancia y un testigo de recurso compartido de archivos para garantizar el establecimiento de un quórum. La arquitectura estándar refleja una arquitectura local de dos instancias de Exchange Server, que abarca dos subredes ubicadas en dos zonas de disponibilidad.
  5. Security Groups, para habilitar un flujo seguro de tráfico entre instancias implementadas en la VPC.
  6. Uso de un Network Load Balancer (NLB) con los puertos necesarios liberados a Internet (SMTP, SMTPS y HTTPS).

Dada la configuración de entorno anterior, elegimos un Network Load Balancer (NLB, el cual trabaja en la capa 4 del modelo OSI) porque servirá como un único punto de contacto para los clientes, ya sean servidores externos SMTP, clientes Outlook, retransmisiones SMTP, Outlook Web App, entre diferentes organizaciones de Exchange o incluso Exchange Online.

El NLB distribuirá el tráfico entrante entre los servidores de Microsoft Exchange (utilizando los puertos TCP 25, 587, 443 y 80) para aumentar la disponibilidad del servicio de correo electrónico. Para hacer esto, necesitamos agregar uno o más listeners al NLB.

El agente de listener del NLB atenderá las solicitudes de conexión de clientes SMTP o WEB, utilizando el protocolo configurado y reenviando las solicitudes a un grupo de destino (target group), que en este caso son los servidores Exchange. Cada grupo de destino enruta las solicitudes a uno o más servidores Exchange, utilizando el protocolo TCP y el número de puerto de servicio (SMTP, HTTP).

Comencemos esta publicación con un escenario en el que en nuestra revisión de la arquitectura de Microsoft Exchange Server en AWS, nos encontramos con una falla al acceder a los servicios principales. Por ejemplo, al acceder al Panel de control de Exchange (Exchange Control Panel), la página mostraba una carga lenta hasta que ocurría un timeout.

Nuestra investigación comenzó con una revisión de la configuración realizada por el cliente. No identificamos ningún error de configuración que pueda explicar el comportamiento experimentado.

Por lo tanto, de acuerdo con el aprendizaje pasado, parafraseando lo que escuchamos y leemos:

“Si todo el mundo lo ha mirado (varios equipos diferentes) y nadie ha encontrado nada, toma capturas de red, ya que éstas siempre tendrán información útil” –  los paquetes no mienten J.

Configuración utilizada por el cliente:

 

 

Por lo tanto, comenzamos el trabajo de captura y análisis de datos.

Las capturas de red simultáneas, utilizando Wireshark, se recopilaron en el origen (estación de trabajo que intenta acceder a la consola de administración de Exchange a través del NLB IPv4) y en instancias de EC2 que ejecutan Microsoft Exchange.

 

 

A través de la captura tomada en la fuente (estación de trabajo), pudimos ver:

a. Three-way handshake establecido correctamente para abrir la sesión TCP, entre la estación de trabajo y el NLB:

 

 

b. Siguiendo esto tenemos el HTTP GET:

Frame 179: 589 bytes on wire (4712 bits), 589 bytes captured (4712 bits) on interface \Device\NPF_{90869922-2FCF-4D43-859E-B22588A4FFEF}, id 0
Ethernet II, Src: 0a:9b:53:09:d1:e0 (0a:9b:53:09:d1:e0), Dst: 0a:40:99:38:34:64 (0a:40:99:38:34:64)
Internet Protocol Version 4, Src: 177.72.241.17, Dst: 10.0.6.186
Transmission Control Protocol, Src Port: 38699, Dst Port: 443, Seq: 1, Ack: 1, Len: 523
    Source Port: 38699
    Destination Port: 443
    [Stream index: 24]
    [TCP Segment Len: 523]
    Sequence number: 1    (relative sequence number)
    Sequence number (raw): 1183824636
    [Next sequence number: 524    (relative sequence number)]
    Acknowledgment number: 1    (relative ack number)
    Acknowledgment number (raw): 3011441666
    1000 .... = Header Length: 32 bytes (8)
    Flags: 0x018 (PSH, ACK)
    Window size value: 7
    [Calculated window size: 28672]
    [Window size scaling factor: 4096]
    Checksum: 0x7edd [unverified]
    [Checksum Status: Unverified]
    Urgent pointer: 0
    Options: (12 bytes), No-Operation (NOP), No-Operation (NOP), Timestamps
    [SEQ/ACK analysis]
    [Timestamps]
    TCP payload (523 bytes)
Hypertext Transfer Protocol
    [Expert Info (Warning/Security): Unencrypted HTTP protocol detected over encrypted port, could indicate a dangerous misconfiguration.]
        [Unencrypted HTTP protocol detected over encrypted port, could indicate a dangerous misconfiguration.]
        [Severity level: Warning]
        [Group: Security]
    GET / HTTP/1.1\r\n
        [Expert Info (Chat/Sequence): GET / HTTP/1.1\r\n]
            [GET / HTTP/1.1\r\n]
            [Severity level: Chat]
            [Group: Sequence]
        Request Method: GET
        Request URI: /
        Request Version: HTTP/1.1
    [Full request URI: http://mail.seudominio.com/]
    [HTTP request 1/1]

 

c. Como podemos ver arriba, Wireshark por defecto nos dio una advertencia (warn). Básicamente, significa que el puerto TCP 443 está reservado por la IANA para el transporte de tráfico HTTPS. Cuando Wireshark detecta tráfico no cifrado en este puerto, nos informa porque puede significar un problema de configuración.

Antes de dar la solución al problema anterior, necesitamos comprender el modelo de prácticas recomendadas para implementar Microsoft Exchange Server en AWS.

 

Parte 1 — Prueba del servicio

Para probar el servicio, realizaremos un acceso sencillo a través del navegador a través de la URL configurada para la «Outlook Web App». Esta prueba se realizará con el fin de aislar posibles fallas locales y de seguridad, por ejemplo, un Security Group mal configurado.

a. Confirmación de URL para OWA.

 

 

b. Prueba desde una subred privada utilizando la URL obtenida en el punto anterior.

 

 

c. Prueba desde una subred pública.

 

 

Parte 2 — Configuración de TLS en el Network Load Balancer (Listeners)

Para que la distribución de la carga de trabajo en el entorno Exchange se produzca de manera uniforme y segura, necesitamos configurar el NLB correctamente, utilizando TLS en listeners y target groups.

Para utilizar un listener TLS, debe tener al menos un certificado de servidor (x.509) en el NLB. El NLB utiliza un certificado de servidor para finalizar la conexión front-end y descifrar las solicitudes de los clientes antes de enviarlas a los destinos. Este mismo certificado se puede configurar en servidores de Exchange para servicios externos como IIS y SMTP.

a. En la consola de AWS, ir al servicio EC2. En el menú de la izquierda bajo la sección Equilibrio de carga, seleccionar Balanceadores de carga. Después Create Load Balancer > Network Load Balancer > Create.

 

 

b. Dar un nombre al NLB, seleccionar en Scheme internet-facing, junto con la opción TLS para el listener, usando el puerto 443.

 

 

c. Configurar el NLB en tres subredes públicas. Cada subred de una zona de disponibilidad (AZ) específica. Esto significa que podemos enrutar comunicaciones externas a diferentes servidores Exchange en subredes privadas que existen en las mismas AZ.

 

 

d. Seleccionar el certificado de servidor (certificado público) y la política de seguridad*.

 

* Recomendamos la política ELBSecurityPolicy2016-08 para su compatibilidad.

 

Parte 3 — Configuración de TLS en el grupo de destino

a. Todavía en la misma configuración (Paso 3), podemos crear un nuevo Target group con Target type = instance. Para el protocolo, seleccionamos TLS 443. Para la configuración de Health checks (comprobaciones para determinar si un destino está disponible para procesar las solicitudes), hemos cambiado a utilizar HTTPS en la URL de Outlook Web App.

 

 

b. Seleccionamos los servidores Exchange y los agregamos como destinos:

 

 

c. Seleccionar la opción “Review” y luego “Create”.

d. Confirmar la creación del target group y del NLB con las opciones TLS, junto con la confirmación de que los objetivos registrados están en estado “healthy”:

 

 

e. Publicar el record CNAME en Route53, con el nombre del servicio de correo electrónico “mail.dominio.com” (reemplazar con su dominio de OWA) apuntando al NLB. Route53 ayuda mucho en entornos multi-región para equilibrar la carga en diferentes regiones. Para este ejemplo, sin embargo, utilizamos una política de enrutamiento simple.

 

 

Parte 4 — Prueba del servicio exterior

Para probar el servicio externamente, utilizaremos la dirección “mail.dominio.com” de una estación de trabajo fuera de la VPC de AWS

 

 

Parte 5 — Comportamientos de servicio en entornos TLS en ambas configuraciones

Como podemos ver en la captura a continuación, se observa que el tráfico va cifrado utilizando TLS v1.2.

 

 

Conclusión

En esta publicación, demostramos cómo implementar Microsoft Exchange Server en la nube de AWS mediante un Network Load Balancer para implementar la carga de trabajo de manera uniforme, junto con la configuración necesaria para que no haya problemas de acceso para los servicios web y de mensajería.

Para obtener más información acerca de Microsoft Exchange Server en AWS, visite nuestro QuickStart.

 

Este artículo fue traducido del Blog de AWS en Portugués.

 

Sobre los autores

Caio Ribeiro Cesar actualmente trabaja como arquitecto de soluciones especializado en tecnología de Microsoft en la nube de AWS. Comenzó su carrera profesional como administrador de sistemas, que continuó durante más de 13 años en áreas como seguridad de la información, identidad en línea y plataformas de correo electrónico corporativo. Recientemente se hizo fanático de la computación en la nube de AWS y ayuda a los clientes a aprovechar el poder de la tecnología de Microsoft en AWS.

 

 

 

Daniel Pires actualmente trabaja como Gerente Técnico de Cuentas en Amazon Web Services. Ha trabajado con las tecnologías de Microsoft durante más de 15 años (Active Directory, Hybrid Identity, Microsoft Azure).

 

 

 

 

Revisor

Daniel Bravo es Arquitecto de Soluciones en AWS.