Gerir pontos finais do Office 365

A maioria das organizações empresariais com múltiplas localizações de escritório e uma WAN que se ligue precisará de configuração para a conectividade de rede do Office 365. Pode otimizar a sua rede ao enviar todos os pedidos de rede de confiança do Office 365 diretamente através da sua firewall, ao ultrapassar todas as inspeções ou processamento extra de pacotes. Esta ação reduz a latência e os seus requisitos de capacidade de perímetro. Identificar o tráfego de rede do Office 365 é o primeiro passo para fornecer o melhor desempenho aos seus utilizadores. Para obter mais informações, consulte Princípios de Conectividade de Rede do Office 365.

A Microsoft recomenda que aceda aos pontos finais de rede do Office 365 e que faça alterações contínuas aos mesmo utilizando o Endereço IP e o Serviço Web de URL do Office 365.

Independentemente da forma como gere tráfego de rede vital do Office 365, o Office 365 necessita de ligação à Internet. Outros pontos finais de rede onde é necessária conectividade estão listados em Pontos finais adicionais não incluídos no serviço Web de URL e Endereço IP do Office 365.

A forma como utiliza os pontos finais de rede do Office 365 dependerá da arquitetura de rede da sua organização empresarial. Este artigo aborda várias formas como as arquiteturas de rede empresarial podem ser integradas com OS URLs e endereços IP do Office 365. A forma mais fácil de escolher quais os pedidos de rede em que confia é utilizar dispositivos SD-WAN que suportem a configuração automatizada do Office 365 em cada uma das suas localizações do escritório.

SD-WAN para saída do ramo local de tráfego de rede vital do Office 365

Em cada localização da filial, pode fornecer um dispositivo SD-WAN configurado para encaminhá-lo para o Office 365 Otimizar categoria de pontos finais ou Otimizar e Permitir categorias diretamente para a rede da Microsoft. Outro tráfego de rede, incluindo tráfego do centro de dados no local, tráfego de Web sites de Internet geral e tráfego para pontos finais de categoria predefinido do Office 365 é enviado para outra localização onde tenha um perímetro de rede mais substancial.

A Microsoft está a trabalhar com fornecedores SD-WAN para ativar a configuração automática. Para obter mais informações, consulte Programa de Parceiro de Rede do Office 365.

Utilizar um ficheiro PAC para o direcionar de tráfego vital do Office 365

Utilize ficheiros PAC ou WPAD para gerir pedidos de rede associados ao Office 365 mas que não têm um endereço IP. Os pedidos de rede típicos enviados através de um dispositivo de perímetro ou proxy aumentam a latência. Apesar de as SSL Break and Inspect criarem a maior latência, outros serviços, como a autenticação de proxy e a procura de reputação, podem causar um desempenho fraco e uma má experiência de utilizador. Além disso, estes dispositivos de rede de perímetro precisam de capacidade suficiente para processar todos os pedidos de ligação de rede. Recomendamos que não utilize os seus dispositivos de inspeção ou proxy para pedidos de rede diretos do Office 365.

A Galeria do PowerShell Get-PacFile é um script do PowerShell que lê os pontos finais de rede mais recentes do serviço Web de URL e Endereço IP do Office 365 e cria um ficheiro PAC de exemplo. Pode modificar o script para que se possa integrar com a sua gestão de ficheiros PAC existente.

Nota

Para obter mais informações sobre as considerações de segurança e desempenho da conectividade direta aos pontos finais do Office 365, consulte Princípios de Conectividade de Rede do Office 365.

Figura 1 – perímetro de rede empresarial simples

O ficheiro PAC está implementado nos browsers no momento 1 na Figura 1. Ao utilizar um ficheiro PAC para uma saída direta de tráfego de rede vital do Office 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 adquirir os endereços IP para as mesmas categorias de pontos finais do Office 365, conforme especificado no ficheiro PAC e ao criar ACLs de firewall com base nesses endereços. A firewall é o ponto 3 na Figura 1.

Separadamente, se optar por fazer apenas o direta direta para os pontos finais de Otimização da categoria, todos os pontos finais de categoria necessários que enviar para o servidor proxy terão de estar listados no servidor proxy para que o processamento seja desaprofundado. Por exemplo, as quebras SSL e a Inspeção e Autenticação do Proxy são incompatíveis com os pontos finais de Otimização e Permitir categoria. 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 do tráfego de rede do Office 365 que atinge o servidor proxy. Para obter informações sobre problemas com sSL Break and Inspect, consulte Utilizar dispositivos de rede de terceiros ou soluções no tráfego do Office 365.

