Implementar o ExpressRoute para Microsoft 365

Este artigo aplica-se a Microsoft 365 Enterprise.

O ExpressRoute para Microsoft 365 fornece um caminho de encaminhamento alternativo para muitos serviços do Microsoft 365 com acesso à Internet. A arquitetura do ExpressRoute para Microsoft 365 baseia-se na publicidade de prefixos IP públicos dos serviços do Microsoft 365 que já estão acessíveis através da Internet nos circuitos do ExpressRoute aprovisionados para redistribuição subsequente desses prefixos IP na sua rede. Com o ExpressRoute, ativa efetivamente vários caminhos de encaminhamento diferentes, através da Internet e através do ExpressRoute, para muitos serviços do Microsoft 365. Este estado de encaminhamento na sua rede pode representar uma alteração significativa na forma como a topologia de rede interna foi concebida.

Nota

Não recomendamos o ExpressRoute para o Microsoft 365 porque não fornece o melhor modelo de conectividade para o serviço na maioria das circunstâncias. Como tal, é necessária autorização da Microsoft para utilizar este modelo de conectividade. Analisamos todos os pedidos de clientes e autorizamos o ExpressRoute para o Microsoft 365 apenas nos cenários raros em que é necessário. Leia o guia do ExpressRoute para Microsoft 365 para obter mais informações e, após uma revisão abrangente do documento com as suas equipas de produtividade, rede e segurança, trabalhe com a sua equipa de conta Microsoft para submeter uma exceção, se necessário. As subscrições não autorizadas que tentarem criar filtros de rota para o Microsoft 365 receberão uma mensagem de erro.

Tem de planear cuidadosamente a sua implementação do ExpressRoute para o Microsoft 365 para acomodar as complexidades de rede de ter o encaminhamento disponível através de um circuito dedicado com rotas injetadas na sua rede principal e na Internet. Se você e a sua equipa não realizarem o planeamento e teste detalhados neste guia, existe um risco elevado de ocorrer uma perda intermitente ou total de conectividade aos serviços do Microsoft 365 quando o circuito do ExpressRoute estiver ativado.

Para ter uma implementação bem-sucedida, terá de analisar os seus requisitos de infraestrutura, passar pela avaliação e estrutura detalhadas da rede, planear cuidadosamente a implementação de forma faseada e controlada e criar um plano de validação e teste detalhado. Para um ambiente grande e distribuído, não é incomum ver implementações que se estendem por vários meses. Este guia foi concebido para o ajudar a planear com antecedência.

As grandes implementações bem-sucedidas podem demorar seis meses no planeamento e, muitas vezes, incluem membros da equipa de várias áreas da organização, incluindo redes, administradores de servidores firewall e Proxy, administradores do Microsoft 365, segurança, suporte de utilizadores finais, gestão de projetos e patrocínio executivo. O seu investimento no processo de planeamento reduzirá a probabilidade de ocorrer falhas de implementação, resultando em tempo de inatividade ou numa resolução de problemas complexa e dispendiosa.

Esperamos que os seguintes pré-requisitos sejam concluídos antes de este guia de implementação ser iniciado.

1. Concluiu uma avaliação de rede para determinar se o ExpressRoute é recomendado e aprovado.

2. Selecionou um fornecedor de serviços de rede do ExpressRoute. Encontre detalhes sobre os parceiros do ExpressRoute e as localizações de peering.

3. Já leu e compreendeu a documentação do ExpressRoute e a sua rede interna consegue cumprir os pré-requisitos do ExpressRoute ponto a ponto.

4. A sua equipa leu toda a documentação e documentação pública em , https://aka.ms/erte assistiu à https://aka.ms/expressrouteoffice365série de Formação do Azure ExpressRoute para Microsoft 365 no Canal 9 para compreender os detalhes técnicos críticos, incluindo:

   • As dependências de Internet dos serviços SaaS.

   • Como evitar rotas assimétricas e lidar com encaminhamento complexo.

   • Como incorporar controlos de segurança, disponibilidade e nível de aplicação de perímetro.

Começar por recolher requisitos

Comece por determinar que funcionalidades e serviços planeia adotar na sua organização. Tem de determinar que funcionalidades dos diferentes serviços do Microsoft 365 serão utilizadas e quais as localizações na sua rede que irão alojar as pessoas que utilizam essas funcionalidades. Com o catálogo de cenários, tem de adicionar os atributos de rede de que cada um desses cenários necessita; tais como fluxos de tráfego de rede de entrada e saída e se os pontos finais do Microsoft 365 estão disponíveis através do ExpressRoute ou não.

Para reunir os requisitos da sua organização:

• Cataloge o tráfego de rede de entrada e saída para os serviços do Microsoft 365 que a sua organização está a utilizar. Consulte a página Intervalos de URLs e endereços IP do Microsoft 365 para obter a descrição dos fluxos de que são necessários diferentes cenários do Microsoft 365.

• Reúna a documentação da topologia de rede existente que mostra os detalhes do backbone e topologia internos da WAN, conectividade de sites de satélite, conectividade do utilizador de última milha, encaminhamento para pontos de saída de perímetro de rede e serviços proxy.

  • Identifique pontos finais de serviço de entrada nos diagramas de rede aos quais o Microsoft 365 e outros serviços Microsoft se ligarão, mostrando os caminhos de ligação do ExpressRoute propostos e da Internet.

  • Identifique todas as localizações geográficas do utilizador e a conectividade WAN entre localizações, juntamente com as localizações que têm atualmente uma saída para a Internet e que localizações são propostas para ter uma saída para uma localização de peering do ExpressRoute.

  • Identifique todos os dispositivos edge, como proxies, firewalls, etc., e cataloge a respetiva relação com fluxos que passam pela Internet e pelo ExpressRoute.

  • Documente se os utilizadores finais acederão aos serviços do Microsoft 365 através do Encaminhamento Direto ou do proxy de aplicações indiretos para fluxos da Internet e do ExpressRoute.

• Adicione a localização do seu inquilino e localizações meet-me ao seu diagrama de rede.

• Calcule as características de latência e desempenho de rede esperados e observados das principais localizações dos utilizadores para o Microsoft 365. Tenha em atenção que o Microsoft 365 é um conjunto global e distribuído de serviços e os utilizadores irão ligar-se a localizações que podem ser diferentes da localização do respetivo inquilino. Por este motivo, é recomendado medir e otimizar a latência entre o utilizador e o limite mais próximo da rede global da Microsoft através das ligações ExpressRoute e Internet. Pode utilizar as suas conclusões da avaliação de rede para ajudar nesta tarefa.

• Liste os requisitos de segurança de rede da empresa e de elevada disponibilidade que têm de ser cumpridos com a nova ligação do ExpressRoute. Por exemplo, como é que os utilizadores continuam a obter acesso ao Microsoft 365 em caso de falha do circuito expressRoute ou saída da Internet.

• Documente que fluxos de rede do Microsoft 365 de entrada e saída utilizarão o caminho da Internet e que utilizarão o ExpressRoute. As especificidades das localizações geográficas dos seus utilizadores e os detalhes da topologia de rede no local podem exigir que o plano seja diferente de uma localização de utilizador para outra.

Catalogar o tráfego de rede de saída e de entrada

Para minimizar o encaminhamento e outras complexidades de rede, recomendamos que utilize apenas o ExpressRoute para o Microsoft 365 para os fluxos de tráfego de rede que são necessários para passar por uma ligação dedicada devido a requisitos regulamentares ou como resultado da avaliação da rede. Além disso, recomendamos que teste o âmbito do encaminhamento do ExpressRoute e se aproxime dos fluxos de tráfego de rede de saída e entrada como diferentes e diferentes fases do projeto de implementação. Implementar o ExpressRoute para o Microsoft 365 apenas para fluxos de tráfego de rede iniciados pelo utilizador e deixar fluxos de tráfego de rede de entrada na Internet pode ajudar a controlar o aumento da complexidade topológica e os riscos de introdução de possibilidades de encaminhamento assimétrico adicionais.

O catálogo de tráfego de rede deve conter listagens de todas as ligações de rede de entrada e saída que terá entre a sua rede no local e a Microsoft.

• Os fluxos de tráfego de rede de saída são cenários em que uma ligação é iniciada a partir do seu ambiente no local, como a partir de clientes internos ou servidores, com um destino dos serviços Microsoft. Estas ligações podem ser diretas para o Microsoft 365 ou indiretas, como quando a ligação passa por servidores proxy, firewalls ou outros dispositivos de rede no caminho para o Microsoft 365.

