Управление конечными точками Office 365

Перед большинством организаций, имеющих несколько соединенных глобальной сетью офисов, встает вопрос настройки сетевого подключения Office 365. Вы можете оптимизировать сеть, отправив все Office 365 сетевые запросы непосредственно через брандмауэр, минуя все дополнительные проверки или обработки на уровне пакетов. Это сокращает время задержки и снижает требования к пропускной способности периметра. Определение сетевого трафика Office 365 — это первый шаг в обеспечении оптимальной производительности для пользователей. Дополнительные сведения см. в Office 365 сетевых подключений.

Корпорация Майкрософт рекомендует получить доступ к конечным точкам Office 365 сети и текущим изменениям в них с помощью Office 365 IP-адреса и URL-адреса.

Независимо от того, как вы управляете важнейшим сетевым трафиком Office 365, для использования Office 365 необходимо подключение к Интернету. Другие конечные точки сети, подключение к которым обязательно, перечислены в статье Дополнительные конечные точки, не включенные в веб-службу IP-адресов и URL-адресов Office 365.

Использование конечных точек сети Office 365 зависит от архитектуры сети организации. В этой статье описываются способы интеграции корпоративных сетевых архитектур с URL- и IP-адресами Office 365. Самый простой способ выбрать, какие сетевые запросы следует доверять, — использовать устройства SD-WAN, поддерживающие автоматическую настройку Office 365 в каждом из офисов.

SD-WAN для исходящего трафика локальной ветви жизненно важного Office 365 сетевого трафика

В каждом расположении филиала можно предоставить устройство SD-WAN, настроенное для маршрутизации трафика для категории Office 365 Оптимизация конечных точек или категории "Оптимизация и разрешение" непосредственно в сеть Майкрософт. Остальной сетевой трафик, в том числе локальный трафик центра обработки данных, общий интернет-трафик веб-сайтов и трафик к конечным точкам Office 365 категории "По умолчанию" направляется в другое расположение с более надежным периметром сети.

Корпорация Майкрософт работает с поставщиками SD-WAN, чтобы включить автоматическую настройку. Дополнительные сведения см. в статье Партнерская программа Office 365 для поставщиков сетевых устройств и служб.

Использование PAC-файла для прямой маршрутизации важного трафика Office 365

PAC- или WPAD-файлы используются для управления сетевыми запросами, которые связаны с Office 365, но не имеют IP-адреса. Обычные сетевые запросы, которые отправляются через прокси-сервер или устройство в сети периметра, увеличивают время задержки. Хотя самая длительная задержка возникает из-за расшифровки и анализа SSL-трафика, работа других служб, включая проверку подлинности прокси-сервера и просмотр репутации, также может негативно сказываться на производительности и взаимодействии с пользователем. Кроме того, устройствам сети периметра требуется достаточная пропускная способность для обработки всех запросов на сетевое подключение. Мы рекомендуем обходить прокси-сервер и устройства проверки для прямых сетевых запросов к Office 365.

Get-PacFile из коллекции PowerShell — это сценарий PowerShell, который считывает последние конечные точки сети из веб-службы IP-адресов и URL-адресов Office 365 и создает шаблон PAC-файла. Этот сценарий можно изменить так, чтобы он интегрировался с существующим управлением PAC-файлами.

Примечание.

Дополнительные сведения о безопасности и производительности прямого подключения к конечным точкам Office 365 см. в Office 365.

Подключение к Office 365 через брандмауэры и прокси-серверы.

Рисунок 1. Простой периметр корпоративной сети

На рисунке 1 PAC-файл развернут в веб-браузерах в точке 1. При использовании PAC-файла для прямого выхода важного трафика Office 365 также необходимо разрешить подключение к IP-адресам, URL-адрес которых находится за периметром брандмауэра. Для этого нужно получить IP-адреса конечных точек Office 365 тех категорий, которые указаны в PAC-файле, и на основе этих адресов создать списки управления доступом для брандмауэра. На рисунке 1 брандмауэр обозначен цифрой 3.