Existem dois tipos de ficheiros PAC que o script Get-PacFile que será gerado.

Tipo	Descrição
1	Enviar otimizar o tráfego de ponto final diretamente e tudo o resto para o servidor proxy.
2	Envie Otimizar e Permitir o tráfego de ponto final direto e tudo o resto para o servidor proxy. Este tipo também pode ser utilizado para enviar todo o tráfego suportado do ExpressRoute para Office 365 para segmentos de rede do ExpressRoute e tudo o resto para o servidor proxy.

Eis um exemplo simples de como chamar o script do PowerShell:

Get-PacFile -ClientRequestId b10c5ed1-bad1-445f-b386-b919946339a7

Existem muitos parâmetros que pode passar para o script:

Parâmetro	Descrição
ClientRequestId	Isto é obrigatório e é um GUID transmitido para o serviço Web que representa o computador cliente que faz a chamada.
Instância	A instância de serviço do Office 365, que por predefinição é Global. Este problema também é transmitido para o serviço Web.
TenantName	O nome do seu inquilino do Office 365. Transmitido para o serviço Web e utilizado como um parâmetro substituível em alguns URLs do Office 365.
Tipo	O tipo de ficheiro PAC de proxy que pretende gerar.

Eis outro exemplo de como chamar o script do PowerShell com parâmetros adicionais:

Get-PacFile -Type 2 -Instance Worldwide -TenantName Contoso -ClientRequestId b10c5ed1-bad1-445f-b386-b919946339a7

O processamento de servidor proxy não é processado pelo tráfego de rede do Office 365

Quando os ficheiros PAC não são utilizados para tráfego de saída direto, continua a não querer processar no perímetro de rede ao configurar o servidor proxy. Alguns fornecedores de servidores proxy ativaram a configuração automática desta situação, conforme descrito no Programa de Parceiros de Rede do Office 365.

Se o fizer manualmente, terá de obter os dados de Otimização e Permitir categorias de pontos finais a partir do Endereço IP e do Serviço Web de URL do Office 365 e configurar o seu servidor proxy de modo a não processar os dados para estes. É importante evitar a Quebra de SSL, a Inspecão e a Autenticação do Proxy para os pontos finais da categoria Otimizar e Permitir.

Gestão de alterações dos endereços IP e URLs do Office 365

Para além de selecionar uma configuração adequada para o perímetro de rede, é fundamental que adote um processo de gestão de alterações para pontos finais do Office 365. Estes pontos finais mudam regularmente e, se não gerir as alterações, pode fazer com que os utilizadores bloqueados ou com um desempenho fraco após a adição de um novo ENDEREÇO IP ou URL.

Normalmente, as alterações aos ENDEREÇOS IP e URLs do Office 365 são publicadas perto do último dia de cada mês. Por vezes, será publicada uma alteração fora deste horário devido aos requisitos operacionais, de suporte ou de segurança.

Quando for publicada uma alteração que requeira que atue porque foi adicionado um endereço IP ou URL, deve receber um aviso de 30 dias após a hora em que publicamos a alteração até que haja um serviço do Office 365 no ponto final. Isto é refletido como a Data Efetiva. Embora tenha como objetivo este período de notificação, nem sempre é possível devido aos requisitos operacionais, de suporte ou de segurança. As alterações que não exigem ação imediata para manter a conectividade, como endereços IP ou URLs removidos ou alterações menos significativas, não incluem notificação de avanço. Nestes casos, não será fornecida nenhuma Data Efetiva. Independentemente da notificação fornecida, listamos a data ativa do serviço esperada para cada alteração.

Alterar notificação através do Serviço Web

Pode utilizar o Endereço IP e o Serviço Web de URL do Office 365 para receber uma notificação de alteração. Recomendamos que ligue para o método Web /version uma vez por hora para verificar a versão dos pontos finais que está a utilizar para ligar ao Office 365. Se esta versão for alterada em comparação com a versão que tem em utilização, deverá obter os dados de pontos finais mais recentes a partir do método Web /pontos finais e, opcionalmente, obter as diferenças através do método Web /changes . Não é necessário ligar para os / pontos finais ou /métodos Web de alterações se não tiver sido encontrada qualquer alteração à versão que encontrou.

Para obter mais informações, consulte Endereço IP e Serviço Web de URL do Office 365.

Alterar notificação através de feeds RSS

O Serviço Web de URL e o Endereço IP do Office 365 fornecem um feed RSS a que pode subscrever no Outlook. Existem ligações para os URLs de RSS em cada uma das páginas específicas da instância do serviço do Office 365 para os endereços IP e URLs. Para obter mais informações, consulte Endereço IP e Serviço Web de URL do Office 365.