• Os fluxos de tráfego de rede de entrada são cenários em que uma ligação é iniciada a partir da cloud da Microsoft para um anfitrião no local. Normalmente, estas ligações têm de passar por uma firewall e outra infraestrutura de segurança que a política de segurança do cliente necessita para fluxos de origem externa.

Leia a secção Garantir a simetria da rota para determinar que serviços irão enviar tráfego de entrada e procurar a coluna marcada como ExpressRoute para Microsoft 365 no artigo de referência de pontos finais do Microsoft 365 para determinar o resto das informações de conectividade.

Para cada serviço que necessite de uma ligação de saída, deverá descrever a conectividade planeada para o serviço, incluindo encaminhamento de rede, configuração de proxy, inspeção de pacotes e necessidades de largura de banda.

Para cada serviço que necessite de uma ligação de entrada, precisará de algumas informações adicionais. Os servidores na cloud da Microsoft estabelecerão ligações à sua rede no local. Para garantir que as ligações são efetuadas corretamente, deverá descrever todos os aspetos desta conectividade, incluindo; as entradas DNS públicas para os serviços que aceitarão estas ligações de entrada, os endereços IP IPv4 formatados por CIDR, o equipamento ISP envolvido e como o NAT de entrada ou NAT de origem é processado para estas ligações.

As ligações de entrada devem ser revistas independentemente de estarem a ligar-se através da Internet ou do ExpressRoute para garantir que o encaminhamento assimétrico não foi introduzido. Em alguns casos, os pontos finais no local aos quais os serviços do Microsoft 365 iniciam ligações de entrada também poderão ter de ser acedidos por outros serviços Microsoft e não Microsoft. É fundamental que a ativação do encaminhamento do ExpressRoute para estes serviços para fins do Microsoft 365 não interaja com outros cenários. Em muitos casos, os clientes poderão ter de implementar alterações específicas na sua rede interna, como o NAT baseado na origem, para garantir que os fluxos de entrada da Microsoft permanecem simétricos após a ativação do ExpressRoute.

Eis uma amostra do nível de detalhe necessário. Neste caso, o Exchange Híbrido encaminharia para o sistema no local através do ExpressRoute.

Propriedade da ligação	Valor
Direção do tráfego de rede	Entrada
Serviço	Migração Híbrida do Exchange
Ponto final público do Microsoft 365 (origem)	Exchange Online (endereços IP)
Ponto Final Público no Local (destino)	5.5.5.5
Entrada DNS Pública (Internet)	Autodiscover.contoso.com
Este ponto final no local será utilizado por outros serviços Microsoft (não microsoft 365)	Não
Este ponto final no local será utilizado por utilizadores/sistemas na Internet	Sim
Sistemas internos publicados através de pontos finais públicos	Exchange Server função de acesso de cliente (no local) 192.168.101, 192.168.102, 192.168.103
Anúncio IP do ponto final público	Para a Internet: 5.5.0.0/16 para o ExpressRoute: 5.5.5.0/24
Controlos de Segurança/Perímetro	Caminho da Internet: DeviceID_002 caminho do ExpressRoute: DeviceID_003
Elevada Disponibilidade	Ativo/Ativo em 2 circuitos georredundantes/ExpressRoute - Chicago e Dallas
Controlo de simetria de caminho	Método: Caminho da Internet NAT de origem: Ligações de entrada NAT de origem para o caminho do ExpressRoute 192.168.5.5: Ligações NAT de origem para 192.168.1.0 (Chicago) e 192.168.2.0 (Dallas)

Eis um exemplo de um serviço que é apenas de saída:

Propriedade da ligação	Valor
Direção do tráfego de rede	Saída
Serviço	SharePoint
Ponto final no local (origem)	Estação de trabalho do utilizador
Ponto final público do Microsoft 365 (destino)	SharePoint (endereços IP)
Entrada DNS Pública (Internet)	*.sharepoint.com (e mais FQDNs)
Referências da CDN	cdn.sharepointonline.com (e mais FQDNs) – endereços IP mantidos pelos fornecedores de CDN)
Anúncio IP e NAT em utilização	Caminho da Internet/NAT de Origem: 1.1.1.0/24 Caminho do ExpressRoute/NAT de Origem: 1.1.2.0/24 (Chicago) e 1.1.3.0/24 (Dallas)
Método de conectividade	Internet: através do proxy de camada 7 (ficheiro .pac) ExpressRoute: encaminhamento direto (sem proxy)
Controlos de Segurança/Perímetro	Caminho da Internet: DeviceID_002 Caminho do ExpressRoute: DeviceID_003
Elevada Disponibilidade	Caminho da Internet: Saída redundante da Internet Caminho do ExpressRoute: Encaminhamento ativo/ativo de "batata quente" em 2 circuitos georredundantes do ExpressRoute - Chicago e Dallas
Controlo de simetria de caminho	Método: NAT de origem para todas as ligações

O design da topologia de rede com conectividade regional

Depois de compreender os serviços e os respetivos fluxos de tráfego de rede associados, pode criar um diagrama de rede que incorpore estes novos requisitos de conectividade e ilustra as alterações que irá fazer para utilizar o ExpressRoute para o Microsoft 365. O seu diagrama deve incluir:

1. Todas as localizações de utilizador a partir das quais o Microsoft 365 e outros serviços serão acedidos.

2. Todos os pontos de saída da Internet e do ExpressRoute.

3. Todos os dispositivos de saída e de entrada que gerem a conectividade dentro e fora da rede, incluindo routers, firewalls, servidores proxy de aplicações e deteção/prevenção de intrusões.

4. Destinos internos para todo o tráfego de entrada, como servidores ADFS internos que aceitam ligações dos servidores proxy de aplicações Web do ADFS.

5. Catálogo de todas as sub-redes IP que serão anunciadas

6. Identifique cada localização a partir da qual as pessoas acederão ao Microsoft 365 e liste as localizações meet-me que serão utilizadas para o ExpressRoute.

7. As localizações e partes da topologia de rede interna, onde os prefixos IP da Microsoft aprendidos com o ExpressRoute serão aceites, filtrados e propagados para.

8. A topologia de rede deve ilustrar a localização geográfica de cada segmento de rede e como se liga à rede da Microsoft através do ExpressRoute e/ou da Internet.

O diagrama abaixo mostra cada localização onde as pessoas irão utilizar o Microsoft 365, juntamente com os anúncios de encaminhamento de entrada e saída para o Microsoft 365.

Para o tráfego de saída, as pessoas acedem ao Microsoft 365 de uma de três formas:

1. Através de uma localização meet-me em América do Norte para as pessoas na Califórnia.

2. Através de uma localização meet-me na Região Administrativa Especial de Hong Kong para as pessoas na RAE de Hong Kong.

3. Através da internet no Bangladesh, onde há menos pessoas e nenhum circuito do ExpressRoute aprovisionado.

Da mesma forma, o tráfego de rede de entrada do Microsoft 365 devolve de uma de três formas:

1. Através de uma localização meet-me em América do Norte para as pessoas na Califórnia.

2. Através de uma localização meet-me na Região Administrativa Especial de Hong Kong para as pessoas na RAE de Hong Kong.

3. Através da internet no Bangladesh, onde há menos pessoas e nenhum circuito do ExpressRoute aprovisionado.

Determinar a localização meet-me adequada

A seleção de localizações meet-me, que são a localização física onde o circuito do ExpressRoute liga a sua rede à rede da Microsoft, é influenciada pelas localizações a partir das quais as pessoas acederão ao Microsoft 365. Como oferta SaaS, o Microsoft 365 não funciona sob o modelo regional IaaS ou PaaS da mesma forma que o Azure. Em vez disso, o Microsoft 365 é um conjunto distribuído de serviços de colaboração, onde os utilizadores poderão ter de se ligar a pontos finais em vários datacenters e regiões, que podem não estar necessariamente na mesma localização ou região onde o inquilino do utilizador está alojado.

