O blog da AWS

Executando o Microsoft Exchange Server na nuvem da Amazon Web Services (AWS) – distribuindo a carga de trabalho uniformemente

Por Caio Ribeiro César e Daniel Pires

 

O Microsoft Exchange Server é uma solução de mensagens e colaboração com suporte para caixas de correio, calendários, conformidade e arquivamento eletrônico. Ao implantar um ambiente do Microsoft Exchange Server na AWS, é possível escalar esse ambiente com base na demanda. Com isso, você obtém a funcionalidade do Microsoft Exchange Server e a flexibilidade e a segurança da nuvem AWS.

Diversos são os motivos que fazem com que os administradores optem pela gerência dos servidores de Exchange na nuvem AWS (EC2), tais como:

  • Controle de backup e restore na camada de banco de dados juntamente com controle de backup e restore na camada de mailbox (usuário).
  • Empresas de serviços financeiros que precisam de compliance e gerência de dados dos servidores Exchange.
  • Integração do Exchange EC2 com SES para campanhas de marketing com Amazon SES sem a necessidade de contratação de um serviço externo ou outbound mail blacklist.
  • Manter os logs de Mailflow para intervalos superiores a 90 dias.
  • Fatores de custo, escalabilidade, deployment e segurança.

Neste post, iremos discutir como implementar um ambiente Microsoft Exchange Server na nuvem AWS e também como distribuir a carga de trabalho de uma maneira uniforme:

 

  1. Virtual Private Cloud (VPC): configurado com sub-redes públicas e privadas em diferentes zonas de disponibilidade. Isso irá fornecer a infraestrutura de rede para a sua implantação. Sempre que possível, recomendamos a escolha de uma terceira zona de disponibilidade para testemunho do compartilhamento de arquivos (Database Availability Group) ou para um nó adicional do Microsoft Exchange Server. O uso de três zonas de disponibilidade permite o failover automático de grupos de disponibilidade de banco de dados (DAGs), sem a necessidade de intervenção manual.
  2. Endereços IP elásticos associados a um NAT Gateway (Internet outbound).
  3. Nas sub-redes privadas, controladores de domínio do Microsoft Active Directory e como instâncias EC2 baseadas no Windows Server como servidores Microsoft Exchange.
  4. Nas sub-redes privadas, Exchange Server Enterprise Edition em cada nó. Essa arquitetura fornece redundância e um File Share Witness para garantir o estabelecimento de um quorum. A arquitetura padrão espelha uma arquitetura local de duas instâncias do Exchange Server, abrangendo duas sub-redes colocadas em duas zonas de disponibilidade.
  5. Grupos de segurança, para permitir o fluxo seguro de tráfego entre as instâncias implantadas no VPC.
  6. A utilização de um Network Load Balancer (NLB) com as portas necessárias liberadas para a internet (SMTP, SMTPS e HTTPS).

Tendo em conta as configurações do ambiente acima, escolhemos o Load Balancer de Rede (NLB, quarta camada do modelo Open Systems Interconnection) pois ele servirá como ponto único de contato para os clientes – sejam eles SMTP servers externos, clientes Outlok, SMTP relays, Outlook Web App, um ambiente entre diferentes organizações do Exchange ou até o Exchange Online.

O Network Load Balancer distribuirá o tráfego de entrada entre os seus servidores Microsoft Exchange (25, 587, 443 e 80) para aumentar a disponibilidade do serviço de e-mail. Para isso, precisamos adicionar um ou mais listeners ao Network Load Balancer.

O listener do Network Load Balancer irá verificar as solicitações de conexão de clientes SMTP ou WEB, utilizando o protocolo e encaminhando as solicitações para um “Target Group” (Exchange Servers). Cada target group roteia as solicitações a um ou mais servidores Exchange, usando o protocolo TCP e o número de porta do serviço (SMTP, HTTP).

Vamos iniciar este post com um cenário em que em nossa análise de arquitetura do Microsoft Exchange Server na AWS, nos deparamos com uma falha para acessar os serviços principais. Por exemplo, ao acessar a console do Exchange (Exchange Control Panel), a página demonstrava um loading demorado (carregando) até apresentar um timeout.

Nossa investigação começou com a revisão das configurações feitas pelo cliente. Não identificamos nenhum erro de configuração que pudesse explicar o comportamente experimentado.

Portanto, conforme aprendizados passados, parafraseando o que ouvimos e lemos:

“If everyone has already looked at it and nobody found a solution, collect packet captures since they´ll always show you something useful” // “Se todo mundo já olhou (várias equipes diferentes) e ninguém achou nada, colete capturas de rede, já que estas sempre terão informações úteis” –  packets don’t lie :)

Configuração sendo utilizada pelo cliente:

Portanto, iniciamos o trabalho de captura e análise de dados.

Capturas de rede simultâneas (via WireShark) foram coletadas na origem (estação de trabalho tentando acessar a console de gerenciamento do Exchange via IPv4 do Network Load Balancer) e nas instâncias EC2 com o Microsoft Exchange em execução.