Alterar a notificação e a revisão de aprovação através do Power Automate

Compreendemos que ainda poderá necessitar de processamento manual para as alterações de pontos finais de rede que passam por cada 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 da rede do Office 365 têm alterações. Quando a revisão for concluída, pode fazer com que o fluxo envie automaticamente as alterações para a sua firewall e para a equipa de gestão do servidor proxy.

Para obter informações sobre um modelo e exemplo do Power Automate, consulte Utilizar o Power Automate para receber um e-mail para obter alterações aos URLs e endereços IP do Office 365.

FAQ sobre pontos finais de rede do Office 365

Consulte estas perguntas mais frequentes sobre a conectividade de rede do Office 365.

Como posso submeter uma pergunta?

Clique na ligação na parte inferior para indicar se o artigo foi útil ou não e submeter quaisquer perguntas adicionais. Monitorizamos o feedback e atualizamos as perguntas aqui com as perguntas mais frequentes.

Como posso determinar a localização do meu inquilino?

A localização do inquilino é determinada melhor utilizando o nosso mapa do centro de dados.

Estou a es peering de forma adequada com a Microsoft?

As localizações de peering são descritas mais detalhadamente em peering com a Microsoft.

Com mais de 2500 relações de peering do ISP globalmente e 70 pontos de presença, a separação entre a sua rede e a nossa deverá ser totalmente íntegro. Não pode perder alguns minutos a certificar-se de que a relação de peering do ISP é a mais ideal. Eis alguns exemplos de boas e menos boas entregas de peering da nossa rede.

Vejo pedidos de rede para endereços IP que não se inserem na lista publicada. Tenho de lhes fornecer acesso?

Só fornecemos endereços IP para os servidores do Office 365 para os que deve encam vão diretamente. Esta não é uma lista abrangente de todos os endereços IP para os que verá pedidos de rede. Verá pedidos de rede para endereços IP não publicados da Microsoft e de terceiros. Estes endereços IP são gerados ou geridos de forma dinâmica, o que impede a notificação ate momento quando são alterados. Se a sua firewall não conseguir permitir o acesso com base nos FQDNs destes pedidos de rede, utilize um ficheiro PAC ou WPAD para gerir os pedidos.

Vê um IP associado ao Office 365 no onde pretende obter mais informações?

1. Verifique se o endereço IP está incluído num intervalo publicado maior com uma calculadora CIDR, como estas para IPv4 ou IPv6. 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.
2. Veja se o IP pertence a um parceiro com uma consulta whois. Se for da Microsoft, pode ser um parceiro interno. Muitos pontos finais de rede de parceiros são indicados como pertencentes à categoria predefinida, para a qual os endereços IP não são publicados.
3. O endereço IP pode não fazer parte do Office 365 ou de uma dependência. A publicação de pontos finais de rede do Office 365 não inclui todos os pontos finais de rede da Microsoft.
4. Verifique o certificado. Com um browser, ligue ao endereço IP através do HTTPS://<IP_ADDRESS> e verifique 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 Office 365, é provável que o endereço IP está associado a uma CDN da Microsoft como o MSOCDN.NET ou outro domínio da Microsoft sem informações de IP publicadas. Se deteta que o domínio no certificado é um dos domínios que afirmamos ter listado o endereço IP, informe-nos.

Alguns URLs do Office 365 apontam para registos CNAME em vez de registos no DNS. O que tenho de fazer com os registos 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 em nuvem. Alguns URLs incluídos no Office 365 mostram registos CNAME em vez de registos A ou AAAA. Estes registos CNAME são intermediários e podem haver vários numa cadeia. Serão sempre resolvidos para um registo A ou AAAA de um Endereço IP. Por exemplo, considere a seguinte série de registos DNS, que é resolvida em última instância para o endereço IP IP_1:

serviceA.office.com -> CNAME: serviceA.domainA.com -> CNAME: serviceA.domainB.com -> A: IP_1

Estes redirecionamentos CNAME são uma parte normal do DNS e são transparentes para o computador cliente e transparentes para 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, estes estão sujeitos a alterações em qualquer altura e não precisa de os configurar conforme permitido no seu 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 Office 365. O servidor proxy pede a resolução DNS do URL para um Endereço IP e irá receber uma IP_1. Não valida os registos de redirecionamento CNAME intermediários.