Isto significa que a consideração mais importante que precisa de ter ao selecionar localizações meet-me para o ExpressRoute para o Microsoft 365 é a origem da ligação das pessoas na sua organização. A recomendação geral para uma conectividade ideal do Microsoft 365 é implementar o encaminhamento, para que os pedidos dos utilizadores aos serviços do Microsoft 365 sejam entregues na rede da Microsoft através do caminho de rede mais curto, isto também é frequentemente referido como encaminhamento "batata quente". Por exemplo, se a maioria dos utilizadores do Microsoft 365 estiver numa ou duas localizações, selecionar localizações meet-me que estejam mais próximas da localização desses utilizadores criará a estrutura ideal. Se a sua empresa tiver grandes populações de utilizadores em várias regiões diferentes, poderá considerar ter vários circuitos expressRoute e localizações meet-me. Para algumas das suas localizações de utilizador, o caminho mais curto/ideal para a rede da Microsoft e o Microsoft 365, pode não ser através da WAN interna e dos pontos meet-me do ExpressRoute, mas através da Internet.

Muitas vezes, existem várias localizações meet-me que podem ser selecionadas numa região com relativa proximidade com os seus utilizadores. Preencha a tabela seguinte para orientar as suas decisões.

Localizações planeadas do ExpressRoute meet-me na Califórnia e Nova Iorque

Localização	Número de pessoas	Latência esperada para a rede da Microsoft através da saída da Internet	Latência esperada para a rede da Microsoft através do ExpressRoute
Los Angeles	10,000	~15 ms	~10ms (via Silicon Valley)
Washington DC	15,000	~20ms	~10ms (via Nova Iorque)
Dallas	5,000	~15 ms	~40ms (via Nova Iorque)

Assim que a arquitetura de rede global que mostra a região do Microsoft 365, as localizações meet-me do fornecedor de serviços de rede do ExpressRoute e a quantidade de pessoas por localização tiverem sido desenvolvidas, pode ser utilizada para identificar se é possível efetuar otimizações. Também pode mostrar ligações globais de rede hairpin onde o tráfego encaminha para uma localização distante para obter a localização meet-me. Se for detetado um gancho de cabelo na rede global, este deve ser remediado antes de continuar. Encontre outra localização meet-me ou utilize pontos de saída seletivos da Internet para evitar o gancho de cabelo.

O primeiro diagrama mostra um exemplo de um cliente com duas localizações físicas no América do Norte. Pode ver as informações sobre localizações do office, localizações de inquilinos do Microsoft 365 e várias opções para localizações meet-me do ExpressRoute. Neste exemplo, o cliente selecionou a localização meet-me com base em dois princípios, por ordem:

1. Maior proximidade com as pessoas na sua organização.

2. Mais próximo de um datacenter da Microsoft onde o Microsoft 365 está alojado.

Ao expandir ligeiramente este conceito, o segundo diagrama mostra um exemplo de clientes multinacionais confrontados com informações e tomadas de decisões semelhantes. Este cliente tem um pequeno escritório no Bangladesh com apenas uma pequena equipa de 10 pessoas focada em aumentar a sua pegada na região. Existe uma localização meet-me em Chennai e um datacenter da Microsoft com o Microsoft 365 alojado em Chennai para que uma localização meet-me faça sentido; no entanto, para 10 pessoas, a despesa do circuito extra é pesada. À medida que olha para a sua rede, terá de determinar se a latência envolvida no envio do tráfego de rede através da rede é mais eficaz do que gastar o capital para adquirir outro circuito do ExpressRoute.

Em alternativa, as 10 pessoas no Bangladesh poderão ter um melhor desempenho com o tráfego de rede enviado através da Internet para a rede da Microsoft do que o encaminhamento na sua rede interna, como mostrámos nos diagramas introdutórios e reproduzidos abaixo.

Create o seu plano de implementação do ExpressRoute para Microsoft 365

O seu plano de implementação deve abranger os detalhes técnicos da configuração do ExpressRoute e os detalhes da configuração de todas as outras infraestruturas na sua rede, como o seguinte.

• Planeie os serviços divididos entre o ExpressRoute e a Internet.

• Planeie a largura de banda, a segurança, a elevada disponibilidade e a ativação pós-falha.

• Conceber o encaminhamento de entrada e saída, incluindo otimizações adequadas do caminho de encaminhamento para diferentes localizações

• Decida até que ponto as rotas do ExpressRoute serão anunciadas na sua rede e qual é o mecanismo para os clientes selecionarem o caminho da Internet ou do ExpressRoute; por exemplo, encaminhamento direto ou proxy de aplicações.

• Planeie alterações ao registo DNS, incluindo entradas do Sender Policy Framework .

• Planeie a estratégia NAT, incluindo NAT de origem de saída e entrada.

Planear o encaminhamento com os caminhos de rede da Internet e do ExpressRoute

• Para a implementação inicial, todos os serviços de entrada, como o e-mail de entrada ou a conectividade híbrida, são recomendados para utilizar a Internet.

• Planeie o encaminhamento LAN do cliente do utilizador final, como configurar um ficheiro PAC/WPAD, rota predefinida, servidores proxy e anúncios de rotas BGP.

• Planeie o encaminhamento de perímetro, incluindo servidores proxy, firewalls e proxies de cloud.

Planear a largura de banda, a segurança, a elevada disponibilidade e a ativação pós-falha

Create um plano de largura de banda necessário para cada carga de trabalho principal do Microsoft 365. Calcule separadamente Exchange Online, SharePoint e Skype para Empresas requisitos de largura de banda online. Pode utilizar as calculadoras de estimativas que fornecemos para Exchange Online e Skype para Empresas como ponto de partida. No entanto, é necessário um teste piloto com uma amostra representativa dos perfis de utilizador e localizações para compreender totalmente as necessidades de largura de banda da sua organização.

Adicione a forma como a segurança é processada em cada localização de saída da Internet e do ExpressRoute para o seu plano, lembre-se de que todas as ligações do ExpressRoute ao Microsoft 365 utilizam peering público e ainda têm de ser protegidas de acordo com as políticas de segurança da sua empresa de ligação a redes externas.

Adicione detalhes ao seu plano sobre as pessoas que serão afetadas pelo tipo de indisponibilidade e como essas pessoas poderão realizar o seu trabalho na capacidade máxima da forma mais simples.

Planear requisitos de largura de banda, incluindo requisitos de Skype para Empresas em Nervosismo, Latência, Congestionamento e Espaço principal

O Skype para Empresas Online também tem requisitos de rede adicionais específicos, que são detalhados no artigo Qualidade de Multimédia e Desempenho da Conectividade de Rede no Skype para Empresas Online.

Leia a secção Planeamento da largura de banda do Azure ExpressRoute. Ao realizar uma avaliação de largura de banda com os seus utilizadores piloto, pode utilizar o nosso guia Otimização do desempenho do Microsoft 365 com linhas de base e histórico de desempenho.

Planear os requisitos de elevada disponibilidade

Create um plano de elevada disponibilidade para satisfazer as suas necessidades e incorporá-lo no seu diagrama de topologia de rede atualizado. Leia a secção Elevada disponibilidade e ativação pós-falha com o Azure ExpressRoute.

Planear os requisitos de segurança de rede

Create um plano para cumprir os requisitos de segurança de rede e incorporá-lo no seu diagrama de topologia de rede atualizado. Leia a secção Aplicar controlos de segurança ao Azure ExpressRoute para cenários do Microsoft 365.

Conceber a conectividade do serviço de saída

O ExpressRoute para Microsoft 365 tem requisitos de rede de saída que podem não estar familiarizados. Especificamente, os endereços IP que representam os seus utilizadores e redes para o Microsoft 365 e atuam como pontos finais de origem para ligações de rede de saída à Microsoft têm de seguir requisitos específicos descritos abaixo.

1. Os pontos finais têm de ser endereços IP públicos que estão registados na sua empresa ou para a operadora que lhe fornece conectividade do ExpressRoute.

2. Os pontos finais têm de ser anunciados à Microsoft e validados/aceites pelo ExpressRoute.

3. Os pontos finais não podem ser anunciados na Internet com a mesma ou mais métricas de encaminhamento preferenciais.

4. Os pontos finais não podem ser utilizados para conectividade aos serviços Microsoft que não estão configurados através do ExpressRoute.

Se a sua estrutura de rede não cumprir estes requisitos, existe um risco elevado de os seus utilizadores sofrerem falhas de conectividade ao Microsoft 365 e a outros serviços Microsoft devido à rota de holing preto ou encaminhamento assimétrico. Isto ocorre quando os pedidos aos serviços Microsoft são encaminhados através do ExpressRoute, mas as respostas são encaminhadas pela Internet ou vice-versa e as respostas são removidas por dispositivos de rede com monitorização de estado, como firewalls.