Если прямая маршрутизация выбрана только для конечных точек категории "Оптимизировать", любые обязательные точки категории "Разрешить", которые направляются на прокси-сервер, необходимо внести в список прокси-сервера, чтобы избежать их дальнейшей обработки. Например, расшифровка и анализ SSL-трафика и аутентификация прокси-сервера несовместимы с конечными точками категорий "Оптимизировать" и "Разрешить". На рисунке 1 прокси-сервер обозначен цифрой 2.

Общая конфигурация рассчитана на то, чтобы разрешить не обрабатывать весь исходящий трафик с прокси-сервера на IP-адреса назначения для сетевого трафика Office 365, который обращается к этому прокси-серверу. Проблемы, возникающие при расшифровке и анализе SSL-трафика, описаны в статье Использование сторонних сетевых устройств или решений для трафика Office 365.

Сценарий Get-PacFile генерирует PAC-файлы двух типов.

Тип Описание
1
Отправка трафика конечных точек категории "Оптимизировать" напрямую, а всего остального трафика — на прокси-сервер.
2
Отправка трафика конечных точек категорий "Оптимизировать" и "Разрешить" напрямую, а всего остального трафика — на прокси-сервер. PAC-файлы этого типа также можно использовать для отправки всего трафика, поддерживаемого службой ExpressRoute для Office 365, в сегменты сети ExpressRoute, а всего остального трафика — на прокси-сервер.

Вот простой пример вызова сценария PowerShell:

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

В скрипт можно передать множество параметров:

Параметр Описание
ClientRequestId
Обязательный параметр — идентификатор GUID, передаваемый веб-службе, которая представляет клиентский компьютер, осуществляющий вызов.
Instance
Экземпляр Office 365 службы, который по умолчанию используется по всему миру. Он также передается в веб-службу.
TenantName
Имя клиента Office 365. Передается в веб-службу и используется в качестве замены в некоторых URL-адресах Office 365.
Type
Тип PAC-файла прокси-сервера, который нужно создать.

Вот еще один пример вызова сценария PowerShell с дополнительными параметрами:

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

Прохождение сетевого трафика Office 365 в обход прокси-сервера

Если PAC-файлы не используются для прямого исходящего трафика, вы по-прежнему хотите обойти обработку по периметру сети, настроив прокси-сервер. Некоторые поставщики прокси-серверов предусмотрели автоматическую настройку этой функции, как описано в статье Партнерская программа Office 365 для поставщиков сетевых устройств и служб.

Если вы выполняете это вручную, необходимо получить данные категории "Оптимизация" и "Разрешить конечную точку" из веб-службы OFFICE 365 IP-адрес и URL-адрес, а также настроить прокси-сервер для обхода их обработки. Важно, чтобы к конечным точкам категорий "Оптимизировать" и "Разрешить" не применялись расшифровка и анализ SSL-трафика и аутентификация прокси-сервера.

Управление изменениями URL- и IP-адресов Office 365

Помимо выбора соответствующей конфигурации для периметра сети, крайне важно внедрить процесс управления изменениями для Office 365 конечных точек. Эти конечные точки изменяются регулярно, и если вы не управляете изменениями, то после добавления нового IP-адреса или URL-адреса пользователи могут быть заблокированы или работать с низкой производительностью.

Обычно изменения URL- и IP-адресов Office 365 публикуются в конце каждого месяца. Иногда изменение может публиковаться вне этого графика, исходя из требований безопасности, нужд поддержки или эксплуатации.

При публикации изменения, требующее выполнения действий из-за добавления IP-адреса или URL-адреса, вы должны получать уведомление за 30 дней с момента публикации изменения до тех пор, пока на этой конечной точке не будет Office 365 службы. Это отражается как дата вступления в силу. Хотя мы стараемся обеспечить такой период, это не всегда возможно в связи с требованиями безопасности, поддержки или эксплуатации. Изменения, которые не требуют немедленного действия для поддержания подключения, такие как удаленные IP-адреса или URL-адреса или менее значимые изменения, не включают в себя уведомление заранее. В этих случаях дата вступления в силу не будет указана. Независимо от предоставляемых уведомлений мы указываем ожидаемую дату ввода в действие службы для каждого изменения.