Através da captura coletada à partir da origem (estação de trabalho), pudemos ver:

a. 3-Way handshake (entre origem e IPv4 do Network Load Balancer):

b. Na sequência temos o GET HTTP:

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. Conforme podemos ver acima, o Wireshark por padrão nos deu um aviso (warn). Basicamente ele quer dizer que a porta TCP 443 foi reservada pela IANA para o transporte de tráfego HTTPS. Quando o Wireshark detecta tráfego não encriptado nessa porta, ele nos informa pois pode significar um problema de configuração.

Antes de darmos a solução para o problema acima, precisamos entender o modelo de melhor prática para a implementação do Microsoft Exchange Server na AWS.

Parte 1 – Testando o serviço

Para o teste do serviço, iremos efetuar um acesso simples através do browser, via  a URL configurada para o “Outlook Web App”. Este teste será feito com o intuito de isolar possíveis falhas locais e de segurança (Security Group).

a. Confirmando a URL para o OWA.

b. Teste via URL, servidor Exchange Server em uma subnet privada.

c. Teste via URL, instância EC2 em uma subnet pública.

Parte 2 – Configurando TLS no Balanceamento de Carga (Listeners)

Para que a distribuição da carga de trabalho no ambiente Exchange ocorra uniformemente de forma segura e confiável, precisamos configurar o balanceamento de carga da forma correta, utilizando o TLS nos listeners e nos target groups.

Para usar um listener TLS, é necessário ter pelo menos um certificado de servidor (x.509) no Load Balancer. O Load Balancer usa um certificado de servidor para encerrar a conexão front-end e para descriptografar solicitações dos clientes antes de enviá-las aos destinos. Este mesmo certificado pode ser configurado nos servidores Exchange para os serviços externos como IIS e SMTP.

a. Selecionamos a opção “Network Load Balancer>Create”

b. Selecionamos um nome para o NLB externo (internet-facing), juntamente com a opção de TLS para o listener.

c. Configuramos o NLB em 3 subnets públicas. Cada subnet em uma Availability Zone (AZ) específica. Isso significa que podemos rotear as comunicações externas para diferentes Exchange Servers em subnets privadas que existem nas mesmas AZs.

d. Selecionamos o server certificate (public certificate) e a Security Policy*.

* Recomendamos a política ELBSecurityPolicy-2016-08 para compatibilidade.

Parte 3 – Configurando TLS no Target group

a. Ainda no mesmo setup (Step 3), podemos criar um novo Target Group com a configuração de instância (EC2). Para o protocolo, selecionamos TLS 443. Para o health check (verificações de integridade ativas e passivas para determinar se um destino está disponível para lidar com solicitações), alteramos para a utilização do HTTPS na URL do Outlook Web App.

b. Selecionamos os servidores Exchange e os adicionamos como targets:

c. Selecionamos a opção “Review” e então “Create”.

d. Confirmamos a criação do Target Group e NLB com as opções de TLS, juntamente com a confirmação que os targets registrados estão com o status “healthy”:

e. Publicamos o CNAME no Route53, com o nome do serviço de email “mail.dominio.com” apontando para o NLB. Interessante ressaltar que este serviço auxilia muito em ambientes multi-geo para balancear a carga em regiões distintas. Para este exemplo, utilizamos uma política de roteamento simples.

Parte 4 – Testando o serviço externamente

Para testarmos o serviço externamente, iremos utilizar o endereço “mail.dominio.com” de uma estação de trabalho fora da VPC AWS

Parte 5 – Comportamentos do serviço em ambientes com TLS em ambas as configurações

Como podemos observar na captura abaixo, temos um trace de uma coleta em que a comunicação ocorre sem problemas via TLS v1.2.

Conclusão

Neste post, nós demonstramos como implementar o Microsoft Exchange Server na nuvem AWS através do uso de um Network Load Balancer para a distruibuição da carga de trabalho de uma maneira uniforme, juntamente com a configuração necessária para que não existam problemas de acesso para os serviços de mensageria e web.

Para mais informações sobre o Microsoft Exchange Server na AWS, acesse o nosso QuickStart.

Sobre os autores

Caio Ribeiro César
Caio atualmente trabalha como arquiteto de soluções especializadas em tecnologia da Microsoft na nuvem AWS. Ele iniciou sua carreira profissional como administrador de sistemas, que continuou por mais de 13 anos em áreas como Segurança da Informação, Identity Online e Plataformas de Email Corporativo. Recentemente, se tornou fã da computação em nuvem da AWS e auxilia os clientes a utilizar o poder da tecnologia da Microsoft na AWS.

 

 

Daniel Pires
Daniel atualmente trabalha como Sr. Technical Account Manager na Amazon Web Services. Ele trabalhou com tecnologias Microsoft por mais de 15 anos (Active Directory, Identidade Híbrida, Microsoft Azure).