O método mais comum que pode utilizar para cumprir os requisitos acima é utilizar o NAT de origem, implementado como parte da sua rede ou fornecido pela sua operadora do ExpressRoute. O NAT de origem permite-lhe abstrair os detalhes e o endereçamento IP privado da sua rede internet a partir do ExpressRoute e; juntamente com anúncios de rotas IP adequados, fornecem um mecanismo fácil para garantir a simetria do caminho. Se estiver a utilizar dispositivos de rede com monitorização de estado específicos das localizações de peering do ExpressRoute, tem de implementar conjuntos NAT separados para cada peering do ExpressRoute para garantir a simetria do caminho.

Leia mais sobre os requisitos de NAT do ExpressRoute.

Adicione as alterações para a conectividade de saída ao diagrama de topologia de rede.

Conceber a conectividade do serviço de entrada

A maioria das implementações empresariais do Microsoft 365 assume alguma forma de conectividade de entrada do Microsoft 365 para serviços no local, como para o Exchange, SharePoint e Skype para Empresas cenários híbridos, migrações de caixas de correio e autenticação com a infraestrutura do ADFS. Quando o ExpressRoute ativa um caminho de encaminhamento extra entre a sua rede no local e a Microsoft para conectividade de saída, estas ligações de entrada podem ser inadvertidamente afetadas pelo encaminhamento assimétrico, mesmo que pretenda que esses fluxos continuem a utilizar a Internet. São recomendadas algumas precauções descritas abaixo para garantir que não há impacto nos fluxos de entrada baseados na Internet do Microsoft 365 para os sistemas no local.

Para minimizar os riscos de encaminhamento assimétrico para fluxos de tráfego de rede de entrada, todas as ligações de entrada devem utilizar NAT de origem antes de serem encaminhadas para segmentos da sua rede, que têm visibilidade de encaminhamento para o ExpressRoute. Se as ligações de entrada forem permitidas para um segmento de rede com visibilidade de encaminhamento para o ExpressRoute sem NAT de origem, os pedidos provenientes do Microsoft 365 entrarão a partir da Internet, mas a resposta que regressa ao Microsoft 365 preferirá o caminho de rede do ExpressRoute de volta à rede da Microsoft, causando o encaminhamento assimétrico.

Pode considerar um dos seguintes padrões de implementação para satisfazer este requisito:

1. Execute o NAT de origem antes de os pedidos serem encaminhados para a sua rede interna através de equipamentos de rede, como firewalls ou balanceadores de carga no caminho da Internet para os seus sistemas no local.

2. Certifique-se de que as rotas do ExpressRoute não são propagadas para os segmentos de rede onde residem serviços de entrada, como servidores front-end ou sistemas proxy inversos, que lidam com ligações à Internet.

Contabilizar explicitamente estes cenários na sua rede e manter todos os fluxos de tráfego de rede de entrada através da Internet ajuda a minimizar a implementação e o risco operacional de encaminhamento assimétrico.

Podem existir casos em que pode optar por direcionar alguns fluxos de entrada através de ligações do ExpressRoute. Para estes cenários, tenha em conta as seguintes considerações adicionais.

1. O Microsoft 365 só pode visar pontos finais no local que utilizem IPs públicos. Isto significa que, mesmo que o ponto final de entrada no local só esteja exposto ao Microsoft 365 através do ExpressRoute, ainda precisa de ter um IP público associado ao mesmo.

2. Todas as resoluções de nomes DNS que os serviços do Microsoft 365 executam para resolver pontos finais no local ocorrem com o DNS público. Isto significa que tem de registar o FQDN dos pontos finais de serviço de entrada nos mapeamentos de IP na Internet.

3. Para receber ligações de rede de entrada através do ExpressRoute, as sub-redes ip públicas para estes pontos finais têm de ser anunciadas à Microsoft através do ExpressRoute.

4. Avalie cuidadosamente estes fluxos de tráfego de rede de entrada para garantir que são aplicados controlos de rede e segurança adequados de acordo com as políticas de rede e segurança da empresa.

5. Assim que os pontos finais de entrada no local forem anunciados à Microsoft através do ExpressRoute, o ExpressRoute tornar-se-á efetivamente o caminho de encaminhamento preferencial para esses pontos finais para todos os serviços Microsoft, incluindo o Microsoft 365. Isto significa que essas sub-redes de ponto final só devem ser utilizadas para comunicações com serviços do Microsoft 365 e nenhum outro serviço na rede da Microsoft. Caso contrário, a sua estrutura causará um encaminhamento assimétrico em que as ligações de entrada de outros serviços Microsoft preferem encaminhar a entrada através do ExpressRoute, enquanto o caminho de retorno utilizará a Internet.

6. Caso um circuito do ExpressRoute ou uma localização meet-me esteja inativo, terá de garantir que os pontos finais de entrada no local ainda estão disponíveis para aceitar pedidos através de um caminho de rede separado. Isto pode significar a publicidade de sub-redes para esses pontos finais através de vários circuitos do ExpressRoute.

7. Recomendamos que aplique o NAT de origem para todos os fluxos de tráfego de rede de entrada que entram na sua rede através do ExpressRoute, especialmente quando estes fluxos atravessam dispositivos de rede com monitorização de estado, como firewalls.

8. Alguns serviços no local, como o proxy do ADFS ou a Deteção Automática do Exchange, podem receber pedidos de entrada de serviços e utilizadores do Microsoft 365 a partir da Internet. Para estes pedidos, o Microsoft 365 terá como destino o mesmo FQDN que os pedidos de utilizador através da Internet. Permitir ligações de utilizador de entrada da Internet para esses pontos finais no local, ao mesmo tempo que força as ligações do Microsoft 365 a utilizar o ExpressRoute, representa uma complexidade de encaminhamento significativa. Para a grande maioria dos clientes, a implementação de cenários tão complexos através do ExpressRoute não é recomendada devido a considerações operacionais. Este overhead adicional inclui a gestão de riscos de encaminhamento assimétrico e irá exigir que faça uma gestão cuidadosa dos anúncios e políticas de encaminhamento em múltiplas dimensões.

Atualize o plano de topologia de rede para mostrar como evitar rotas assimétricas

Quer evitar o encaminhamento assimétrico para garantir que as pessoas na sua organização podem utilizar o Microsoft 365 de forma totalmente integrada, bem como outros serviços importantes na Internet. Existem duas configurações comuns que os clientes têm que causam o encaminhamento assimétrico. Agora é uma boa altura para rever a configuração de rede que está a planear utilizar e verificar se pode existir um destes cenários de encaminhamento assimétrico.

Para começar, vamos examinar algumas situações diferentes associadas ao seguinte diagrama de rede. Neste diagrama, todos os servidores que recebem pedidos de entrada, como o ADFS ou servidores híbridos no local, estão no datacenter de New Jersey e são anunciados na Internet.

1. Embora a rede de perímetro esteja segura, não existe nenhum NAT de Origem disponível para pedidos recebidos.

2. Os servidores no datacenter de New Jersey conseguem ver as rotas da Internet e do ExpressRoute.

Também temos sugestões sobre como corrigi-las.

Problema 1: ligação da cloud para o local através da Internet

O diagrama seguinte ilustra o caminho de rede assimétrico seguido quando a configuração de rede não fornece NAT para pedidos de entrada da cloud da Microsoft através da Internet.

1. O pedido de entrada do Microsoft 365 obtém o endereço IP do ponto final no local do DNS público e envia o pedido para a sua rede de perímetro.

2. Nesta configuração com falhas, não existe nenhum NAT de Origem configurado ou disponível na rede de perímetro para onde o tráfego é enviado, o que resulta na utilização do endereço IP de origem real como destino de retorno.

• O servidor na sua rede encaminha o tráfego de retorno para o Microsoft 365 através de qualquer ligação de rede do ExpressRoute disponível.

• O resultado é um caminho assimétrico para esse fluxo para o Microsoft 365, o que resulta numa ligação quebrada.

Solução 1a: NAT de Origem

Simplesmente adicionar um NAT de origem ao pedido de entrada resolve esta rede configurada incorretamente. Neste diagrama:

1. O pedido recebido continua a entrar através da rede de perímetro do datacenter de New Jersey. Desta vez, o NAT de Origem está disponível.

2. A resposta do servidor encaminha-a de volta para o IP associado ao NAT de Origem em vez do endereço IP original, o que resulta no retorno da resposta ao longo do mesmo caminho de rede.

Solução 1b: Âmbito da Rota

Em alternativa, pode optar por não permitir que os prefixos BGP do ExpressRoute sejam anunciados, removendo o caminho de rede alternativo para esses computadores. Neste diagrama:

