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

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

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

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

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

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

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

Корпорация Майкрософт работает с поставщиками SD-WAN, чтобы включить автоматическую настройку. Дополнительные сведения см. в разделе Microsoft 365 Networking Partner Program.

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

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

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

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

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

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

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

Существует два типа PAC-файлов, создаваемых скриптом Get-PacFile.

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

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

Существует множество параметров, которые можно передать в скрипт:

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

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

Обходная обработка сетевого трафика Microsoft 365 прокси-сервера

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Часто задаваемые вопросы о конечных точках сети Microsoft 365

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

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

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

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

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

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

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

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

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

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

См. IP-адрес, связанный с Microsoft 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-адрес может не быть частью Microsoft 365 или зависимостью. Публикация конечных точек сети Microsoft 365 не включает все конечные точки сети Майкрософт.
4. Проверьте сертификат. В браузере подключитесь к IP-адресу с помощью HTTPS://< IP_ADDRESS> и проверьте домены, перечисленные в сертификате, чтобы понять, какие домены связаны с IP-адресом. Если этот IP-адрес принадлежит корпорации Майкрософт и не входит в список IP-адресов Microsoft 365, скорее всего, он связан с сетью CDN Майкрософт, например с MSOCDN.NET или другим доменом Майкрософт без опубликованной информации об IP-адресе. Если выяснится, что указанный в сертификате домен — такой, для которого должен быть список IP-адресов, сообщите нам об этом.

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

Клиентским компьютерам требуется запись DNS A или AAAA, которая включает один или несколько IP-адресов для подключения к облачной службе. В некоторых URL-адресах, включенных в Microsoft 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-адрес будет включен в публикацию Microsoft 365. Прокси-сервер запрашивает разрешение DNS этого URL-адреса на IP-адрес и получает обратно IP_1. Он не проверяет промежуточные записи перенаправления CNAME.

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

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

Microsoft 365 и другие службы Майкрософт используют несколько сторонних служб, таких как Akamai и MarkMonitor, для улучшения работы с Microsoft 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

Я должен иметь минимальное подключение, возможное для Microsoft 365

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

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

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

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

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

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

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

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

Связанные статьи

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

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

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

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

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

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