Получение уведомлений об изменениях с помощью веб-службы

Чтобы получать уведомления об изменениях, можно использовать веб-службу URL- и IP-адресов Office 365. Мы рекомендуем вызывать веб-метод /version один раз в час, чтобы проверить версию конечных точек, которые вы используете для подключения к Office 365. Если версия отличается от той, которую вы используете в данный момент, нужно получить последние данные конечной точки с помощью веб-метода /endpoints, а при желании можно посмотреть отличия с помощью веб-метода /changes. Нет необходимости вызывать веб-методы /endpoints или /changes , если не было изменений в найденной версии.

Дополнительные сведения см. в статье Веб-служба IP-адресов и URL-адресов в Office 365.

Получение уведомлений об изменениях с помощью RSS-каналов

Веб-служба IP-адресов и URL-адресов в Office 365 предоставляет RSS-канал, на который можно подписаться в Outlook. На каждой странице конкретного экземпляра службы Office 365 есть ссылки на URL-адреса RSS с соответствующими URL- и IP-адресами. Дополнительные сведения см. в статье Веб-служба IP-адресов и URL-адресов в Office 365.

Уведомления об изменениях и утверждение с помощью Power Automate

Возможно, вам понадобится вручную обрабатывать изменения конечных точек сети, выходящие ежемесячно. С помощью Power Automate можно создать поток, который уведомляет вас по электронной почте и при необходимости запускает процесс утверждения изменений Office 365 конечных точек сети. Этот процесс можно настроить таким образом, чтобы по завершении проверки изменения автоматически отправлялись по электронной почте вашей команде управления прокси-сервером и брандмауэром.

Сведения о примере и шаблоне Power Automate см. в статье "Использование Power Automate для получения сообщения электронной почты об изменениях Office 365 IP-адресов и URL-адресов".

Вопросы и ответы о конечных точках сети Office 365

Ознакомьтесь с часто задаваемыми вопросами о Office 365 сетевых подключений.

Как отправить вопрос?

Щелкните ссылку внизу в зависимости от того, оказалась ли статья полезной для вас, и отправьте все дополнительные вопросы. Мы отслеживаем отзывы и добавляем сюда наиболее часто задаваемые вопросы.

Как определить расположение моего клиента?

Расположение клиента проще всего определить с помощью нашей карты центров обработки данных.

Правильно ли я использую пиринговое подключение к сети Майкрософт?

Расположения пиринговых подключений более подробно описаны в статье о пиринге с Microsoft.

Благодаря наличию более 2500 пиринговых связей с поставщиками услуг Интернета по всему миру и 70 точек присутствия подключение из вашей сети к нашей не составит проблем. Будет нелишним потратить несколько минут и убедиться, что ваш поставщик услуг Интернета предоставляет оптимальную пиринговую связь. Вот несколько примеров подключений к нашей сети — как хороших, так и не очень.

Я вижу сетевые запросы на IP-адреса, отсутствующие в опубликованном списке. Нужно ли предоставлять к ним доступ?

Мы предоставляем только IP-адреса серверов Office 365, к которым должна выполняться прямая маршрутизация. Это не полный список всех IP-адресов, для которых создаются сетевые запросы. Вы увидите сетевые запросы к Корпорации Майкрософт и сторонним, неопубликованным IP-адресам. Они создаются или управляются динамически таким образом, что об их изменении невозможно уведомить заранее. Если брандмауэр не разрешает доступ на основе полных доменных имен в ответ на эти сетевые запросы, используйте для управления запросами PAC- или WPAD-файл.