1. O pedido recebido continua a entrar através da rede de perímetro do datacenter de New Jersey. Desta vez, os prefixos anunciados pela Microsoft através do circuito do ExpressRoute não estão disponíveis para o datacenter de New Jersey.

2. A resposta do servidor encaminha-a de volta para o IP associado ao endereço IP original através da única rota disponível, o que resulta na devolução da resposta ao longo do mesmo caminho de rede.

Problema 2: ligação da cloud para o local através do ExpressRoute

O diagrama seguinte ilustra o caminho de rede assimétrico seguido quando a configuração de rede não fornece NAT para pedidos de entrada da cloud da Microsoft através do ExpressRoute.

1. O pedido de entrada do Microsoft 365 obtém o endereço IP do DNS e envia o pedido para a sua rede de perímetro.

2. Nesta configuração com falhas, não existe nenhum NAT de Origem configurado ou disponível na rede de perímetro para onde o tráfego é enviado, o que resulta na utilização do endereço IP de origem real como destino de retorno.

• O computador na sua rede encaminha o tráfego de retorno para o Microsoft 365 através de qualquer ligação de rede do ExpressRoute disponível.

• O resultado é uma ligação assimétrica ao Microsoft 365.

Solução 2: NAT de origem

Simplesmente adicionar um NAT de origem ao pedido de entrada resolve esta rede configurada incorretamente. Neste diagrama:

1. O pedido recebido continua a entrar através da rede de perímetro do datacenter de Nova Iorque. Desta vez, o NAT de Origem está disponível.

2. A resposta do servidor encaminha-a de volta para o IP associado ao NAT de Origem em vez do endereço IP original, o que resulta no retorno da resposta ao longo do mesmo caminho de rede.

Documento a verificar se a estrutura da rede tem simetria de caminho

Neste momento, tem de verificar em papel que o seu plano de implementação oferece simetria de rotas para os diferentes cenários em que irá utilizar o Microsoft 365. Irá identificar a rota de rede específica que se espera que seja efetuada quando uma pessoa utiliza diferentes funcionalidades do serviço. Da rede no local e do encaminhamento WAN, para os dispositivos de perímetro, para o caminho de conectividade; O ExpressRoute ou a Internet e a ligação ao ponto final online.

Terá de o fazer para todos os serviços de rede do Microsoft 365 que foram identificados anteriormente como serviços que a sua organização irá adotar.

Ajuda a fazer este trabalho walk-through de rotas com uma segunda pessoa. Explique-lhes de onde se espera que cada salto de rede obtenha a rota seguinte e certifique-se de que está familiarizado com os caminhos de encaminhamento. Lembre-se de que o ExpressRoute fornecerá sempre uma rota mais confinada para endereços IP do servidor Microsoft, o que lhe dará um custo de rota mais baixo do que uma rota predefinida da Internet.

Estruturar a Configuração de Conectividade do Cliente

Se estiver a utilizar um servidor proxy para tráfego vinculado à Internet, terá de ajustar quaisquer ficheiros de configuração pac ou cliente para garantir que os computadores cliente na sua rede estão corretamente configurados para enviar o tráfego do ExpressRoute que pretende para o Microsoft 365 sem transitar o servidor proxy e que o tráfego restante, incluindo algum tráfego do Microsoft 365, é enviado para o proxy relevante. Leia o nosso guia sobre como gerir pontos finais do Microsoft 365, por exemplo, ficheiros PAC.

Nota

Os pontos finais mudam frequentemente, tantas vezes semanalmente. Só deve efetuar alterações com base nos serviços e funcionalidades que a sua organização adotou para reduzir o número de alterações que terá de efetuar para se manter atualizado. Preste muita atenção à Data Efetiva no feed RSS onde as alterações são anunciadas e um registo é mantido de todas as alterações anteriores, os endereços IP anunciados podem não ser anunciados ou removidos do anúncio, até que a data efetiva seja atingida.

Garantir a simetria da rota

Os servidores front-end do Microsoft 365 estão acessíveis tanto na Internet como no ExpressRoute. Estes servidores preferem encaminhar de volta para o local através dos circuitos do ExpressRoute quando ambos estiverem disponíveis. Por este motivo, existe a possibilidade de assimetria de rota se o tráfego da sua rede preferir encaminhar através dos circuitos da Internet. As rotas assimétricas são um problema porque os dispositivos que realizam uma inspeção de pacotes com monitorização de estado podem bloquear o tráfego de retorno que segue um caminho diferente dos pacotes de saída seguidos.

Independentemente de iniciar uma ligação ao Microsoft 365 através da Internet ou do ExpressRoute, a origem tem de ser um endereço encaminhável publicamente. Com muitos clientes a efetuar o peering diretamente com a Microsoft, não é viável ter endereços privados em que a duplicação seja possível entre os clientes.

Seguem-se cenários em que serão iniciadas comunicações do Microsoft 365 para a sua rede no local. Para simplificar a estrutura da rede, recomendamos que encaminhe o seguinte através do caminho da Internet.

• Serviços SMTP, como correio de um inquilino Exchange Online para um anfitrião no local ou o SharePoint Mail enviado do SharePoint para um anfitrião no local. O protocolo SMTP é utilizado mais amplamente na rede da Microsoft do que os prefixos de rota partilhados através de circuitos expressRoute e a publicidade de servidores SMTP no local através do ExpressRoute causará falhas com estes outros serviços.

• ADFS durante a validação de palavra-passe para iniciar sessão.

• Exchange Server Implementações híbridas.

• Pesquisa híbrida federada do SharePoint.

• BCS híbrido do SharePoint.

• Skype para Empresasfederação híbrida e/ou Skype para Empresas.

• Skype para Empresas Cloud Connector.

Para que a Microsoft regresse à sua rede para estes fluxos de tráfego bidirecionais, as rotas BGP para os seus dispositivos no local têm de ser partilhadas com a Microsoft. Quando anunciar prefixos de rota para a Microsoft através do ExpressRoute, deve seguir estas melhores práticas:

1. Não anuncie o mesmo prefixo de rota de Endereço IP público para a Internet pública e através do ExpressRoute. Recomenda-se que os anúncios do Prefixo de Rota BGP ip para a Microsoft através do ExpressRoute sejam de um intervalo que não é anunciado para a Internet. Se isto não for possível de alcançar devido ao espaço de Endereços IP disponível, é essencial garantir que anuncia um intervalo mais específico através do ExpressRoute do que qualquer circuito de Internet.

2. Utilize conjuntos DE IP NAT separados por circuito do ExpressRoute e separe os dos circuitos da Internet.

3. Qualquer rota anunciada para a Microsoft irá atrair tráfego de rede a partir de qualquer servidor na rede da Microsoft, não apenas aqueles para os quais as rotas são anunciadas para a sua rede através do ExpressRoute. Anuncie apenas rotas para servidores onde os cenários de encaminhamento são definidos e bem compreendidos pela sua equipa. Anuncie prefixos de rota de Endereço IP separados em cada um dos múltiplos circuitos do ExpressRoute da sua rede.

Elevada disponibilidade e ativação pós-falha com o Azure ExpressRoute

Recomendamos o aprovisionamento de, pelo menos, dois circuitos ativos de cada saída com o ExpressRoute para o seu fornecedor do ExpressRoute. Este é o local mais comum onde vemos falhas para os clientes e pode facilmente evitá-lo ao aprovisionar um par de circuitos ativos/ativos do ExpressRoute. Também recomendamos, pelo menos, dois circuitos ativos/ativos da Internet porque muitos serviços do Microsoft 365 só estão disponíveis através da Internet.

Dentro do ponto de saída da sua rede estão muitos outros dispositivos e circuitos que desempenham um papel fundamental na forma como as pessoas percebem a disponibilidade. Estas partes dos seus cenários de conectividade não são abrangidas pelo ExpressRoute ou pelos SLAs do Microsoft 365, mas desempenham um papel fundamental na disponibilidade do serviço ponto a ponto, conforme percebido pelas pessoas na sua organização.

Concentre-se nas pessoas que utilizam e operam o Microsoft 365, se uma falha de qualquer componente afetar a experiência das pessoas que utilizam o serviço, procure formas de limitar a percentagem total de pessoas afetadas. Se um modo de ativação pós-falha for operacionalmente complexo, considere a experiência das pessoas de muito tempo para recuperar e procure modos de ativação pós-falha operacionalmente simples e automatizados.