As configurações rígidas ou a utilização de uma lista de permitidos com base em FQDNs indiretos do Office 365 não são recomendadas, não são suportadas pela Microsoft e são conhecidas por causar problemas de conectividade do cliente. As soluções DNS que bloqueiam o redirecionamento CNAME ou que resolvem incorretamente as entradas DNS do Office 365 podem ser resolvidas através de reencanhadores DNS com a recursão DNS ativada ou com sugestões raiz DNS. Muitos produtos de perímetro de rede de terceiros integram nativamente o ponto final recomendado do Office 365 para incluir uma lista de perdões na respetiva configuração através do serviço Web de URL e Endereço IP do Office 365.

Por que motivo vejo nomes como nsatc.net ou akadns.net nomes de domínio da Microsoft?

O Office 365 e outros serviços da Microsoft utilizam vários serviços de terceiros, como o Akamai e o MarkMonitor, para melhorar a sua experiência do Office 365. Para continuarmos a lhe dar a melhor experiência possível, iremos alterar estes serviços no futuro. Os domínios de terceiros podem alonhar conteúdos, como uma CDN, ou podem alonhar um serviço, como um serviço de gestão de tráfego geográfico. Alguns dos serviços atualmente utilizados incluem:

O MarkMonitor está a ser utilizado quando vir pedidos que incluem *.nsatc.net. Este serviço fornece proteção e monitorização de nomes de domínio contra comportamento malicioso.

O exactTarget está a ser utilizado quando vir pedidos para *.exacttarget.com. Este serviço fornece gestão e monitorização de ligações de e-mail contra comportamento malicioso.

O Akamai está a ser utilizado quando vir pedidos que incluem um dos seguintes FQDNs. Este serviço oferece serviços de geoDNS e de redes de entrega de conteúdos.

*.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 Office 365

Como o Office 365 é um conjunto de serviços criado para funcionar na Internet, a fiabilidade e disponibilidade são baseadas no funcionamento de vários serviços de Internet padrão. Por exemplo, os serviços de Internet padrão, como o DNS, o CRL e CDNs, têm de estar acessíveis para utilizar o Office 365, como também têm de estar acessíveis para utilizar serviços de Internet mais modernos.

O conjunto de ações do Office 365 está separado nas principais áreas de serviço. Estes podem ser ativados seletivamente para conectividade e existe uma área Comum, que é uma dependência para todos e é sempre necessária.

Área de Serviço	Descrição
Exchange	Exchange Online e Proteção do Exchange Online
SharePoint	SharePoint Online e OneDrive for Business
Skype para Empresas Online e Microsoft Teams	Skype para Empresas e Microsoft Teams
Comum	Office 365 Pro Plus, Office num browser, Azure AD e outros pontos finais de rede comuns

Para além dos serviços de Internet básicos, existem serviços de terceiros que são utilizados apenas para integrar funcionalidades. Embora estes sejam necessários para integração, estão marcados como opcionais no artigo pontos finais do Office 365, o que significa que as funcionalidades principais do serviço continuarão a funcionar se o ponto final não estiver acessível. Qualquer ponto final de rede obrigatório terá o atributo obrigatório definido como verdadeiro. Qualquer ponto final de rede opcional terá o atributo obrigatório definido como falso e o atributo das notas irá detalhar a funcionalidade em falta que deve esperar se a conectividade estiver bloqueada.

Se estiver a tentar utilizar o Office 365 e vir que existem serviços de terceiros que não estão acessíveis, deve certificar-se de que todos os FQDNs marcados como obrigatórios ou opcionais neste artigo são permitidos através do proxy e da firewall.

Como posso bloquear o acesso aos serviços de consumidor da Microsoft?

A funcionalidade de restrições de inquilino agora suporta 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 ação utiliza um cabeçalho separado para o login.live.com final. Para obter mais informações, consulte Utilizar restrições de inquilino para gerir o acesso a aplicações na nuvem do SaaS.

A minha firewall necessita de Endereços IP e não consegue processar URLs. Como posso configurá-lo para o Office 365?

O Office 365 não fornece endereços IP de todos os pontos finais de rede necessários. Alguns são fornecidos apenas como URLs e são categorizados como predefinição. Os URLs na categoria predefinida que são necessários devem ser permitidos através de um servidor proxy. Se não tiver um servidor proxy, veja como configurou os 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 Office 365 que não fornecem endereços IP devem ser configurados da mesma forma.

Tópicos relacionados

Serviço Web de URL e Endereço IP do Office 365

Intervalos IP do Microsoft Azure Datacenter

Microsoft Public IP Space

Requisitos de infraestrutura de rede do Microsoft Intune

ExpressRoute e Power BI

Intervalos de endereços de URLs e IP do Office 365

Gerir a conectividade do ExpressRoute para Office 365

Princípios de Conectividade de Rede do Office 365