Хотите узнать больше об IP-адресе, связанном с Office 365?

  1. Проверьте, нет ли его в более широком диапазоне опубликованных IP-адресов, используя калькулятор CIDR, такой как этот для IPv4 или IPv6. Например, IP-адрес 40.103.0.1 входит в диапазон 40.96.0.0/13, хотя 40.103 не совпадает с 40.96.
  2. Посмотрите, не принадлежит ли IP-адрес партнеру. Это можно сделать с помощью запроса whois. Если адрес принадлежит Майкрософт, возможно, это внутренний партнер. Многие конечные точки партнерской сети перечислены как принадлежащие к категории по умолчанию, для которой IP-адреса не публикуются.
  3. Возможно, IP-адрес не является зависимостью или частью службы Office 365. Office 365 конечной точки сети включает не все конечные точки сети Майкрософт.
  4. Проверьте сертификат. В браузере подключитесь к IP-адресу <с помощью HTTPS:// IP_ADDRESS> и проверьте домены, перечисленные в сертификате, чтобы понять, какие домены связаны с IP-адресом. Если это IP-адрес, принадлежащий корпорации Майкрософт, а не в списке Office 365 IP-адресов, скорее всего, IP-адрес связан с сетью доставки содержимого (Майкрософт), такой как MSOCDN.NET или другой домен Майкрософт без опубликованных IP-адресов. Если выяснится, что указанный в сертификате домен — такой, для которого должен быть список IP-адресов, сообщите нам об этом.

Некоторые URL-адреса Office 365 в DNS указывают не на записи A, а на записи CNAME. Что делать с записями CNAME?

Клиентским компьютерам требуется запись DNS A или AAAA, которая включает один или несколько IP-адресов для подключения к облачной службе. В некоторых URL-адресах Office 365 вместо записей A или AAAA отображаются записи CNAME. Такие записи CNAME являются промежуточными и могут образовывать последовательность из нескольких записей. В конечном итоге они всегда сводятся к записи A или AAAA, чтобы получить IP-адрес. Например, рассмотрим следующую последовательность записей DNS, которые сводятся к IP-адресу IP_1:

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

Такие перенаправления CNAME — нормальная часть DNS, прозрачная для клиентских компьютеров и прокси-серверов. Они используются для балансировки нагрузки, снижения рисков неполадок служб, обеспечения высокого уровня доступности и работы сетей доставки содержимого. Корпорация Майкрософт не публикует промежуточные записи CNAME, они могут быть изменены в любое время, и вам не нужно настраивать их как разрешенные на прокси-сервере.

Прокси-сервер проверяет исходный URL-адрес, который в приведенном выше примере serviceA.office.com этот URL-адрес будет включен в Office 365 публикации. Прокси-сервер запрашивает разрешение DNS этого URL-адреса в IP-адресе и получает в ответ IP_1. Он не проверяет промежуточные записи перенаправления CNAME.

Жестко заданные конфигурации или использование списка разрешений на основе непрямых полных доменных имен Office 365 не рекомендуется, не поддерживается корпорацией Майкрософт и, как известно, вызывает проблемы с подключением клиентов. Решения DNS, которые блокируют перенаправление CNAME или неправильно разрешают Office 365 записей DNS, можно решить с помощью серверов пересылки DNS с включенной рекурсией DNS или с помощью корневых указаний DNS. Многие сторонние продукты периметра сети изначально интегрируются с рекомендуемой конечной точкой Office 365, чтобы включить список разрешений в свою конфигурацию с помощью Office 365 IP-адреса и URL-адреса веб-службы.

Почему в списке доменных имен Майкрософт присутствуют такие имена, как nsatc.net или akadns.net?

Office 365 и другие службы Майкрософт используют некоторые сторонние службы, такие как Akamai и MarkMonitor, для улучшения работы Office 365. В будущем мы можем сменить их, чтобы обеспечивать стабильно высокий уровень обслуживания. Сторонние домены могут содержать содержимое, например CDN, или службу, например службу управления географическим трафиком. Ниже перечислены некоторые из служб, которые используются в настоящее время.