Fora da sua rede, o Microsoft 365, o ExpressRoute e o seu fornecedor do ExpressRoute têm diferentes níveis de disponibilidade.

Disponibilidade do Serviço

• Os serviços do Microsoft 365 são abrangidos por contratos de nível de serviço bem definidos, que incluem métricas de tempo de atividade e disponibilidade para serviços individuais. Uma das razões pelas quais o Microsoft 365 pode manter níveis de disponibilidade de serviço tão elevados é a capacidade de os componentes individuais realizarem a ativação pós-falha de forma totalmente integrada entre os muitos datacenters da Microsoft, através da rede global da Microsoft. Esta ativação pós-falha expande-se do datacenter e da rede para os vários pontos de saída da Internet e permite a ativação pós-falha de forma totalmente integrada na perspetiva das pessoas que utilizam o serviço.

• O ExpressRoute fornece um SLA de disponibilidade de 99,9% em circuitos dedicados individuais entre o Microsoft Network Edge e o fornecedor do ExpressRoute ou a infraestrutura de parceiros. Estes níveis de serviço são aplicados ao nível do circuito do ExpressRoute, que consiste em duas interligações independentes entre o equipamento redundante da Microsoft e o equipamento do fornecedor de rede em cada localização de peering.

Disponibilidade do Fornecedor

• As disposições de nível de serviço da Microsoft param no seu fornecedor ou parceiro do ExpressRoute. Este é também o primeiro local onde pode fazer escolhas que irão influenciar o seu nível de disponibilidade. Deve avaliar de perto as características de arquitetura, disponibilidade e resiliência que o fornecedor do ExpressRoute oferece entre o perímetro de rede e a ligação dos fornecedores em cada localização de peering da Microsoft. Preste muita atenção aos aspetos lógicos e físicos da redundância, do equipamento de peering, dos circuitos WAN fornecidos pela transportadora e de quaisquer serviços adicionais de valor adicional, como serviços NAT ou firewalls geridas.

Conceber o seu plano de disponibilidade

Recomendamos vivamente que planeie e crie elevada disponibilidade e resiliência nos seus cenários de conectividade ponto a ponto para o Microsoft 365. Uma estrutura deve incluir;

• Não existem pontos únicos de falha, incluindo os circuitos da Internet e do ExpressRoute.

• Minimizar o número de pessoas afetadas e a duração desse impacto para os modos de falha mais esperados.

• Otimizar para um processo de recuperação simples, repetível e automático a partir dos modos de falha mais esperados.

• Suportar todas as exigências do tráfego de rede e da funcionalidade através de caminhos redundantes, sem degradação substancial.

Os cenários de conectividade devem incluir uma topologia de rede otimizada para vários caminhos de rede independentes e ativos para o Microsoft 365. Isto produzirá uma melhor disponibilidade ponto a ponto do que uma topologia otimizada apenas para redundância ao nível do dispositivo ou equipamento individual.

Sugestão

Se os seus utilizadores estiverem distribuídos por vários continentes ou regiões geográficas e cada uma dessas localizações se ligar através de circuitos WAN redundantes a uma única localização no local onde está localizado um único circuito do ExpressRoute, os seus utilizadores terão menos disponibilidade de serviço ponto a ponto do que um design de topologia de rede que inclui circuitos independentes do ExpressRoute que ligam as diferentes regiões à localização de peering mais próxima.

Recomendamos o aprovisionamento de, pelo menos, dois circuitos do ExpressRoute com cada circuito ligado a uma localização de peering geográfico diferente. Deve aprovisionar este par de circuitos ativo-ativo para todas as regiões em que as pessoas irão utilizar a conectividade do ExpressRoute para os serviços do Microsoft 365. Isto permite que cada região permaneça ligada durante um desastre que afeta uma localização principal, como um datacenter ou uma localização de peering. Configurá-los como ativos/ativos permite que o tráfego do utilizador final seja distribuído por vários caminhos de rede. Isto reduz o âmbito das pessoas afetadas durante interrupções do dispositivo ou do equipamento de rede.

Não recomendamos a utilização de um único circuito do ExpressRoute com a Internet como uma cópia de segurança.

Exemplo: Ativação pós-falha e Elevada Disponibilidade

O design multigeográfico da Contoso foi submetido a uma revisão do encaminhamento, da largura de banda, da segurança e agora tem de passar por uma revisão de elevada disponibilidade. A Contoso considera a elevada disponibilidade como abrangendo três categorias; resiliência, fiabilidade e redundância.

A resiliência permite que a Contoso recupere rapidamente de falhas. A fiabilidade permite que a Contoso ofereça um resultado consistente dentro do sistema. A redundância permite que a Contoso se mova entre uma ou mais instâncias espelhadas da infraestrutura.

Em cada configuração de limite, a Contoso tem Firewalls, Proxies e IDS redundantes. Para América do Norte, a Contoso tem uma configuração de limite no datacenter de Dallas e outra configuração edge no datacenter da Virgínia. O equipamento redundante em cada localização oferece resiliência a essa localização.

A configuração de rede na Contoso é criada com base em alguns princípios fundamentais:

• Em cada região geográfica, existem vários circuitos do Azure ExpressRoute.

• Cada circuito numa região pode suportar todo o tráfego de rede nessa região.

• O encaminhamento preferirá claramente um ou outro caminho, consoante a disponibilidade, a localização e assim sucessivamente.

• A ativação pós-falha entre circuitos do Azure ExpressRoute ocorre automaticamente sem configuração ou ação adicional necessária pela Contoso.

• A ativação pós-falha entre circuitos da Internet ocorre automaticamente sem configuração ou ação adicional necessária pela Contoso.

Nesta configuração, com redundância ao nível físico e virtual, a Contoso é capaz de oferecer resiliência local, resiliência regional e resiliência global de forma fiável. A Contoso elegeu esta configuração depois de avaliar um único circuito do Azure ExpressRoute por região, bem como a possibilidade de efetuar a ativação pós-falha para a Internet.

Se a Contoso não conseguiu ter vários circuitos do Azure ExpressRoute por região, encaminhar o tráfego com origem em América do Norte para o circuito do Azure ExpressRoute na Ásia-Pacífico adicionaria um nível inaceitável de latência e a configuração do reencaminhador de DNS necessária adiciona complexidade.

Não é recomendado utilizar a Internet como uma configuração de cópia de segurança. Isto interrompe o princípio de fiabilidade da Contoso, o que resulta numa experiência inconsistente ao utilizar a ligação. Além disso, a configuração manual seria necessária para efetuar a ativação pós-falha, tendo em conta os anúncios BGP que foram configurados, a configuração NAT, a configuração de DNS e a configuração do proxy. Esta complexidade de ativação pós-falha adicionada aumenta o tempo de recuperação e diminui a capacidade de diagnosticar e resolver os passos envolvidos.

Ainda tem dúvidas sobre como planear e implementar a gestão de tráfego ou o Azure ExpressRoute? Leia o resto da nossa documentação de orientação de desempenho e rede ou as FAQ do Azure ExpressRoute.

Aplicar controlos de segurança ao Azure ExpressRoute para cenários do Microsoft 365

Proteger a conectividade do Azure ExpressRoute começa com os mesmos princípios que proteger a conectividade à Internet. Muitos clientes optam por implementar controlos de rede e perímetro ao longo do caminho do ExpressRoute que liga a rede no local ao Microsoft 365 e a outras clouds da Microsoft. Estes controlos podem incluir firewalls, proxies de aplicações, prevenção de fugas de dados, deteção de intrusões, sistemas de prevenção de intrusões, etc. Em muitos casos, os clientes aplicam diferentes níveis de controlos ao tráfego iniciado a partir do local que vai para a Microsoft, em comparação com o tráfego iniciado pela Microsoft que vai para a rede no local do cliente, em comparação com o tráfego iniciado a partir do local que vai para um destino geral da Internet.

Eis alguns exemplos de integração da segurança com o modelo de conectividade do ExpressRoute que escolheu implementar.

Opção de integração do ExpressRoute	Modelo de perímetro de segurança de rede
Colocalizado numa troca na cloud	Instale uma nova infraestrutura de segurança/perímetro existente na instalação de colocalização onde a ligação do ExpressRoute é estabelecida. Utilize a instalação de colocalização exclusivamente para fins de encaminhamento/interligação e ligações de reencaminhamento a partir da instalação de colocalização para a infraestrutura de segurança/perímetro no local.
Ethernet Ponto a Ponto	Termine a ligação Do ExpressRoute Ponto a Ponto na localização existente da infraestrutura de segurança/perímetro no local. Instale uma nova infraestrutura de segurança/perímetro específica do caminho do ExpressRoute e termine a ligação Ponto a Ponto aí.
IPVPN Qualquer a Qualquer	Utilize uma infraestrutura de segurança/perímetro no local existente em todas as localizações que entram na IPVPN utilizada para a conectividade do ExpressRoute para o Microsoft 365. Efetue o hairpin da IPVPN utilizada para o ExpressRoute para o Microsoft 365 para localizações específicas no local designadas para servirem de segurança/perímetro.

