Gerenciando os pontos de extremidade do Microsoft 365
A maioria das organizações empresariais que têm várias localizações de escritório e uma WAN de ligação precisam de configuração para a conectividade de rede do Microsoft 365. Pode otimizar a sua rede ao enviar todos os pedidos de rede fidedignos do Microsoft 365 diretamente através da firewall, ignorando toda a inspeção ou processamento adicional ao nível do pacote. Isso reduz a latência e os seus requisitos de capacidade de perímetro. Identificar o tráfego de rede do Microsoft 365 é o primeiro passo para proporcionar um desempenho ideal aos seus utilizadores. Para obter mais informações, veja Princípios de Conectividade de Rede do Microsoft 365.
A Microsoft recomenda que aceda aos pontos finais de rede do Microsoft 365 e às alterações contínuas aos mesmos através do Serviço Web de URL e Endereço IP do Microsoft 365.
Independentemente da forma como gere o tráfego de rede vital do Microsoft 365, o Microsoft 365 requer conectividade à Internet. Outros pontos finais de rede onde a conectividade é necessária estão listados em Pontos finais adicionais não incluídos no Serviço Web de URL e Endereço IP do Microsoft 365.
A forma como utiliza os pontos finais de rede do Microsoft 365 depende da arquitetura de rede da sua organização empresarial. Este artigo descreve várias formas de integração de arquiteturas de rede empresarial com endereços IP e URLs do Microsoft 365. A forma mais fácil de escolher que pedidos de rede confiar é utilizar dispositivos SD-WAN que suportam a configuração automatizada do Microsoft 365 em cada uma das suas localizações do escritório.
SD-WAN para saída de ramo local do tráfego de rede vital do Microsoft 365
Em cada localização da sucursal, pode fornecer um dispositivo SD-WAN configurado para encaminhar o tráfego para a categoria de pontos finais Otimizar do Microsoft 365 ou Otimizar e Permitir categorias diretamente para a rede da Microsoft. Outro tráfego de rede, incluindo tráfego de datacenter no local, tráfego geral de sites da Internet e tráfego para pontos finais de categoria predefinidos do Microsoft 365 é enviado para outra localização onde tem um perímetro de rede mais substancial.
A Microsoft está a trabalhar com fornecedores de SD-WAN para ativar a configuração automatizada. Para obter mais informações, consulte Microsoft 365 Programa de Parceiros de Redes.
Utilizar um ficheiro PAC para encaminhamento direto de tráfego vital do Microsoft 365
Utilize ficheiros PAC ou WPAD para gerir pedidos de rede associados ao Microsoft 365, mas que não têm um endereço IP. Normalmente, solicitações de rede que são enviadas por meio de um dispositivo de proxy ou perímetro aumentam a latência. Enquanto a Interrupção do TLS e a Inspeção criam a maior latência, outros serviços, como a autenticação de proxy e a pesquisa de reputação, podem causar um mau desempenho e uma má experiência de utilizador. Além disso, esses dispositivos de perímetro de rede precisam de capacidade suficiente para processar todas as solicitações de conexão de rede. Recomendamos que ignore os seus dispositivos de proxy ou inspeção para pedidos de rede diretos do Microsoft 365.
Galeria do PowerShell Get-PacFile é um script do PowerShell que lê os pontos finais de rede mais recentes do serviço Web de Endereços IP e URL do Microsoft 365 e cria um ficheiro PAC de exemplo. Você pode modificar o script para que ele seja integrado ao gerenciamento de arquivos de PAC existente.
Observação
Para obter mais informações sobre as considerações de segurança e desempenho da conectividade direta aos pontos finais do Microsoft 365, consulte Princípios de Conectividade de Rede do Microsoft 365.
Figura 1: perímetro de rede corporativa simples
O arquivo PAC é implantado em navegadores da Web, no ponto 1, na Figura 1. Ao utilizar um ficheiro PAC para uma saída direta do tráfego de rede vital do Microsoft 365, também tem de permitir a conectividade aos endereços IP por trás destes URLs na firewall de perímetro de rede. Isto é feito ao obter os endereços IP para as mesmas categorias de ponto final do Microsoft 365, conforme especificado no ficheiro PAC e ao criar ACLs de firewall com base nesses endereços. O firewall é o ponto 3 na Figura 1.
Separadamente, se optar por efetuar apenas o encaminhamento direto para os pontos finais da categoria Otimizar, todos os pontos finais da categoria Permitir necessários que envie para o servidor proxy têm de ser listados no servidor proxy para ignorar o processamento adicional. Por exemplo, a quebra TLS e a Inspeção e a Autenticação de Proxy são incompatíveis com os pontos finais de categoria Otimizar e Permitir. O servidor proxy é o ponto 2 na Figura 1.
A configuração comum é permitir sem processar todo o tráfego de saída do servidor proxy para os endereços IP de destino para o tráfego de rede do Microsoft 365 que atinge o servidor proxy. Para obter informações sobre problemas com a Interrupção do TLS e a Inspeção, consulte Utilizar dispositivos ou soluções de rede de terceiros no tráfego do Microsoft 365.
Existem dois tipos de ficheiros PAC que o script Get-PacFile gera.
Tipo | Descrição |
---|---|
1 |
Enviar Otimizar o tráfego de ponto de extremidade direto e todo o conteúdo restante para o servidor proxy. |
2 |
Enviar Otimizar e Permitir o tráfego de ponto de extremidade direto e todo o conteúdo restante para o servidor proxy. Este tipo também pode ser utilizado para enviar todo o ExpressRoute suportado para o tráfego do Microsoft 365 para segmentos de rede do ExpressRoute e tudo o resto para o servidor proxy. |
Veja um exemplo simples de como chamar o script do PowerShell:
Get-PacFile -ClientRequestId b10c5ed1-bad1-445f-b386-b919946339a7
Existem muitos parâmetros que pode transmitir para o script:
Parâmetro | Descrição |
---|---|
ClientRequestId |
Isso é obrigatório e é uma GUID passada para o serviço Web que representa o computador cliente que faz a chamada. |
Instance |
A instância de serviço do Microsoft 365, que é predefinida como Global. Isto também é transmitido para o serviço Web. |
TenantName |
O seu nome de inquilino do Microsoft 365. Transmitido para o serviço Web e utilizado como parâmetro substituível em alguns URLs do Microsoft 365. |
Type |
O tipo de Arquivo PAC de proxy que você deseja gerar. |
Eis outro exemplo de como chamar o script do PowerShell com mais parâmetros:
Get-PacFile -Type 2 -Instance Worldwide -TenantName Contoso -ClientRequestId b10c5ed1-bad1-445f-b386-b919946339a7
O servidor proxy ignora o processamento do tráfego de rede do Microsoft 365
Quando os ficheiros PAC não são utilizados para o tráfego de saída direto, continua a querer ignorar o processamento no perímetro da rede ao configurar o servidor proxy. Alguns fornecedores de servidores proxy ativaram a configuração automatizada, conforme descrito no microsoft 365 Programa de Parceiros de Redes.
Se o fizer manualmente, terá de obter os dados da categoria Otimizar e Permitir ponto final do Serviço Web de Endereços IP e URL do Microsoft 365 e configurar o servidor proxy para ignorar o processamento. É importante evitar a Interrupção do TLS e Inspecionar e Autenticação de Proxy para os pontos finais da categoria Otimizar e Permitir.
Gestão de alterações para endereços IP e URLs do Microsoft 365
Além de selecionar a configuração adequada para o perímetro de rede, é fundamental que adote um processo de gestão de alterações para pontos finais do Microsoft 365. Estes pontos finais mudam regularmente. Se não gerir as alterações, pode acabar com os utilizadores bloqueados ou com fraco desempenho após a adição de um novo endereço IP ou URL.
Normalmente, as alterações aos endereços IP e URLs do Microsoft 365 são publicadas perto do último dia de cada mês. Por vezes, uma alteração é publicada fora desse agendamento devido a requisitos operacionais, de suporte ou de segurança.
Quando é publicada uma alteração que exige que aja porque foi adicionado um endereço IP ou URL, deverá receber um aviso prévio de 30 dias a partir do momento em que publicarmos a alteração até existir um serviço do Microsoft 365 nesse ponto final. Isto reflete-se como a Data Efetiva. Embora tenhamos como objetivo este período de notificação, poderá nem sempre ser possível devido a requisitos operacionais, de suporte ou de segurança. As alterações que não requerem uma ação imediata para manter a conectividade, como endereços IP ou URLs removidos ou alterações menos significativas, não incluem notificação antecipada. Nestes casos, não é fornecida nenhuma Data Efetiva. Independentemente da notificação que é fornecida, listamos a data de ativação do serviço esperada para cada alteração.
Alterar notificação usando o serviço Web
Pode utilizar o Endereço IP e o Serviço Web de URL do Microsoft 365 para receber a notificação de alteração. Recomendamos que chame o método Web /version uma vez por hora para marcar a versão dos pontos finais que está a utilizar para ligar ao Microsoft 365. Se essa versão mudar quando comparada à versão que você está usando, você deverá obter os dados mais recentes do ponto de extremidade do método web /endpoints e, opcionalmente, obter as diferenças entre o método web /changes. Não é necessário chamar os métodos Web /endpoints ou /changes se não tiver havido qualquer alteração à versão que encontrou.
Para obter mais informações, veja Endereço IP e Serviço Web de URL do Microsoft 365.
Alterar notificação usando o serviço Web
O Endereço IP e o Serviço Web de URL do Microsoft 365 fornecem um feed RSS que pode subscrever no Outlook. Existem ligações para os URLs de RSS em cada uma das páginas específicas da instância de serviço do Microsoft 365 para os endereços IP e URLs. Para obter mais informações, veja Endereço IP e Serviço Web de URL do Microsoft 365.
Alterar notificação e revisão de aprovação usando o Power Automate
Entendemos que você ainda pode exigir o processamento manual de alterações dos ponto de extremidade de rede que acontecem todo mês. Pode utilizar o Power Automate para criar um fluxo que o notifica por e-mail e, opcionalmente, executa um processo de aprovação para alterações quando os pontos finais de rede do Microsoft 365 têm alterações. Depois de concluir a revisão, você pode fazer com que o fluxo envie automaticamente por email as alterações para o seu firewall e sua equipe de gerenciamento do servidor proxy.
Para obter informações sobre um exemplo e modelo do Power Automate, veja Utilizar o Power Automate para receber um e-mail para obter alterações a endereços IP e URLs do Microsoft 365.
FAQ sobre pontos finais de rede do Microsoft 365
Veja estas perguntas mais frequentes sobre a conectividade de rede do Microsoft 365.
Como enviar uma pergunta?
Selecione a ligação na parte inferior para indicar se o artigo foi útil ou não e submeta mais perguntas. Monitoramos os comentários e atualizamos as perguntas com os questionamentos mais frequentes.
Como determinar o local do meu locatário?
O local do locatário é determinado da melhor forma usando nosso mapa de datacenters.
Estou me emparelhando adequadamente com a Microsoft?
Locais de emparelhamento são descritos em mais detalhes em emparelhamento com a Microsoft.
Com mais de 2.500 relações de emparelhamento de ISP globalmente e 70 pontos de presença, a passagem de sua rede para a nossa deve ser perfeita. Não custa nada gastar alguns minutos garantindo que a relação de emparelhamento de seu ISP seja ideal. Veja alguns exemplos de entregas de emparelhamento boas e não tão boas para nossa rede.
Não vejo as solicitações de rede para os endereços IP na lista publicada, eu preciso fornecer acesso a eles?
Apenas fornecemos endereços IP para os servidores do Microsoft 365 para os quais deve encaminhar diretamente. Essa não é uma lista abrangente de todos os endereços IP para os quais você verá solicitações de rede. Verá pedidos de rede à Microsoft e endereços IP de terceiros, não publicados. Esses endereços IP são gerados dinamicamente ou gerenciados de maneira a impedir o aviso em tempo hábil quando eles mudam. Se o firewall não permitir o acesso com base em FQDNs para essas solicitações de rede, use um arquivo PAC ou WPAD para gerenciar as solicitações.
Consulte um IP associado ao Microsoft 365 sobre o qual pretende obter mais informações?
- Verifique se o endereço IP está incluído em um intervalo publicado maior usando uma calculadora CIDR como essas para o IPv4ouIPv6. Por exemplo, 40.96.0.0/13 inclui o endereço IP 40.103.0.1 apesar de 40.96 não corresponder a 40.103.
- Ver se um parceiro é responsável pelo IP com uma consulta whois. Se for propriedade da Microsoft, poderá ser um parceiro interno. Muitos pontos finais de rede de parceiros estão listados como pertencentes à categoria predefinida , para a qual os endereços IP não são publicados.
- O endereço IP pode não fazer parte do Microsoft 365 ou de uma dependência. A publicação de pontos finais de rede do Microsoft 365 não inclui todos os pontos finais de rede da Microsoft.
- Verifique o certificado. Com um browser, ligue-se ao endereço IP com
https://<IP_address>
e marcar os domínios listados no certificado para compreender que domínios estão associados ao endereço IP. Se for um endereço IP da Microsoft e não estiver na lista de endereços IP do Microsoft 365, é provável que o endereço IP esteja associado a uma CDN da Microsoft, como MSOCDN.NET ou outro domínio da Microsoft sem informações de IP publicadas. Se você descobrir que o domínio do certificado é um domínio onde podemos solicitar que seja listado o endereço IP, informe-nos.
Alguns URLs do Microsoft 365 apontam para registos CNAME em vez de registos A no DNS. O que preciso fazer com os registros CNAME?
Os computadores cliente precisam de um registo DNS A ou AAAA que inclua um ou mais endereços IP para ligar a um serviço cloud. Alguns URLs incluídos no Microsoft 365 mostram registos CNAME em vez de registos A ou AAAA. Estes registos CNAME são intermediários e podem existir vários numa cadeia. Acabarão sempre por resolve a um registo A ou AAAA para um Endereço IP. Por exemplo, considere a seguinte série de registos DNS, que, em última análise, resolve ao endereço IP IP_1:
serviceA.office.com -> CNAME: serviceA.domainA.com -> CNAME: serviceA.domainB.com -> A: IP_1
Esses redirecionamentos CNAME são uma parte normal do DNS e são transparentes para o computador cliente e transparentes para os servidores proxy. São utilizados para balanceamento de carga, redes de entrega de conteúdos, elevada disponibilidade e mitigação de incidentes de serviço. A Microsoft não publica os registos CNAME intermediários, estão sujeitos a alterações em qualquer altura e não deve ter de os configurar conforme permitido no servidor proxy.
Um servidor proxy valida o URL inicial, que no exemplo acima é serviceA.office.com e este URL seria incluído na publicação do Microsoft 365. O servidor proxy pede a resolução de DNS desse URL para um Endereço IP e recebe novamente IP_1. Não valida os registos de redirecionamento CNAME intermediários.
As configurações hard-coded ou a utilização de uma lista de permissões baseada em FQDNs indiretos do Microsoft 365 não são recomendadas e não são suportadas pela Microsoft. Sabe-se que causam problemas de conectividade do cliente. As soluções DNS que bloqueiam o redirecionamento CNAME ou que, de outra forma, resolve incorretamente entradas DNS do Microsoft 365, podem ser resolvidas através de reencaminhadores DNS com a recursão DNS ativada ou através de sugestões de raiz DNS. Muitos produtos de perímetro de rede de terceiros integram nativamente o ponto final recomendado do Microsoft 365 para incluir uma lista de permissões na respetiva configuração através do Serviço Web de URL e Endereço IP do Microsoft 365.
Por que vejo nomes como nsatc.net ou akadns.net em nomes de domínio da Microsoft?
O Microsoft 365 e outros serviços Microsoft utilizam vários serviços de terceiros, como o Akamai e o MarkMonitor, para melhorar a sua experiência do Microsoft 365. Para continuar a dar-lhe a melhor experiência possível, poderemos alterar estes serviços no futuro. Os domínios de terceiros podem alojar conteúdo, como uma CDN, ou podem alojar um serviço, como um serviço de gestão de tráfego geográfico. Alguns dos serviços em uso no momento incluem:
O MarkMonitor está a ser utilizado quando vê pedidos que incluem *.nsatc.net. Esse serviço fornece proteção de nome de domínio e monitoramento para proteção contra comportamentos mal intencionados.
ExactTarget está a ser utilizado quando vê pedidos para *.exacttarget.com. Esse serviço fornece gerenciamento de link de email e monitoramento contra comportamentos mal-intencionados.
Akamai é em uso quando você vê as solicitações que incluem um dos seguintes FQDNs. Esse serviço oferece DNS geográfica e serviços de rede de distribuição de conteúdo.
*.akadns.net
*.akam.net
*.akamai.com
*.akamai.net
*.akamaiedge.net
*.akamaihd.net
*.akamaized.net
*.edgekey.net
*.edgesuite.net
Tenho de ter a conectividade mínima possível para o Microsoft 365
Uma vez que o Microsoft 365 é um conjunto de serviços criados para funcionar através da Internet, as promessas de fiabilidade e disponibilidade baseiam-se em muitos serviços de Internet padrão disponíveis. Por exemplo, os serviços de Internet padrão, como DNS, CRL e CDNs, têm de estar acessíveis para utilizar o Microsoft 365, tal como têm de estar acessíveis para utilizar a maioria dos serviços de Internet modernos.
O conjunto de aplicações do Microsoft 365 está dividido em quatro áreas de serviço principais que representam as três cargas de trabalho principais e um conjunto de recursos comuns. Estas áreas de serviço podem ser utilizadas para associar fluxos de tráfego a uma determinada aplicação. No entanto, dado que as funcionalidades consomem frequentemente pontos finais em várias cargas de trabalho, estas áreas de serviço não podem ser utilizadas de forma eficaz para restringir o acesso.
Área de Serviço | Descrição |
---|---|
Exchange |
Exchange Online e Proteção do Exchange Online |
SharePoint |
SharePoint Online e OneDrive for Business |
Skype for Business Online e Microsoft Teams |
Skype for Business Online e Microsoft Teams |
Comum |
Microsoft 365 Pro Plus, Office num browser, Microsoft Entra ID e outros pontos finais de rede comuns |
Além dos serviços básicos de internet, há serviços de terceiros que são usados somente para integrar funcionalidade. Embora estes serviços sejam necessários para integração, são marcados como opcionais no artigo Pontos finais do Microsoft 365. Isto significa que a funcionalidade principal do serviço continua a funcionar se o ponto final não estiver acessível. Qualquer ponto final de rede necessário tem o atributo necessário definido como verdadeiro. Qualquer ponto final de rede opcional tem o atributo necessário definido como falso e o atributo notas detalha a funcionalidade em falta que deve esperar se a conectividade estiver bloqueada.
Se estiver a tentar utilizar o Microsoft 365 e encontrar serviços de terceiros que não estão acessíveis, quer garantir que todos os FQDNs marcados como obrigatórios ou opcionais neste artigo são permitidos através do proxy e da firewall.
Como bloqueio o acesso aos serviços do consumidor da Microsoft?
A funcionalidade de restrições de inquilino suporta agora o bloqueio da utilização de todas as aplicações de consumidor da Microsoft (aplicações MSA), como o OneDrive, Hotmail e Xbox.com. Esta funcionalidade utiliza um cabeçalho separado para o ponto final login.live.com. Para obter mais informações, veja Utilizar restrições de inquilinos para gerir o acesso a aplicações na cloud SaaS.
O firewall exige endereços IP e não processa URLs. Como fazer configurá-lo para o Microsoft 365?
O Microsoft 365 não fornece endereços IP de todos os pontos finais de rede necessários. Alguns são fornecidos somente como URLs e são categorizados como padrão. Os URLs na categoria predefinida necessária devem ser permitidos através de um servidor proxy. Se não tiver um servidor proxy, veja como configurou pedidos Web para URLs que os utilizadores escrevem na barra de endereço de um browser; o utilizador também não fornece um endereço IP. Os URLs de categoria predefinidos do Microsoft 365 que não fornecem endereços IP devem ser configurados da mesma forma.
Artigos relacionados
Endereço IP e serviço Web de URL do Microsoft 365
Intervalos de IP do Datacenter do Microsoft Azure
Grupos de notícias públicos da Microsoft
Requisitos de infraestrutura de rede para o Microsoft Intune