MarkMonitor используется, когда вы видите запросы, включающее *.nsatc.net. Эта служба обеспечивает безопасность и мониторинг доменных имен для защиты от злоумышленников.

ExactTarget используется при появлении запросов к *.exacttarget.com. Эта служба обеспечивает администрирование и мониторинг ссылок в сообщениях электронной почты для защиты от злоумышленников.

Служба Akamai используется, если вы видите запросы, включающие одно из указанных ниже полных доменных имен. Эта служба предоставляет услуги geo-DNS и CDN.

*.akadns.net
*.akam.net
*.akamai.com
*.akamai.net
*.akamaiedge.net
*.akamaihd.net
*.akamaized.net
*.edgekey.net
*.edgesuite.net

Мне необходимо минимальное количество подключений для Office 365

Поскольку Office 365 — это набор служб, предназначенных для работы через Интернет, его надежность и доступность зависит от доступности многих стандартных служб Интернета. Например, такие стандартные службы Интернета, как DNS, CRL и CDN, должны быть доступны для использования Office 365 точно так же, как и для большинства современных веб-служб.

Входящие в набор Office 365 службы распределены в соответствии с основными областями обслуживания, Их можно выборочно включить для подключения, и существует общая область, которая является зависимостью для всех и всегда требуется.

Область обслуживания Описание
Exchange
Exchange Online и Exchange Online Protection
SharePoint
SharePoint Online и OneDrive для бизнеса
Skype для бизнеса Online и Microsoft Teams
Skype для бизнеса и Microsoft Teams
Common
Office 365 профессиональный плюс, Office в браузере, Azure AD и другие общие конечные точки сети

Помимо базовых служб Интернета есть сторонние службы, которые используются только для интеграции функциональных возможностей. Хотя они необходимы для интеграции, они помечаются как необязательные в статье Office 365 конечных точек. Это означает, что основные функции службы будут продолжать работать, если конечная точка недоступна. Для любой требуемой конечной точки сети обязательный атрибут будет иметь значение true. Для любой необязательной конечной точки сети обязательный атрибут будет иметь значение false, а атрибут notes будет содержать сведения об отсутствующих функциях, которые следует ожидать, если подключение заблокировано.

Если вы пытаетесь использовать Office 365 и нашли сторонние службы недоступны, необходимо убедиться, что все полные доменные имена, помеченные как обязательные или необязательные в этой статье, разрешены через прокси-сервер и брандмауэр.

Как заблокировать доступ к службам Майкрософт для потребителей?

Функция ограничений клиентов теперь поддерживает блокировку использования всех потребительских приложений Майкрософт (приложений MSA), таких как OneDrive, Hotmail и Xbox.com. При этом используется отдельный заголовок конечной login.live.com конечной точки. Дополнительные сведения см. в разделе "Использование ограничений клиента для управления доступом к облачным приложениям SaaS".

Моему брандмауэру требуются IP-адреса и не удается обрабатывать URL-адреса. Как настроить его для Office 365?

Office 365 не предоставляет IP-адреса всех необходимых конечных точек сети. Некоторые предоставляются только в виде URL-адресов и относятся к категории "По умолчанию". URL-адреса в категории по умолчанию, которые являются обязательными, должны быть разрешены через прокси-сервер. Если у вас нет прокси-сервера, посмотрите, как вы настроите веб-запросы для URL-адресов, которые пользователи введите в адресную строку веб-браузера. Пользователь также не предоставляет IP-адрес. URL Office 365 категории по умолчанию, не предоставляющие IP-адреса, должны быть настроены таким же образом.

Веб-служба IP-адресов и URL-адресов в Office 365

Диапазоны IP-адресов центра обработки данных Microsoft Azure

Пространство публичных IP-адресов корпорации Майкрософт

Требования к сетевой инфраструктуре для Microsoft Intune

ExpressRoute и Power BI

URL-адреса и диапазоны IP-адресов для Office 365

Управление подключением ExpressRoute для Office 365

Принципы сетевого подключения к Office 365