Alguns fornecedores de serviços também oferecem funcionalidades de segurança/perímetro geridas como parte das respetivas soluções de integração com o Azure ExpressRoute.

Ao considerar a colocação da topologia das opções de perímetro de rede/segurança utilizadas para o ExpressRoute para ligações do Microsoft 365, seguem-se considerações adicionais

• A profundidade e o tipo de controlos de rede/segurança podem ter impacto no desempenho e escalabilidade da experiência de utilizador do Microsoft 365.

• Os fluxos de saída (no local-Microsoft>) e de entrada (Microsoft> no local) [se ativado] podem ter requisitos diferentes. Estes são provavelmente diferentes de Saída para destinos gerais da Internet.

• Os requisitos do Microsoft 365 para portas/protocolos e sub-redes IP necessárias são os mesmos, quer o tráfego seja encaminhado através do ExpressRoute para o Microsoft 365 ou através da Internet.

• A colocação topológica dos controlos de rede/segurança do cliente determina a rede ponto a ponto final entre o utilizador e o serviço Microsoft 365 e pode ter um impacto substancial na latência da rede e no congestionamento.

• Os clientes são encorajados a conceber a sua topologia de segurança/perímetro para utilização com o ExpressRoute para Microsoft 365, de acordo com as melhores práticas de redundância, elevada disponibilidade e recuperação após desastre.

Eis um exemplo da Contoso que compara as diferentes opções de conectividade do Azure ExpressRoute com os modelos de segurança de perímetro abordados acima.

Exemplo: Proteger o Azure ExpressRoute

A Contoso está a considerar implementar o Azure ExpressRoute e, depois de planear a arquitetura ideal para o ExpressRoute para o Microsoft 365 e, depois de utilizar a documentação de orientação acima para compreender os requisitos de largura de banda, está a determinar o melhor método para proteger o perímetro.

Para a Contoso, uma organização multinacional com localizações em vários continentes, a segurança tem de abranger todos os perímetros. A opção de conectividade ideal para a Contoso é uma ligação multiponto com várias localizações de peering em todo o mundo para atender às necessidades dos seus colaboradores em cada continente. Cada continente inclui circuitos redundantes do Azure ExpressRoute no continente e a segurança tem de abranger todos estes circuitos.

A infraestrutura existente da Contoso é fiável e pode processar o trabalho adicional, como resultado, a Contoso é capaz de utilizar a infraestrutura para o Azure ExpressRoute e segurança de perímetro da Internet. Se não fosse esse o caso, a Contoso poderia optar por comprar mais equipamento para complementar o equipamento existente ou para lidar com um tipo de ligação diferente.

Planeamento da largura de banda do Azure ExpressRoute

Todos os clientes do Microsoft 365 têm necessidades de largura de banda exclusivas consoante o número de pessoas em cada localização, a sua atividade com cada aplicação do Microsoft 365 e outros fatores, como a utilização de equipamentos no local ou híbridos e configurações de segurança de rede.

Ter pouca largura de banda resultará em congestionamento, retransmissões de dados e atrasos imprevisíveis. Ter demasiada largura de banda resultará num custo desnecessário. Numa rede existente, a largura de banda é frequentemente referida em termos da quantidade de espaço disponível no circuito como uma percentagem. Ter 10% de espaço na cabeça provavelmente resultará em congestionamento e ter 80% de espaço em geral significa custos desnecessários. As alocações de destino típicas da sala são de 20% a 50%.

Para encontrar o nível certo de largura de banda, o melhor mecanismo é testar o consumo de rede existente. Esta é a única forma de obter uma verdadeira medida de utilização e necessidade, uma vez que todas as aplicações e configurações de rede são, de certa forma, exclusivas. Ao medir, deverá prestar muita atenção ao consumo total de largura de banda, latência e congestionamento de TCP para compreender as suas necessidades de rede.

Assim que tiver uma linha de base estimada que inclua todas as aplicações de rede, pilote o Microsoft 365 com um pequeno grupo que inclua os diferentes perfis de pessoas na sua organização para determinar a utilização real e utilize as duas medidas para estimar a quantidade de largura de banda necessária para cada localização do escritório. Se existirem problemas de latência ou congestionamento TCP nos testes, poderá ter de aproximar a saída das pessoas que utilizam o Microsoft 365 ou remover a análise intensiva da rede, como a desencriptação/inspeção SSL.

Todas as nossas recomendações sobre o tipo de processamento de rede recomendado aplicam-se aos circuitos do ExpressRoute e da Internet. O mesmo acontece com o resto da documentação de orientação no nosso site de otimização de desempenho.

Criar os procedimentos de implementação e teste

O seu plano de implementação deve incluir testes e planeamento de reversão. Se a implementação não estiver a funcionar conforme esperado, o plano deve ser concebido para afetar o menor número de pessoas antes de os problemas serem detetados. Seguem-se alguns princípios de alto nível que o seu plano deve considerar.

1. Teste o segmento de rede e a integração do serviço de utilizador para minimizar a interrupção.

2. Planeie o teste de rotas com traceroute e ligação TCP a partir de um anfitrião ligado à Internet separado.

3. De preferência, os testes de serviços de entrada e saída devem ser efetuados numa rede de teste isolada com um inquilino de teste do Microsoft 365.

   • Em alternativa, os testes podem ser efetuados numa rede de produção se o cliente ainda não estiver a utilizar o Microsoft 365 ou estiver no piloto.

   • Em alternativa, os testes podem ser realizados durante uma falha de produção que é reservada apenas para teste e monitorização.

   • Em alternativa, os testes podem ser feitos ao verificar as rotas de cada serviço em cada nó de router de camada 3. Esta contingência só deve ser utilizada se não for possível efetuar outros testes, uma vez que a falta de testes físicos apresenta riscos.

Criar os procedimentos de implementação

Os seus procedimentos de implementação devem ser implementados em pequenos grupos de pessoas por fases para permitir testes antes de implementar em grupos de pessoas maiores. Seguem-se várias formas de testar a implementação do ExpressRoute.

1. Configure o ExpressRoute com o peering da Microsoft e faça com que os anúncios de rota sejam reencaminhados para um único anfitrião apenas para fins de teste faseado.

2. Anuncie as rotas para a rede do ExpressRoute para um único segmento de rede no início e expanda os anúncios de rotas por segmento ou região de rede.

3. Se implementar o Microsoft 365 pela primeira vez, utilize a implementação de rede do ExpressRoute como piloto para algumas pessoas.

4. Se utilizar servidores proxy, pode, em alternativa, configurar um ficheiro PAC de teste para direcionar algumas pessoas para o ExpressRoute com testes e comentários antes de adicionar mais.

O seu plano de implementação deve listar cada um dos procedimentos de implementação que têm de ser seguidos ou os comandos que têm de ser utilizados para implementar a configuração de rede. Quando o tempo de indisponibilidade da rede chegar, todas as alterações que estão a ser feitas devem ser do plano de implementação escrito que foi escrito antecipadamente e revisto pelo elemento da rede. Veja a nossa documentação de orientação sobre a configuração técnica do ExpressRoute.

• Atualizar os seus registos TXT SPF se tiver alterado os endereços IP de quaisquer servidores no local que continuem a enviar e-mails.

• Atualizar quaisquer entradas DNS para servidores no local se tiver alterado os endereços IP para acomodar uma nova configuração NAT.

• Certifique-se de que subscreveu o feed RSS para notificações de ponto final do Microsoft 365 para manter quaisquer configurações de encaminhamento ou proxy.

Após a conclusão da implementação do ExpressRoute, os procedimentos no plano de teste devem ser executados. Os resultados de cada procedimento devem ser registados. Tem de incluir procedimentos para reverter para o ambiente de produção original caso os resultados do plano de teste indiquem que a implementação não foi bem-sucedida.

Criar os procedimentos de teste

Os seus procedimentos de teste devem incluir testes para cada serviço de rede de saída e de entrada para o Microsoft 365 que irá utilizar o ExpressRoute e outros que não o farão. Os procedimentos devem incluir testes de cada localização de rede exclusiva, incluindo utilizadores que não estão no local na LAN empresarial.

Alguns exemplos de atividades de teste incluem o seguinte.

1. Faça ping do router no local para o router do operador de rede.

2. Valide se os anúncios de endereços IP do Microsoft 365 e do CRM Online são recebidos pelo router no local.

3. Valide se o NAT de entrada e saída está a funcionar entre o ExpressRoute e a rede interna.

4. Confirme que as rotas para o NAT estão a ser anunciadas a partir do router.

5. Confirme que o ExpressRoute aceitou os prefixos anunciados.

   • Utilize o seguinte cmdlet para verificar os anúncios de peering:

   Get-AzureRmExpressRouteCircuitRouteTable -DevicePath Primary -ExpressRouteCircuitName TestER -ResourceGroupName RG -PeeringType MicrosoftPeering
   

6. Valide se o seu intervalo de NAT IP público não é anunciado à Microsoft através de qualquer outro circuito de Rede da Internet pública ou ExpressRoute, a menos que seja um subconjunto específico de um intervalo maior, como no exemplo anterior.

7. Os circuitos do ExpressRoute são emparelhados e validam que ambas as sessões BGP estão em execução.

8. Configure um único anfitrião no interior do NAT e utilize ping, tracert e tcpping para testar a conectividade no novo circuito ao anfitrião outlook.office365.com. Em alternativa, pode utilizar uma ferramenta como o Wireshark ou o Microsoft Network Monitor 3.4 numa porta espelhada para o MSEE para confirmar que consegue ligar-se ao endereço IP associado ao outlook.office365.com.

9. Testar a funcionalidade ao nível da aplicação para Exchange Online.

• Testar se o Outlook consegue ligar-se a Exchange Online e enviar/receber e-mails.

• Testar o Outlook consegue utilizar o modo online.

• Testar a conectividade do smartphone e a capacidade de envio/receção.

10. Testar a funcionalidade ao nível da aplicação para o SharePoint

• Teste OneDrive para Empresas cliente de sincronização.

• Testar o acesso Web do SharePoint.

11. Testar a funcionalidade ao nível da aplicação para cenários de chamadas Skype para Empresas:

• Participar numa chamada de conferência como utilizador autenticado [convite iniciado pelo utilizador final].

• Convidar o utilizador para uma chamada de conferência [convite enviado a partir do MCU].

• Participe na conferência como utilizador anónimo através da aplicação Web Skype para Empresas.

• Participar na chamada a partir da ligação do PC com fios, telemóvel IP e dispositivo móvel.

• Chamada para utilizador federado o Chamada para Validação RTPC: a chamada é concluída, a qualidade da chamada é aceitável, o tempo de ligação é aceitável.

• Verifique se o estado de presença dos contactos está atualizado para os membros do inquilino e para os utilizadores federados.

Problemas comuns

O encaminhamento assimétrico é o problema de implementação mais comum. Seguem-se algumas origens comuns a procurar:

• Utilizar uma topologia de encaminhamento de rede aberta ou plana sem NAT de origem no local.

• Não utilizar o SNAT para encaminhar para serviços de entrada através das ligações à Internet e ao ExpressRoute.

• Não está a testar os serviços de entrada no ExpressRoute numa rede de teste antes de implementar amplamente.

Implementar a conectividade do ExpressRoute através da sua rede

Teste a sua implementação para um segmento da rede de cada vez, implementando progressivamente a conectividade a diferentes partes da rede com um plano para reverter para cada novo segmento de rede. Se a sua implementação estiver alinhada com uma implementação do Microsoft 365, implemente primeiro para os seus utilizadores piloto do Microsoft 365 e expanda a partir daí.

Primeiro para o teste e, em seguida, para produção:

• Execute os passos de implementação para ativar o ExpressRoute.

• Teste se vê que as rotas de rede são as esperadas.

• Efetue testes em cada serviço de entrada e saída.

• Reverter se detetar algum problema.

Configurar uma ligação de teste ao ExpressRoute com um segmento de rede de teste

Agora que já tem o plano concluído em papel, está na altura de testar em pequena escala. Neste teste, irá estabelecer uma única ligação do ExpressRoute com o Peering da Microsoft a uma sub-rede de teste na sua rede no local. Pode configurar um inquilino do Microsoft 365 de avaliação com conectividade de e para a sub-rede de teste e incluir todos os serviços de saída e de entrada que irá utilizar na produção na sub-rede de teste. Configure o DNS para o segmento de rede de teste e estabeleça todos os serviços de entrada e saída. Execute o seu plano de teste e certifique-se de que está familiarizado com o encaminhamento para cada serviço e a propagação da rota.

Executar os planos de implementação e teste

À medida que conclui os itens descritos acima, verifique as áreas que concluiu e certifique-se de que o utilizador e a sua equipa os analisaram antes de executar os seus planos de implementação e teste.

• Lista de serviços de saída e de entrada envolvidos na alteração da rede.

• Diagrama de arquitetura de rede global a mostrar a saída da Internet e as localizações meet-me do ExpressRoute.

• Diagrama de encaminhamento de rede que demonstra os diferentes caminhos de rede utilizados para cada serviço implementado.

• Um plano de implementação com passos para implementar as alterações e reverter, se necessário.

• Um plano de teste para testar cada serviço do Microsoft 365 e de rede.

• Validação em papel concluída das rotas de produção para serviços de entrada e saída.

• Um teste concluído num segmento de rede de teste, incluindo testes de disponibilidade.

Escolha uma janela de indisponibilidade que seja suficientemente longa para executar todo o plano de implementação e o plano de teste, tem algum tempo disponível para resolução de problemas e tempo para reverter, se necessário.

Atenção

Devido à natureza complexa do encaminhamento através da Internet e do ExpressRoute, recomenda-se que seja adicionado tempo de memória intermédia adicional a esta janela para processar a resolução de problemas de encaminhamento complexo.

Configurar qoS para Skype para Empresas Online

O QoS é necessário para obter os benefícios de voz e reunião para o Skype para Empresas Online. Pode configurar a QoS depois de garantir que a ligação de rede do ExpressRoute não bloqueia nenhum dos seus outros acessos ao serviço do Microsoft 365. A configuração da QoS é descrita no artigo ExpressRoute e QoS no Skype para Empresas Online.

Resolução de problemas da implementação

O primeiro local a observar é nos passos deste guia de implementação. Alguma coisa falhou no seu plano de implementação? Voltar e executar mais pequenos testes de rede, se possível, para replicar o erro e depurá-lo lá.

Identifique que serviços de entrada ou saída falharam durante o teste. Obtenha especificamente os endereços IP e sub-redes para cada um dos serviços que falharam. Continue a percorrer o diagrama de topologia de rede em papel e valide o encaminhamento. Valide especificamente onde o encaminhamento do ExpressRoute é anunciado, Teste esse encaminhamento durante a indisponibilidade, se possível, com rastreios.

Execute o PSPing com um rastreio de rede para cada ponto final do cliente e avalie os endereços IP de origem e de destino para validar se são os esperados. Execute o telnet para qualquer anfitrião de correio que exponha na porta 25 e verifique se o SNAT está a ocultar o endereço IP de origem original, se tal for esperado.

Tenha em atenção que, ao implementar o Microsoft 365 com uma ligação do ExpressRoute, terá de garantir que a configuração de rede do ExpressRoute foi concebida de forma ideal e que também otimou os outros componentes na sua rede, como computadores cliente. Além de utilizar este guia de planeamento para resolver os passos que poderá ter perdido, também escrevemos um plano de resolução de problemas de desempenho para o Microsoft 365 .

Eis uma ligação abreviada que pode utilizar para regressar: https://aka.ms/implementexpressroute365

Tópicos Relacionados

Avaliar a conectividade de rede do Microsoft 365

Azure ExpressRoute para Microsoft 365

Qualidade dos Suportes de Dados e Desempenho da Conectividade de Rede no Skype para Empresas Online

Otimizar a sua rede para o Skype para Empresas Online

ExpressRoute e QoS no Skype para Empresas Online

Fluxo de chamadas com o ExpressRoute

Otimização do desempenho do Microsoft 365 com linhas de base e histórico de desempenho

Plano de resolução de problemas de desempenho do Microsoft 365

Intervalos de URLs e endereços IP do Microsoft 365

Otimização da rede e do desempenho do Microsoft 365