Реализация работы ExpressRoute для Microsoft 365
Эта статья относится к Microsoft 365 корпоративный.
ExpressRoute для Microsoft 365 предоставляет альтернативный путь маршрутизации для многих служб Microsoft 365, подключенных к Интернету. Архитектура ExpressRoute для Microsoft 365 основана на рекламе общедоступных IP-префиксов служб Microsoft 365, которые уже доступны через Интернет, в подготовленных каналах ExpressRoute для последующего перераспределения этих префиксов IP-адресов в сети. С помощью ExpressRoute вы эффективно включаете несколько различных путей маршрутизации через Интернет и ExpressRoute для многих служб Microsoft 365. Такое состояние маршрутизации в сети может представлять собой значительное изменение в разработке топологии внутренней сети.
Примечание.
Мы не рекомендуем Использовать ExpressRoute для Microsoft 365, так как в большинстве случаев он не обеспечивает оптимальную модель подключения для службы. Таким образом, для использования этой модели подключения требуется авторизация Майкрософт. Мы проверяем каждый запрос клиента и авторизируем ExpressRoute для Microsoft 365 только в редких случаях, когда это необходимо. Дополнительные сведения см. в руководстве ExpressRoute для Microsoft 365 . После всесторонней проверки документа с командами по повышению производительности, сети и безопасности обратитесь к вашей команде по работе с учетными записями Майкрософт, чтобы при необходимости отправить исключение. Неавторизованные подписки, пытающиеся создать фильтры маршрутов для Microsoft 365, получат сообщение об ошибке.
Необходимо тщательно спланировать реализацию ExpressRoute для Microsoft 365, чтобы обеспечить сложность маршрутизации через выделенный канал с маршрутами, внедренными в основную сеть и Интернет. Если вы и ваша команда не выполняете подробное планирование и тестирование, описанные в этом руководстве, существует высокий риск возникновения периодических или общей потери подключения к службам Microsoft 365 при включении канала ExpressRoute.
Для успешной реализации необходимо проанализировать требования к инфраструктуре, провести подробную оценку и проектирование сети, тщательно спланировать развертывание поэтапным и контролируемым образом, а также составить подробный план проверки и тестирования. Для крупной распределенной среды не редкость реализации охватывает несколько месяцев. Это руководство поможет вам планировать заранее.
Планирование крупных успешных развертываний может занять шесть месяцев и часто включает членов команды из многих областей в организации, включая сетевые сети, администраторов брандмауэра и прокси-сервера, администраторов Microsoft 365, безопасности, поддержки конечных пользователей, управления проектами и спонсорства руководителей. Ваши инвестиции в процесс планирования понизят вероятность того, что произойдет сбой развертывания, что приведет к простою или сложному и дорогостоящему устранению неполадок.
Мы ожидаем, что следующие предварительные требования будут выполнены до запуска этого руководства по реализации.
Вы завершили оценку сети, чтобы определить, является ли ExpressRoute рекомендуемой и утвержденной.
Вы выбрали поставщика сетевых служб ExpressRoute. Сведения о партнерах ExpressRoute и расположениях пиринга.
Вы уже ознакомились с документацией по ExpressRoute и ознакомились с ней, и ваша внутренняя сеть может выполнить все необходимые условия ExpressRoute.
Ваша команда ознакомилась со всеми общедоступными рекомендациями и документацией по адресу , и посмотрела серию обучающих материалов по Azure ExpressRoute для Microsoft 365 на Channel 9, чтобы получить представление о важных технических деталях, включая следующие: https://aka.ms/erthttps://aka.ms/expressrouteoffice365
Интернет-зависимости служб SaaS.
Как избежать асимметричных маршрутов и обработать сложную маршрутизацию.
Как внедрить элементы управления безопасностью периметра, доступностью и уровнем приложения.
Начните с сбора требований
Начните с определения функций и служб, которые вы планируете внедрить в организации. Необходимо определить, какие функции различных служб Microsoft 365 будут использоваться и в каких расположениях в вашей сети будут размещаться пользователи, использующие эти функции. В каталоге сценариев необходимо добавить сетевые атрибуты, необходимые каждому из этих сценариев. например, потоки входящего и исходящего сетевого трафика, а также доступность конечных точек Microsoft 365 через ExpressRoute или нет.
Чтобы собрать требования организации, выполните следующие действия.
Каталогируйте входящий и исходящий сетевой трафик для служб Microsoft 365, используемых вашей организацией. Сведения о потоках, необходимых для различных сценариев Microsoft 365, см. на странице URL-адресов и диапазонов IP-адресов Microsoft 365.
Соберите документацию по существующей топологии сети с подробными сведениями о внутренней магистрали глобальной сети и топологии, подключении вспомогательных сайтов, подключении пользователей последней мили, маршрутизации к точкам исходящего трафика периметра сети и прокси-службам.
Определите конечные точки входящих служб на сетевых схемах, к которым будет подключаться Microsoft 365 и другие службы Майкрософт, с отображением как интернета, так и предлагаемых путей подключения ExpressRoute.
Определите все географические расположения пользователей и подключение к глобальной сети между расположениями, а также то, в каких расположениях в настоящее время есть исходящий трафик в Интернет и в каких расположениях предлагается использовать исходящий трафик в расположение пиринга ExpressRoute.
Определите все пограничные устройства, такие как прокси-серверы, брандмауэры и т. д., и каталогизируйте их связь с потоками, передаваемыми через Интернет и ExpressRoute.
Задокументируйте, будут ли конечные пользователи получать доступ к службам Microsoft 365 через прямую маршрутизацию или непрямую прокси-службу приложения для потоков Интернета и ExpressRoute.
Добавьте расположение клиента и расположения meet-me в схему сети.
Оцените ожидаемые и наблюдаемые характеристики производительности сети и задержки из основных расположений пользователей в Microsoft 365. Помните, что Microsoft 365 — это глобальный и распределенный набор служб, и пользователи будут подключаться к расположениям, которые могут отличаться от расположения клиента. По этой причине рекомендуется измерять и оптимизировать задержку между пользователем и ближайшим краем глобальной сети Майкрософт через ExpressRoute и подключения к Интернету. Вы можете использовать результаты оценки сети, чтобы помочь в выполнении этой задачи.
Перечисление требований к безопасности сети компании и высокого уровня доступности, которые должны быть выполнены с новым подключением ExpressRoute. Например, как пользователи продолжают получать доступ к Microsoft 365 в случае сбоя исходящего трафика через Интернет или канала ExpressRoute.
Задокументируйте, какие входящие и исходящие сетевые потоки Microsoft 365 будут использовать путь к Интернету, а какие будут использовать ExpressRoute. Для конкретных географических расположений пользователей и сведений о топологии локальной сети может потребоваться, чтобы план отличались от одного расположения пользователя к другому.
Каталогизация исходящего и входящего сетевого трафика
Чтобы свести к минимуму маршрутизацию и другие сложности сети, рекомендуется использовать ExpressRoute для Microsoft 365 только для потоков сетевого трафика, которые должны проходить через выделенное подключение в соответствии с нормативными требованиями или в результате оценки сети. Кроме того, рекомендуется поэтапно область маршрутизации ExpressRoute и подходить к потокам исходящего и входящего сетевого трафика как к разным и отдельным этапам проекта реализации. Развертывание ExpressRoute для Microsoft 365 только для потоков исходящего сетевого трафика, инициированных пользователем, и сохранение потоков входящего сетевого трафика через Интернет может помочь контролировать увеличение топологической сложности и рисков, связанных с внедрением дополнительных асимметричных возможностей маршрутизации.
Каталог сетевого трафика должен содержать списки всех входящих и исходящих сетевых подключений, которые будут иметься между локальной сетью и корпорацией Майкрософт.
Потоки исходящего сетевого трафика — это любые сценарии, в которых подключение инициируется из локальной среды, например с внутренних клиентов или серверов, с назначением служб Майкрософт. Эти подключения могут быть прямыми к Microsoft 365 или косвенными, например через прокси-серверы, брандмауэры или другие сетевые устройства по пути к Microsoft 365.
Потоки входящего сетевого трафика — это любые сценарии, в которых подключение инициируется из облака Майкрософт к локальному узлу. Эти подключения обычно должны проходить через брандмауэр и другую инфраструктуру безопасности, которая требуется политике безопасности клиента для внешних потоков.
Прочтите раздел Обеспечение симметрии маршрутов , чтобы определить, какие службы будут отправлять входящий трафик, и найдите столбец с пометкой ExpressRoute для Microsoft 365 в справочной статье о конечных точках Microsoft 365 , чтобы определить остальные сведения о подключении.
Для каждой службы, для которой требуется исходящее подключение, необходимо описать запланированное подключение для службы, включая маршрутизацию сети, конфигурацию прокси-сервера, проверку пакетов и потребности в пропускной способности.
Для каждой службы, требующей входящего подключения, потребуются некоторые дополнительные сведения. Серверы в облаке Майкрософт будут устанавливать подключения к локальной сети. Чтобы убедиться, что подключения установлены правильно, необходимо описать все аспекты этого подключения, в том числе; общедоступные записи DNS для служб, которые будут принимать эти входящие подключения, IP-адреса IPv4 в формате CIDR, оборудование поставщика услуг Интернета, а также способ обработки NAT для входящего или исходного NAT для этих подключений.
Входящие подключения следует проверять независимо от того, подключаются ли они через Интернет или ExpressRoute, чтобы убедиться, что асимметричная маршрутизация не введена. В некоторых случаях к локальным конечным точкам, к которым службы Microsoft 365 инициируют входящие подключения, также может потребоваться доступ к другим службам Майкрософт и другим службам Майкрософт. Крайне важно, чтобы включение маршрутизации ExpressRoute к этим службам в Microsoft 365 не нарушалось другими сценариями. Во многих случаях клиентам может потребоваться реализовать определенные изменения во внутренней сети, например NAT на основе источника, чтобы обеспечить симметричность входящих потоков из Корпорации Майкрософт после включения ExpressRoute.
Ниже приведен пример требуемого уровня детализации. В этом случае Exchange Hybrid будет маршрутизировать в локальную систему через ExpressRoute.
| Свойство Connection | Значение |
|---|---|
| Направление сетевого трафика |
Входящих |
| Служба |
Гибридное развертывание Exchange |
| Общедоступная конечная точка Microsoft 365 (источник) |
Exchange Online (IP-адреса) |
| Общедоступная локальная конечная точка (назначение) |
5.5.5.5 |
| Общедоступная запись DNS (Интернет) |
Autodiscover.contoso.com |
| Будет ли эта локальная конечная точка использоваться другими (не microsoft 365) службами Майкрософт |
Нет |
| Будет ли эта локальная конечная точка использоваться пользователями и системами в Интернете |
Да |
| Внутренние системы, опубликованные через общедоступные конечные точки |
Exchange Server роль клиентского доступа (локальная версия) 192.168.101, 192.168.102, 192.168.103 |
| Объявление ОБ IP-адресе общедоступной конечной точки |
В Интернет: 5.5.0.0/16 в ExpressRoute: 5.5.5.0/24 |
| Элементы управления безопасностью и периметром |
Путь к Интернету: DeviceID_002 путь ExpressRoute: DeviceID_003 |
| Высокая доступность |
Активный и активный в двух геоизбыточных каналах ExpressRoute — Чикаго и Даллас |
| Элемент управления симметрией пути |
Метод. Путь к Интернету исходного NAT: входящие подключения к ExpressRoute 192.168.5.5: исходные подключения NAT к 192.168.1.0 (Чикаго) и 192.168.2.0 (Даллас) |
Ниже приведен пример службы, которая является только для исходящего трафика:
| Свойство Connection | Значение |
|---|---|
| Направление сетевого трафика |
Исходящий |
| Служба |
SharePoint |
| Локальная конечная точка (источник) |
Рабочая станция пользователя |
| Общедоступная конечная точка Microsoft 365 (назначение) |
SharePoint (IP-адреса) |
| Общедоступная запись DNS (Интернет) |
*.sharepoint.com (и другие полные доменные имена) |
| Рефералы CDN |
cdn.sharepointonline.com (и больше полных доменных имен) — IP-адреса, обслуживаемые поставщиками CDN; |
| Реклама IP-адресов и использование NAT |
Путь к Интернету/Исходный NAT: 1.1.1.0/24 ExpressRoute path/Source NAT: 1.1.2.0/24 (Чикаго) и 1.1.3.0/24 (Даллас) |
| Метод подключения |
Интернет: через прокси-сервер уровня 7 (PAC-файл) ExpressRoute: прямая маршрутизация (без прокси-сервера) |
| Элементы управления безопасностью и периметром |
Путь к Интернету: DeviceID_002 Путь к ExpressRoute: DeviceID_003 |
| Высокая доступность |
Путь к Интернету: избыточный исходящий интернет-трафик Путь ExpressRoute: активный и активный "горячий картофель" маршрутизация между 2 геоизбыточными каналами ExpressRoute - Чикаго и Даллас |
| Элемент управления симметрией пути |
Метод. Исходный NAT для всех подключений |
Проектирование топологии сети с региональным подключением
После того как вы узнаете о службах и связанных с ними потоках сетевого трафика, вы можете создать схему сети, включающую эти новые требования к подключению и проиллюстрирующие изменения, внесенные при использовании ExpressRoute для Microsoft 365. Схема должна включать в себя следующее:
Все расположения пользователей, из которых будет осуществляться доступ к Microsoft 365 и другим службам.
Все точки исходящего трафика Через Интернет и ExpressRoute.
Все исходящие и входящие устройства, которые управляют подключением в сети и из нее, включая маршрутизаторы, брандмауэры, прокси-серверы приложений, обнаружение и предотвращение вторжений.
Внутренние назначения для всего входящего трафика, например внутренние серверы ADFS, которые принимают подключения с прокси-серверов веб-приложений ADFS.
Каталог всех IP-подсетей, которые будут объявлены
Определите каждое расположение, из которого пользователи будут получать доступ к Microsoft 365, и перечислите места встречи, которые будут использоваться для ExpressRoute.
Расположения и части топологии внутренней сети, в которых префиксы IP-адресов Майкрософт, полученные из ExpressRoute, будут приниматься, фильтроваться и распространяться в.
Топология сети должна проиллюстрировать географическое расположение каждого сегмента сети и способ подключения к сети Майкрософт через ExpressRoute и (или) Интернет.
На схеме ниже показано каждое расположение, где пользователи будут использовать Microsoft 365, а также объявления о входящей и исходящей маршрутизации в Microsoft 365.
Для исходящего трафика пользователи получают доступ к Microsoft 365 одним из трех способов:
Через место встречи в Северная Америка для людей в Калифорнии.
Через место встречи в Гонконге Специальный административный район для людей в Гонконге САР.
Через Интернет в Бангладеш, где меньше людей и не подготовлен канал ExpressRoute.
Аналогичным образом входящий сетевой трафик из Microsoft 365 возвращается одним из трех способов:
Через место встречи в Северная Америка для людей в Калифорнии.
Через место встречи в Гонконге Специальный административный район для людей в Гонконге САР.
Через Интернет в Бангладеш, где меньше людей и не подготовлен канал ExpressRoute.
Определение соответствующего места встречи
Выбор расположений meet-me, которые представляют собой физическое расположение, где канал ExpressRoute подключает вашу сеть к сети Майкрософт, зависит от расположений, из которых пользователи будут получать доступ к Microsoft 365. Как предложение SaaS, Microsoft 365 работает не в рамках региональной модели IaaS или PaaS, как в Azure. Вместо этого Microsoft 365 — это распределенный набор служб совместной работы, где пользователям может потребоваться подключаться к конечным точкам в нескольких центрах обработки данных и регионах, которые могут не обязательно находиться в том же расположении или регионе, где размещен клиент пользователя.
Это означает, что при выборе мест встречи для ExpressRoute для Microsoft 365 необходимо учитывать, где будут подключаться люди в вашей организации. Общая рекомендация для оптимального подключения к Microsoft 365 заключается в реализации маршрутизации, чтобы запросы пользователей к службам Microsoft 365 передавалися в сеть Майкрософт по кратчайшему сетевому пути. Это также часто называют маршрутизацией "горячий картофель". Например, если большинство пользователей Microsoft 365 находятся в одном или двух местах, выбор расположений meet-me, которые находятся в непосредственной близости к расположению этих пользователей, создаст оптимальную структуру. Если ваша компания имеет большое число пользователей во многих разных регионах, вы можете рассмотреть возможность наличия нескольких каналов ExpressRoute и расположений для встреч. Для некоторых расположений пользователей самый короткий или оптимальный путь к сети Майкрософт и Microsoft 365 может быть не через внутреннюю глобальную сеть и точки встречи ExpressRoute, а через Интернет.
Часто существует несколько расположений для встреч, которые можно выбрать в регионе с относительной близостью к пользователям. Заполните следующую таблицу, чтобы принять решения.
Запланированные места встречи ExpressRoute в Калифорнии и Нью-йорке
| Расположение |
Количество людей |
Ожидаемая задержка в сети Майкрософт через исходящий трафик Через Интернет |
Ожидаемая задержка в сети Майкрософт через ExpressRoute |
|---|---|---|---|
| Лос-Анджелес |
10,000 |
~15 мс |
~10 мс (через Силиконовую долину) |
| Вашингтон |
15 000 |
~20 мс |
~10 мс (через Нью-йорк) |
| Даллас |
5,000 |
~15 мс |
~40 мс (через Нью-йорк) |
После разработки глобальной сетевой архитектуры, показывающей регион Microsoft 365, расположение поставщика сетевых служб ExpressRoute и количество людей по расположению, ее можно использовать для определения возможности оптимизации. Он также может отображать глобальные сетевые подключения шпильки, где трафик направляется в удаленное расположение, чтобы получить расположение встречи. Если обнаружена шпилька в глобальной сети, ее следует исправить, прежде чем продолжить. Либо найдите другое место встречи, либо используйте выборочные точки интернет-прорыва исходящего трафика, чтобы избежать шпильки.
На первой схеме показан пример клиента с двумя физическими расположениями в Северная Америка. Вы можете просмотреть сведения о расположении офисов, расположениях клиентов Microsoft 365 и нескольких вариантах расположения для встреч ExpressRoute. В этом примере клиент выбрал место встречи на основе двух принципов в порядке:
Ближайшее расположение к людям в организации.
Ближайший к центру обработки данных Майкрософт, в котором размещена Microsoft 365.
Если расширить эту концепцию немного дальше, на второй схеме показан пример мультинационного клиента, столкнувшись с аналогичной информацией и принятием решений. Этот клиент имеет небольшой офис в Бангладеш с небольшой командой из 10 человек, сосредоточенной на росте своего места в регионе. В Ченнаи есть место для встречи и центр обработки данных Майкрософт с Microsoft 365, размещенный в Ченнае, поэтому место встречи было бы целесообразно. однако для 10 человек расходы на дополнительную цепь обременительна. При просмотре сети необходимо определить, является ли задержка, связанная с отправкой сетевого трафика по сети, более эффективной, чем тратить капитал на приобретение другого канала ExpressRoute.
Кроме того, 10 человек в Бангладеш могут повысить производительность сетевого трафика, отправляемого через Интернет в сеть Майкрософт, чем маршрутизация по внутренней сети, как показано на вводных схемах и воспроизведенных ниже.
Create план реализации ExpressRoute для Microsoft 365
План реализации должен включать как технические сведения о настройке ExpressRoute, так и сведения о настройке всей другой инфраструктуры в сети, например следующее.
Планирование служб, разделенных между ExpressRoute и Интернетом.
Планируйте пропускную способность, безопасность, высокий уровень доступности и отработку отказа.
Проектирование входящей и исходящей маршрутизации, включая правильную оптимизацию пути маршрутизации для разных расположений
Определите, как далеко будут объявлены маршруты ExpressRoute в вашей сети и какой механизм для клиентов может выбрать путь к Интернету или ExpressRoute; например, прямая маршрутизация или прокси приложения.
Планирование изменений записей DNS, включая записи платформы политики отправителей .
Планирование стратегии NAT, включая NAT для исходящего и входящего источника.
Планирование маршрутизации с помощью сетевых путей Через Интернет и ExpressRoute
Для первоначального развертывания всем входящим службам, таким как входящая электронная почта или гибридное подключение, рекомендуется использовать Интернет.
Спланируйте маршрутизацию по локальной сети конечного пользователя, например настройте файл PAC/WPAD, маршрут по умолчанию, прокси-серверы и объявления маршрутов BGP.
Планирование маршрутизации периметра, включая прокси-серверы, брандмауэры и облачные прокси-серверы.
Планирование пропускной способности, безопасности, высокого уровня доступности и отработки отказа
Create план пропускной способности, необходимой для каждой основной рабочей нагрузки Microsoft 365. Отдельно оцените требования к пропускной способности Exchange Online, SharePoint и Skype для бизнеса Online. В качестве отправной точки можно использовать калькуляторы оценки, которые мы предоставили для Exchange Online и Skype для бизнеса. Однако для полного понимания потребностей вашей организации в пропускной способности требуется пробное тестирование с репрезентативной выборкой профилей пользователей и расположений.
Добавьте в план способ обеспечения безопасности в каждом расположении исходящего трафика Через Интернет и ExpressRoute, помните, что все подключения ExpressRoute к Microsoft 365 используют общедоступный пиринг и по-прежнему должны быть защищены в соответствии с политиками безопасности вашей компании при подключении к внешним сетям.
Добавьте в свой план сведения о том, какие люди будут затронуты сбоем и как эти люди смогут выполнять свою работу на полную мощность самым простым способом.
Планирование требований к пропускной способности, включая требования к Skype для бизнеса для Jitter, задержки, перегрузки и головного места
Skype для бизнеса Online также имеет особые дополнительные требования к сети, которые подробно описаны в статье Качество мультимедиа и производительность сетевого подключения в Skype для бизнеса Online.
Ознакомьтесь с разделом Планирование пропускной способности для Azure ExpressRoute. При оценке пропускной способности с пилотными пользователями можно использовать наше руководство по настройке производительности Microsoft 365 с помощью базовых показателей и журнала производительности.
Планирование требований к высокой доступности
Create план высокого уровня доступности в соответствии с вашими потребностями и включить его в обновленную схему топологии сети. Ознакомьтесь с разделом Высокий уровень доступности и отработка отказа с помощью Azure ExpressRoute.
Планирование требований к безопасности сети
Create план в соответствии с требованиями к безопасности сети и включите его в обновленную схему топологии сети. Ознакомьтесь с разделом Применение элементов управления безопасностью к Azure ExpressRoute для сценариев Microsoft 365.
Проектирование исходящих подключений к службе
ExpressRoute для Microsoft 365 имеет требования к исходящей сети, которые могут быть незнакомы. В частности, IP-адреса, представляющие пользователей и сети в Microsoft 365 и выступающие в качестве исходных конечных точек для исходящих сетевых подключений к Корпорации Майкрософт, должны соответствовать определенным требованиям, описанным ниже.
Конечные точки должны быть общедоступными IP-адресами, которые зарегистрированы в вашей компании или для оператора, предоставляющего вам подключение к ExpressRoute.
Конечные точки должны быть объявлены в Корпорации Майкрософт и проверены или приняты ExpressRoute.
Конечные точки не должны объявляться в Интернете с той же или более предпочтительной метрикой маршрутизации.
Конечные точки не должны использоваться для подключения к службам Майкрософт, которые не настроены через ExpressRoute.
Если ваша сетевая конструкция не соответствует этим требованиям, существует высокий риск того, что пользователи будут сталкиваться со сбоями подключения к Microsoft 365 и другим службам Майкрософт из-за "черной" или асимметричной маршрутизации. Это происходит, когда запросы к службам Майкрософт направляются через ExpressRoute, но ответы направляются обратно через Интернет или наоборот, а ответы удаляются сетевыми устройствами с отслеживанием состояния, такими как брандмауэры.
Наиболее распространенным способом, который можно использовать для удовлетворения указанных выше требований, является использование исходного NAT, реализованного как часть сети или предоставляемого оператором ExpressRoute. Исходный NAT позволяет абстрагировать сведения и частные IP-адреса вашей интернет-сети из ExpressRoute и; В сочетании с соответствующими объявлениями IP-маршрутов обеспечивают простой механизм обеспечения симметрии пути. Если вы используете сетевые устройства с отслеживанием состояния, относящиеся к расположениям пиринга ExpressRoute, необходимо реализовать отдельные пулы NAT для каждого пиринга ExpressRoute, чтобы обеспечить симметрию пути.
Ознакомьтесь с дополнительными сведениями о требованиях к NAT ExpressRoute.
Добавьте изменения для исходящего подключения на схему топологии сети.
Проектирование подключения к входящей службе
Большинство корпоративных развертываний Microsoft 365 предполагают некоторую форму входящего подключения из Microsoft 365 к локальным службам, например для сценариев Exchange, SharePoint и Skype для бизнеса гибридных сценариев, миграции почтовых ящиков и проверки подлинности с использованием инфраструктуры ADFS. Если expressRoute включает дополнительный путь маршрутизации между локальной сетью и корпорацией Майкрософт для исходящего подключения, на эти входящие подключения может случайно повлиять асимметричная маршрутизация, даже если вы планируете, чтобы эти потоки продолжали использовать Интернет. Ниже описаны некоторые меры предосторожности, чтобы не повлиять на входящие потоки из Интернета из Microsoft 365 в локальные системы.
Чтобы свести к минимуму риски асимметричной маршрутизации для потоков входящего сетевого трафика, все входящие подключения должны использовать исходный NAT, прежде чем они будут перенаправлены в сегменты сети, которые имеют видимость маршрутизации в ExpressRoute. Если входящие подключения разрешены к сегменту сети с видимостью маршрутизации в ExpressRoute без исходного NAT, запросы, исходящие из Microsoft 365, будут поступать из Интернета, но ответ, возвращающийся в Microsoft 365, будет предпочитать сетевой путь ExpressRoute обратно в сеть Майкрософт, что приводит к асимметричной маршрутизации.
Для удовлетворения этого требования можно рассмотреть один из следующих шаблонов реализации:
Выполните NAT источника, прежде чем запросы будут перенаправлены во внутреннюю сеть с помощью сетевого оборудования, такого как брандмауэры или подсистемы балансировки нагрузки, по пути из Интернета в локальные системы.
Убедитесь, что маршруты ExpressRoute не распространяются на сегменты сети, в которых находятся входящие службы, такие как интерфейсные серверы или системы обратных прокси-серверов, обрабатывающие подключения к Интернету.
Явный учет этих сценариев в сети и сохранение всех потоков входящего сетевого трафика через Интернет помогает свести к минимуму риск развертывания и эксплуатации асимметричной маршрутизации.
В некоторых случаях вы можете направить некоторые входящие потоки через подключения ExpressRoute. Для этих сценариев следует учитывать следующие дополнительные аспекты.
Microsoft 365 может ориентироваться только на локальные конечные точки, использующие общедоступные IP-адреса. Это означает, что даже если локальная входящая конечная точка предоставляется только Microsoft 365 через ExpressRoute, с ней по-прежнему должен быть связан общедоступный IP-адрес.
Все разрешения DNS-имен, выполняемые службами Microsoft 365 для разрешения локальных конечных точек, выполняются с помощью общедоступной службы DNS. Это означает, что необходимо зарегистрировать полное доменное имя конечных точек входящей службы для сопоставлений IP-адресов в Интернете.
Чтобы получать входящие сетевые подключения через ExpressRoute, общедоступные IP-подсети для этих конечных точек должны быть объявлены в Корпорации Майкрософт через ExpressRoute.
Тщательно оцените эти потоки входящего сетевого трафика, чтобы убедиться, что к ним применяются надлежащие средства безопасности и сетевые элементы управления в соответствии с корпоративными политиками безопасности и сетевыми политиками.
Как только локальные входящие конечные точки будут объявлены в Майкрософт через ExpressRoute, ExpressRoute фактически станет предпочтительным путем маршрутизации к этим конечным точкам для всех служб Майкрософт, включая Microsoft 365. Это означает, что эти подсети конечных точек должны использоваться только для связи со службами Microsoft 365 и никакими другими службами в сети Майкрософт. В противном случае ваша схема приведет к асимметричной маршрутизации, когда входящие подключения из других служб Майкрософт предпочитают маршрутизировать входящий трафик через ExpressRoute, а обратный путь будет использовать Интернет.
Если канал ExpressRoute или расположение meet-me не работает, необходимо убедиться, что локальные входящие конечные точки по-прежнему доступны для приема запросов по отдельному сетевому пути. Это может означать рекламу подсетей для этих конечных точек через несколько каналов ExpressRoute.
Мы рекомендуем применять исходный NAT для всех потоков входящего сетевого трафика, входящих в сеть через ExpressRoute, особенно если эти потоки пересекаются сетевыми устройствами с отслеживанием состояния, такими как брандмауэры.
Некоторые локальные службы, такие как прокси-сервер ADFS или автоматическое обнаружение Exchange, могут получать входящие запросы как от служб Microsoft 365, так и от пользователей из Интернета. Для этих запросов Microsoft 365 будет ориентироваться на то же полное доменное имя, что и запросы пользователей через Интернет. Разрешение входящих подключений пользователей из Интернета к этим локальным конечным точкам, принудив подключения Microsoft 365 использовать ExpressRoute, представляет собой значительную сложность маршрутизации. Для подавляющего большинства клиентов реализация таких сложных сценариев через ExpressRoute не рекомендуется из-за операционных соображений. Эти дополнительные издержки включают в себя управление рисками асимметричной маршрутизации и потребуют тщательного управления объявлениями и политиками маршрутизации в нескольких измерениях.
Обновите план топологии сети, чтобы показать, как избежать асимметричных маршрутов
Вы хотите избежать асимметричной маршрутизации, чтобы пользователи в вашей организации могли легко использовать Microsoft 365, а также другие важные службы в Интернете. Существует две распространенные конфигурации клиентов, которые вызывают асимметричную маршрутизацию. Теперь самое время изучить конфигурацию сети, которую вы планируете использовать, и проверка, если может существовать один из этих сценариев асимметричной маршрутизации.
Для начала мы рассмотрим несколько различных ситуаций, связанных с следующей схемой сети. На этой схеме все серверы, получающие входящие запросы, такие как ADFS или локальные гибридные серверы, находятся в центре обработки данных Нью-Джерси и объявляются в Интернете.
Хотя сеть периметра защищена, для входящих запросов нет доступного NAT источника.
Серверы в центре обработки данных Нью-Джерси могут видеть как маршруты Через Интернет, так и ExpressRoute.
У нас также есть предложения по их устранению.
Проблема 1. Подключение между облаком и локальной средой через Интернет
На следующей схеме показан асимметричный сетевой путь, выполняемый, когда конфигурация сети не предоставляет NAT для входящих запросов из облака Майкрософт через Интернет.
Входящий запрос от Microsoft 365 получает IP-адрес локальной конечной точки из общедоступной DNS и отправляет запрос в сеть периметра.
В этой неисправной конфигурации в сети периметра, куда отправляется трафик, не настроен или доступен исходный NAT, что приводит к тому, что фактический исходный IP-адрес используется в качестве назначения возврата.
Сервер в сети направляет обратный трафик в Microsoft 365 через любое доступное сетевое подключение ExpressRoute.
Результатом является асимметричный путь для этого потока в Microsoft 365, что приводит к разрыву подключения.
Решение 1a. Исходный NAT
Простое добавление исходного NAT во входящий запрос разрешает эту неправильно настроенную сеть. На этой схеме:
Входящий запрос продолжает поступать через сеть периметра центра обработки данных Нью-Джерси. На этот раз доступен исходный NAT.
Ответ от сервера направляется обратно к IP-адресу, связанному с исходным NAT, а не к исходному IP-адресу, в результате чего ответ возвращается по тому же сетевому пути.
Решение 1b. Определение области маршрутов
Кроме того, можно запретить объявление префиксов BGP ExpressRoute, удалив альтернативный сетевой путь для этих компьютеров. На этой схеме:
Входящий запрос продолжает поступать через сеть периметра центра обработки данных Нью-Джерси. На этот раз префиксы, объявленные корпорацией Майкрософт по каналу ExpressRoute, недоступны для центра обработки данных в Нью-Джерси.
Ответ сервера направляется обратно к IP-адресу, связанному с исходным IP-адресом, по единственному доступному маршруту, в результате чего ответ возвращается по тому же сетевому пути.
Проблема 2. Подключение между облаком и локальной средой через ExpressRoute
На следующей схеме показан асимметричный сетевой путь, выполняемый, когда конфигурация сети не предоставляет NAT для входящих запросов из облака Майкрософт через ExpressRoute.
Входящий запрос от Microsoft 365 получает IP-адрес из DNS и отправляет запрос в сеть периметра.
В этой неисправной конфигурации в сети периметра, куда отправляется трафик, не настроен или доступен исходный NAT, что приводит к тому, что фактический исходный IP-адрес используется в качестве назначения возврата.
Компьютер в сети направляет обратный трафик в Microsoft 365 через любое доступное сетевое подключение ExpressRoute.
Результатом является асимметричное подключение к Microsoft 365.
Решение 2. Исходный NAT
Простое добавление исходного NAT во входящий запрос разрешает эту неправильно настроенную сеть. На этой схеме:
Входящий запрос продолжает поступать через сеть периметра нью-йоркского центра обработки данных. На этот раз доступен исходный NAT.
Ответ от сервера направляется обратно к IP-адресу, связанному с исходным NAT, а не к исходному IP-адресу, в результате чего ответ возвращается по тому же сетевому пути.
На бумаге убедитесь, что схема сети имеет симметрию пути
На этом этапе необходимо проверить на бумаге, что план реализации предлагает симметрию маршрутов для различных сценариев, в которых вы будете использовать Microsoft 365. Вы определите конкретный сетевой маршрут, который, как ожидается, будет выполняться, когда пользователь использует различные функции службы. От локальной сети и маршрутизации глобальной сети, устройств периметра до пути подключения; ExpressRoute или Интернет и подключение к сетевой конечной точке.
Это необходимо сделать для всех сетевых служб Microsoft 365, которые ранее были определены как службы, которые будут приняты вашей организацией.
Это помогает сделать этот документ пошаговое руководство по маршрутам со вторым лицом. Объясните им, где ожидается, что каждый сетевой прыжок будет получать свой следующий маршрут, и убедитесь, что вы знакомы с путями маршрутизации. Помните, что ExpressRoute всегда предоставляет более широкий маршрут к IP-адресам сервера Майкрософт, что дает более низкую стоимость маршрута, чем маршрут по умолчанию для Интернета.
Проектирование конфигурации подключения клиента
Если вы используете прокси-сервер для трафика, связанного с Интернетом, необходимо настроить все файлы конфигурации PAC или клиента, чтобы убедиться, что клиентские компьютеры в сети правильно настроены для отправки трафика ExpressRoute в Microsoft 365 без передачи прокси-сервера, а оставшийся трафик, включая некоторый трафик Microsoft 365, отправляется на соответствующий прокси-сервер. Ознакомьтесь с нашим руководством по управлению конечными точками Microsoft 365, например PAC-файлами.
Примечание.
Конечные точки меняются часто, так же часто, как еженедельно. Вы должны вносить изменения только на основе служб и функций, принятых вашей организацией, чтобы уменьшить количество изменений, которые необходимо внести, чтобы оставаться актуальными. Обратите особое внимание на дату вступления в силу в RSS-канале, где объявлены изменения и сохраняется запись обо всех прошлых изменениях. Объявленные IP-адреса не могут быть объявлены или удалены из объявления до достижения даты вступления в силу.
Обеспечение симметрии маршрутов
Интерфейсные серверы Microsoft 365 доступны как в Интернете, так и в ExpressRoute. Эти серверы предпочтут маршрутизировать обратно в локальную среду через каналы ExpressRoute, если они доступны. Из-за этого существует вероятность асимметрии маршрутов, если трафик из вашей сети предпочитает маршрутизировать через интернет-каналы. Асимметричные маршруты — это проблема, так как устройства, выполняющие проверку пакетов с отслеживанием состояния, могут блокировать обратный трафик, который следует по пути, отличному от пути исходящих пакетов.
Независимо от того, инициируете ли вы подключение к Microsoft 365 через Интернет или ExpressRoute, источником должен быть общедоступный маршрутизируемый адрес. Если многие клиенты пиринговой связи напрямую с Корпорацией Майкрософт, то наличие частных адресов, где возможно дублирование между клиентами, нецелесообразно.
Ниже приведены сценарии, в которых инициируется обмен данными из Microsoft 365 с локальной сетью. Чтобы упростить структуру сети, рекомендуется выполнить маршрутизацию по интернету.
Службы SMTP, такие как почта из клиента Exchange Online на локальный узел или почта SharePoint, отправленная из SharePoint на локальный узел. Протокол SMTP используется в сети Майкрософт более широко, чем префиксы маршрутов, совместно используемые по каналам ExpressRoute, и реклама локальных SMTP-серверов через ExpressRoute приведет к сбоям с этими другими службами.
ADFS во время проверки пароля для входа.
Skype для бизнеса гибридной и (или) Skype для бизнеса федерации.
Чтобы корпорация Майкрософт направляла эти двунаправленные потоки трафика обратно в вашу сеть, маршруты BGP на локальные устройства должны быть совместно переданы корпорации Майкрософт. При объявлении префиксов маршрутов в Майкрософт через ExpressRoute следует следовать следующим рекомендациям:
Не объявляйте один и тот же префикс общедоступного IP-адреса в общедоступном Интернете и через ExpressRoute. Рекомендуется, чтобы объявления префиксов маршрутов IP BGP в Майкрософт через ExpressRoute были из диапазона, который вообще не рекламируется в Интернете. Если этого не удается достичь из-за свободного пространства IP-адресов, важно убедиться, что вы объявляете более конкретный диапазон через ExpressRoute, чем любые интернет-каналы.
Используйте отдельные пулы IP-адресов NAT для каждого канала ExpressRoute и отдельно от сети Интернет.
Любой маршрут, объявленный корпорации Майкрософт, будет привлекать сетевой трафик с любого сервера в сети Майкрософт, а не только с тех, для которых маршруты объявляются в вашей сети через ExpressRoute. Объявляйте маршруты только на серверах, где сценарии маршрутизации определены и хорошо изучены вашей командой. Объявление отдельных префиксов маршрутов IP-адресов в каждом из нескольких каналов ExpressRoute из сети.
Высокий уровень доступности и отработка отказа с помощью Azure ExpressRoute
Рекомендуется подготовить по крайней мере два активных канала из каждого исходящего трафика с помощью ExpressRoute к поставщику ExpressRoute. Это наиболее распространенное место, где мы видим сбои для клиентов, и вы можете легко избежать этого, подготовив пару каналов ExpressRoute "активный/активный". Мы также рекомендуем использовать по крайней мере два активных канала Интернета, так как многие службы Microsoft 365 доступны только через Интернет.
В точке исходящего трафика сети находится множество других устройств и каналов, которые играют важную роль в том, как люди воспринимают доступность. Эти части сценариев подключения не охватываются Соглашениями об уровне обслуживания ExpressRoute или Microsoft 365, но они играют важную роль в доступности комплексных служб, как это воспринимается сотрудниками вашей организации.
Сосредоточьтесь на людях, использующих и работающих с Microsoft 365. Если сбой одного компонента повлияет на опыт пользователей, использующих службу, найдите способы ограничения общего процента затронутых пользователей. Если режим отработки отказа является операционным комплексом, рассмотрите опыт пользователей, который долгое время восстанавливается, и найдите простые в эксплуатации и автоматические режимы отработки отказа.
За пределами сети Microsoft 365, ExpressRoute и поставщик ExpressRoute имеют разные уровни доступности.
Доступность службы
Службы Microsoft 365 охватываются четко определенными соглашениями об уровне обслуживания, которые включают метрики времени доступности и времени доступности для отдельных служб. Одной из причин, по которой Microsoft 365 может поддерживать такие высокие уровни доступности служб, является возможность для отдельных компонентов легко выполнять отработку отказа между многими центрами обработки данных Майкрософт с помощью глобальной сети Майкрософт. Эта отработка отказа распространяется из центра обработки данных и сети на несколько точек исходящего интернет-трафика и обеспечивает беспроблемную отработку отказа с точки зрения пользователей службы.
ExpressRoute обеспечивает 99,9 % доступности соглашения об уровне обслуживания для отдельных выделенных каналов между Microsoft Network Edge и поставщиком ExpressRoute или партнерской инфраструктурой. Эти уровни обслуживания применяются на уровне канала ExpressRoute, который состоит из двух независимых соединений между избыточным оборудованием Майкрософт и оборудованием поставщика сети в каждом расположении пиринга.
Доступность поставщика
- Соглашения об уровне обслуживания Корпорации Майкрософт останавливаются на поставщике ExpressRoute или партнере. Это также первое место, где вы можете сделать выбор, который будет влиять на уровень доступности. Следует внимательно оценить характеристики архитектуры, доступности и устойчивости, которые предлагает поставщик ExpressRoute между периметром сети и подключением поставщиков в каждом расположении пиринга Майкрософт. Обратите особое внимание на логические и физические аспекты избыточности, пиринговое оборудование, каналы глобальной сети, предоставляемые оператором, и любые дополнительные службы, такие как службы NAT или управляемые брандмауэры.
Разработка плана доступности
Настоятельно рекомендуется планировать и проектировать высокий уровень доступности и устойчивости в комплексных сценариях подключения к Microsoft 365. Конструкция должна включать в себя;
Нет отдельных точек сбоя, включая каналы Internet и ExpressRoute.
Минимизация числа затронутых пользователей и продолжительности этого воздействия для большинства ожидаемых режимов сбоя.
Оптимизация для простого, повторяемого и автоматического процесса восстановления из большинства ожидаемых режимов сбоя.
Поддержка всех требований к сетевому трафику и функциональности через избыточные пути без существенного ухудшения.
Сценарии подключения должны включать топологию сети, оптимизированную для нескольких независимых и активных сетевых путей к Microsoft 365. Это обеспечит более эффективную сквозную доступность, чем топология, оптимизированная только для избыточности на уровне отдельного устройства или оборудования.
Совет
Если пользователи распределены по нескольким континентам или географическим регионам и каждое из этих расположений подключается через избыточные каналы глобальной сети к одному локальному расположению, где расположен один канал ExpressRoute, пользователи будут испытывать меньшую сквозную доступность службы, чем топология сети, которая включает независимые каналы ExpressRoute, которые соединяют различные регионы с ближайшим пиринговым расположением.
Рекомендуется подготовить по крайней мере два канала ExpressRoute с подключением к каждому каналу с разным географическим расположением пиринга. Эту пару каналов "активный— активный" следует подготовить для каждого региона, где пользователи будут использовать подключение ExpressRoute для служб Microsoft 365. Это позволяет каждому региону оставаться подключенным во время аварии, которая влияет на основное расположение, например центр обработки данных или расположение пиринга. Настройка их в как активные и активные позволяет распределить трафик конечных пользователей по нескольким сетевым путям. Это снижает область людей, пострадавших во время простоя устройства или сетевого оборудования.
Не рекомендуется использовать один канал ExpressRoute с Интернетом в качестве резервной копии.
Пример: отработка отказа и высокий уровень доступности
Мульти-географический проект Contoso прошел проверку маршрутизации, пропускной способности, безопасности и теперь должен пройти проверку высокого уровня доступности. Компания Contoso считает, что высокий уровень доступности охватывает три категории. устойчивость, надежность и избыточность.
Устойчивость позволяет компании Contoso быстро восстанавливаться после сбоев. Надежность позволяет компании Contoso обеспечить согласованный результат в системе. Избыточность позволяет Contoso перемещаться между одним или несколькими зеркальными экземплярами инфраструктуры.
В каждой пограничной конфигурации у contoso есть избыточные брандмауэры, прокси-серверы и идентификаторы. Для Северная Америка contoso имеет одну конфигурацию ребер в центре обработки данных Далласа, а другую — в центре обработки данных в Вирджинии. Избыточное оборудование в каждом расположении обеспечивает устойчивость к такому расположению.
Конфигурация сети в Contoso основана на нескольких ключевых принципах:
В каждом географическом регионе есть несколько каналов Azure ExpressRoute.
Каждый канал в регионе может поддерживать весь сетевой трафик в этом регионе.
Маршрутизация явно будет предпочитать один или другой путь в зависимости от доступности, расположения и т. д.
Отработка отказа между каналами Azure ExpressRoute происходит автоматически без дополнительных настроек или действий, необходимых для contoso.
Отработка отказа между интернет-каналами происходит автоматически без дополнительных настроек или действий, необходимых компании Contoso.
В этой конфигурации с избыточностью на физическом и виртуальном уровнях компания Contoso может обеспечить надежную локальную устойчивость, региональную устойчивость и глобальную устойчивость. Компания Contoso выбрала эту конфигурацию после оценки одного канала Azure ExpressRoute для каждого региона, а также возможности отработки отказа в Интернет.
Если компании Contoso не удавалось иметь несколько каналов Azure ExpressRoute для каждого региона, маршрутизация трафика, исходя из Северная Америка в канал Azure ExpressRoute в Азиатско-Тихоокеанском регионе, добавит неприемлемый уровень задержки, а требуемая конфигурация dns-сервера пересылки усложняет.
Не рекомендуется использовать Интернет в качестве конфигурации резервного копирования. Это нарушает принцип надежности Компании Contoso, что приводит к несогласованности при использовании подключения. Кроме того, для отработки отказа потребуется ручная настройка с учетом настроенных объявлений BGP, конфигурации NAT, конфигурации DNS и конфигурации прокси-сервера. Эта сложность отработки отказа увеличивает время восстановления и снижает их способность диагностировать и устранять неполадки.
У вас остались вопросы о планировании и реализации управления трафиком или Azure ExpressRoute? Ознакомьтесь с остальными рекомендациями по работе с сетью и производительностью или часто задаваемыми вопросами об Azure ExpressRoute.
Применение элементов управления безопасностью к Azure ExpressRoute для сценариев Microsoft 365
Защита подключения Azure ExpressRoute начинается с того же принципа, что и защита подключения к Интернету. Многие клиенты предпочитают развертывать элементы управления сетью и периметром по пути ExpressRoute, подключая локальную сеть к Microsoft 365 и другим облакам Майкрософт. Эти элементы управления могут включать брандмауэры, прокси-серверы приложений, предотвращение утечки данных, обнаружение вторжений, системы защиты от вторжений и т. д. Во многих случаях клиенты применяют различные уровни управления к трафику, инициированному из локальной среды в Корпорацию Майкрософт, по сравнению с трафиком, инициированным корпорацией Майкрософт в локальную сеть клиента, и к трафику, инициированному из локальной среды, к общему интернет-назначению.
Ниже приведено несколько примеров интеграции безопасности с моделью подключения ExpressRoute , которую вы решили развернуть.
| Параметр интеграции ExpressRoute | Модель периметра сетевой безопасности |
|---|---|
| Совместное размещение на облачной бирже |
Установите новую или используйте существующую инфраструктуру безопасности или периметра в объекте совместного размещения, где установлено подключение ExpressRoute. Используйте средство совместного размещения исключительно для целей маршрутизации и взаимодействия, а также обратного перемещения подключений из совместного размещения в локальную инфраструктуру безопасности и периметра. |
| Ethernet типа "точка — точка" |
Завершите подключение ExpressRoute типа "точка — точка" в существующем локальном расположении инфраструктуры безопасности или периметра. Установите новую инфраструктуру безопасности и периметра, относящийся к пути ExpressRoute, и завершите подключение "точка — точка". |
| IPVPN "любой к любому" |
Используйте существующую локальную инфраструктуру безопасности и периметра во всех расположениях, которая отправляется в IPVPN, используемый для ExpressRoute для подключения Microsoft 365. Прикрепить IPVPN, используемый для ExpressRoute для Microsoft 365, к определенным локальным расположениям, предназначенным для обеспечения безопасности или периметра. |
Некоторые поставщики услуг также предлагают функции управляемой безопасности и периметра в рамках своих решений интеграции с Azure ExpressRoute.
При рассмотрении размещения топологии параметров периметра сети и безопасности, используемых для ExpressRoute для подключений Microsoft 365, ниже приведены дополнительные рекомендации.
Элементы управления глубиной и типом сети и безопасностью могут влиять на производительность и масштабируемость пользовательского интерфейса Microsoft 365.
Исходящие потоки> (локальная среда Майкрософт) и входящие (локальная среда Майкрософт>) [если они включены] могут иметь разные требования. Они, скорее всего, отличаются от исходящих для общих назначений в Интернете.
Требования Microsoft 365 к портам и протоколам и необходимым IP-подсетям одинаковы, независимо от того, направляется ли трафик через ExpressRoute для Microsoft 365 или через Интернет.
Топологическое размещение элементов управления сетью и безопасностью клиента определяет конечный конец сети между пользователем и службой Microsoft 365 и может существенно повлиять на задержку и перегрузку сети.
Клиентам рекомендуется разработать топологию безопасности и периметра для использования с ExpressRoute для Microsoft 365 в соответствии с рекомендациями по избыточности, высокому уровню доступности и аварийному восстановлению.
Ниже приведен пример contoso, который сравнивает различные варианты подключения Azure ExpressRoute с моделями безопасности периметра, описанными выше.
Пример. Защита Azure ExpressRoute
Компания Contoso рассматривает возможность реализации Azure ExpressRoute и после планирования оптимальной архитектуры для ExpressRoute для Microsoft 365 и использования приведенных выше рекомендаций для понимания требований к пропускной способности она определяет оптимальный метод защиты периметра.
Для contoso, мультинациональная организация с расположениями на нескольких континентах, безопасность должна охватывать все периметры. Оптимальным вариантом подключения для Contoso является подключение с несколькими точками с несколькими точками пиринга по всему миру для удовлетворения потребностей своих сотрудников на каждом континенте. Каждый континент включает избыточные каналы Azure ExpressRoute на континенте, и безопасность должна охватывать все эти каналы.
Существующая инфраструктура Contoso надежна и может выполнять дополнительную работу. В результате компания Contoso может использовать ее для обеспечения безопасности периметра Azure ExpressRoute и Интернета. Если бы это не так, компания Contoso могла бы приобрести дополнительное оборудование, чтобы дополнить существующее оборудование или для обработки другого типа подключения.
Планирование пропускной способности для Azure ExpressRoute
Каждый клиент Microsoft 365 имеет уникальные потребности в пропускной способности в зависимости от количества пользователей в каждом расположении, их активности с каждым приложением Microsoft 365 и других факторов, таких как использование локального или гибридного оборудования и конфигураций безопасности сети.
Слишком малая пропускная способность приведет к перегрузке, повторной отправке данных и непредсказуемым задержкам. Слишком большая пропускная способность приведет к ненужным затратам. В существующей сети пропускную способность часто называют с точки зрения объема доступного запаса в канале в процентах. Наличие 10 % запаса, скорее всего, приведет к перегрузке и 80 % запаса, как правило, означает ненужные затраты. Типичные целевые целевые ресурсы головного пространства — от 20% до 50%.
Чтобы найти правильный уровень пропускной способности, лучший механизм — протестировать существующее потребление сети. Это единственный способ получить истинную меру использования и потребности, так как каждая сетевая конфигурация и приложения в некотором смысле уникальны. При измерении необходимо уделить пристальное внимание общему потреблению пропускной способности, задержке и перегрузке TCP, чтобы понять потребности сети.
После того как вы получите предполагаемый базовый план, включающий все сетевые приложения, опробуйте Microsoft 365 с небольшой группой, включающей различные профили сотрудников в вашей организации, чтобы определить фактическое использование, и использовать два измерения для оценки объема пропускной способности, необходимого для каждого расположения офиса. Если в тестировании обнаружены проблемы с задержкой или перегрузкой TCP, может потребоваться переместить исходящий трафик ближе к пользователям, использующим Microsoft 365, или удалить интенсивное сканирование сети, например расшифровку и проверку SSL.
Все наши рекомендации о том, какой тип обработки сети рекомендуется применять как к каналам ExpressRoute, так и к Интернету. То же самое относится и к остальным рекомендациям на нашем сайте по настройке производительности.
Создание процедур развертывания и тестирования
План реализации должен включать в себя планирование тестирования и отката. Если реализация работает не так, как ожидалось, план должен быть разработан таким образом, чтобы повлиять на наименьшее число людей, прежде чем будут обнаружены проблемы. Ниже приведены некоторые общие принципы, которые следует учитывать в плане.
Подготовьте сегмент сети и подключение службы пользователей, чтобы свести к минимуму прерывание работы.
Запланируйте тестирование маршрутов с подключением traceroute и TCP с отдельного узла, подключенного к Интернету.
Желательно, чтобы тестирование входящих и исходящих служб выполнялось в изолированной тестовой сети с тестовым клиентом Microsoft 365.
Кроме того, тестирование можно выполнить в рабочей сети, если клиент еще не использует Microsoft 365 или находится в пилотном режиме.
Кроме того, тестирование можно выполнить во время сбоя в рабочей среде, который выделен только для тестирования и мониторинга.
Кроме того, тестирование можно выполнить, проверив маршруты для каждой службы на каждом узле маршрутизатора уровня 3. Эту обратную сторону следует использовать только в том случае, если другое тестирование невозможно, так как отсутствие физического тестирования сопряжено с риском.
Создание процедур развертывания
Процедуры развертывания должны развертываться для небольших групп людей поэтапно, чтобы можно было протестировать перед развертыванием в больших группах людей. Ниже приведено несколько способов поэтапного развертывания ExpressRoute.
Настройте ExpressRoute с пирингом Майкрософт и переадресуйте объявления маршрутов на один узел только для поэтапного тестирования.
Сначала прорекламируйте маршруты в сеть ExpressRoute в одном сегменте сети и разверните рекламные объявления маршрутов по сегментам сети или регионам.
При первом развертывании Microsoft 365 используйте развертывание сети ExpressRoute в качестве пилотного проекта для нескольких пользователей.
При использовании прокси-серверов можно также настроить тестовый PAC-файл, чтобы направить несколько пользователей в ExpressRoute с помощью тестирования и обратной связи перед добавлением дополнительных данных.
В плане реализации должны быть перечислены все процедуры развертывания, которые необходимо выполнить, или команды, которые необходимо использовать для развертывания конфигурации сети. Когда наступает время сбоя сети, все внесенные изменения должны быть внесены из написанного плана развертывания, который был написан заранее и проверен. Ознакомьтесь с нашим руководством по технической настройке ExpressRoute.
Обновление записей SPF TXT, если вы изменили IP-адреса для любых локальных серверов, которые будут продолжать отправлять сообщения электронной почты.
Обновление записей DNS для локальных серверов при изменении IP-адресов в соответствии с новой конфигурацией NAT.
Убедитесь, что вы подписаны на RSS-канал для уведомлений конечной точки Microsoft 365, чтобы поддерживать любые конфигурации маршрутизации или прокси-сервера.
После завершения развертывания ExpressRoute необходимо выполнить процедуры в плане тестирования. Результаты каждой процедуры должны быть зарегистрированы в журнале. Необходимо включить процедуры для отката в исходную рабочую среду, если результаты плана тестирования указывают на то, что реализация не была успешной.
Создание процедур тестирования
Процедуры тестирования должны включать тесты для каждой исходящей и входящей сетевой службы для Microsoft 365, которая будет использовать ExpressRoute, и для тех, которые не будут использовать. Процедуры должны включать тестирование из каждого уникального сетевого расположения, включая пользователей, которые не являются локальными в корпоративной локальной сети.
Ниже приведены некоторые примеры тестовых действий.
Связь между локальным маршрутизатором и маршрутизатором оператора сети.
Убедитесь, что ваш локальный маршрутизатор получает объявления IP-адресов Microsoft 365 и CRM Online с более поздним номером 500.
Убедитесь, что NAT для входящего и исходящего трафика работает между ExpressRoute и внутренней сетью.
Убедитесь, что маршруты к NAT объявляются с вашего маршрутизатора.
Убедитесь, что ExpressRoute принял объявленные префиксы.
- Используйте следующий командлет для проверки объявлений пиринга:
Get-AzureRmExpressRouteCircuitRouteTable -DevicePath Primary -ExpressRouteCircuitName TestER -ResourceGroupName RG -PeeringType MicrosoftPeeringУбедитесь, что общедоступный диапазон IP-адресов NAT не объявляется корпорации Майкрософт через любой другой канал ExpressRoute или общедоступный сетевой канал Интернета, если только это не определенное подмножество большего диапазона, как в предыдущем примере.
Каналы ExpressRoute связаны, убедитесь, что оба сеанса BGP запущены.
Настройте один узел на внутренней стороне NAT и используйте ping, tracert и tcpping для проверки подключения по новому каналу к outlook.office365.com узла. Кроме того, вы можете использовать такое средство, как Wireshark или Microsoft Network Monitor 3.4, на зеркальном порту к MSEE, чтобы убедиться, что вы можете подключиться к IP-адресу, связанному с outlook.office365.com.
Тестирование функциональных возможностей на уровне приложения для Exchange Online.
Проверьте, что Outlook может подключаться к Exchange Online и отправлять и получать сообщения электронной почты.
Проверьте, что Outlook может использовать режим "в сети".
Проверьте возможность подключения к смартфону и возможность отправки и получения.
- Тестирование функциональных возможностей уровня приложения для SharePoint
Проверка клиента синхронизации OneDrive для бизнеса.
Проверка веб-доступа к SharePoint.
- Протестируйте функциональные возможности на уровне приложения для сценариев вызова Skype для бизнеса:
Присоединиться к конференции от имени пользователя, прошедшего проверку подлинности [приглашение, инициированное конечным пользователем].
Приглашение пользователя на конференцию [приглашение, отправленное из MCU].
Присоединитесь к конференции в качестве анонимного пользователя с помощью веб-приложения Skype для бизнеса.
Присоединиться к вызову с проводного компьютера, IP-телефона и мобильного устройства.
Вызов федеративного пользователя o Проверка вызова ТСОП: вызов завершен, качество вызова приемлемо, время подключения допустимо.
Убедитесь, что состояние присутствия для контактов обновлено как для членов клиента, так и для федеративных пользователей.
Распространенные проблемы
Асимметричная маршрутизация является наиболее распространенной проблемой реализации. Ниже приведены некоторые распространенные источники для поиска:
Использование открытой или неструктурной топологии маршрутизации сети без исходного NAT.
Не используется SNAT для маршрутизации во входящие службы через Интернет и подключения ExpressRoute.
Не тестировать входящие службы в ExpressRoute в тестовой сети до широкого развертывания.
Развертывание подключения ExpressRoute через сеть
Поэтапное развертывание в одном сегменте сети, постепенно развертывая подключение к разным частям сети с планом отката для каждого нового сегмента сети. Если развертывание согласовано с развертыванием Microsoft 365, сначала разверните пилотных пользователей Microsoft 365 и расширьте его.
Сначала для тестирования, а затем для рабочей среды:
Выполните шаги по развертыванию, чтобы включить ExpressRoute.
Проверьте правильность сетевых маршрутов.
Выполните тестирование для каждой входящей и исходящей службы.
Откат, если обнаружены какие-либо проблемы.
Настройка тестового подключения к ExpressRoute с помощью тестового сегмента сети
Теперь, когда у вас есть готовый план на бумаге, пришло время протестировать в небольшом масштабе. В этом тесте вы установите одно подключение ExpressRoute с пирингом Майкрософт к тестовой подсети в локальной сети. Вы можете настроить пробный клиент Microsoft 365 с подключением к тестовой подсети и из нее, а также включить все исходящие и входящие службы, которые будут использоваться в рабочей среде в тестовой подсети. Настройте DNS для тестового сегмента сети и установите все входящие и исходящие службы. Выполните план тестирования и убедитесь, что вы знакомы с маршрутизацией для каждой службы и распространением маршрутов.
Выполнение планов развертывания и тестирования
По мере выполнения описанных выше элементов проверка области, которые вы завершили, и убедитесь, что вы и ваша команда ознакомились с ними перед выполнением планов развертывания и тестирования.
Список исходящих и входящих служб, участвующих в изменении сети.
Схема архитектуры глобальной сети, показывающая расположения встреч с выходом из Интернета и ExpressRoute.
Схема сетевой маршрутизации, демонстрирующая различные сетевые пути, используемые для каждой развернутой службы.
План развертывания с шагами по реализации изменений и отката при необходимости.
План тестирования для тестирования каждой службы Microsoft 365 и сетевой службы.
Завершена бумажная проверка рабочих маршрутов для входящих и исходящих служб.
Завершенное тестирование в тестовом сегменте сети, включая тестирование доступности.
Выберите окно сбоя, которое достаточно долго для выполнения всего плана развертывания и плана тестирования, имеет некоторое время для устранения неполадок и время для отката при необходимости.
Предостережение
Из-за сложной природы маршрутизации через Интернет и ExpressRoute рекомендуется добавить в это окно дополнительное буферное время для устранения неполадок сложной маршрутизации.
Настройка QoS для Skype для бизнеса Online
QoS необходим для получения голосовых и собраний для Skype для бизнеса Online. Вы можете настроить QoS, убедившись, что сетевое подключение ExpressRoute не блокирует доступ к другим службам Microsoft 365. Конфигурация для QoS описана в статье ExpressRoute и QoS в Skype для бизнеса Online.
Устранение неполадок с реализацией
В первую очередь следует рассмотреть шаги, описанные в этом руководстве по реализации, были ли пропущены в плане реализации? Назад и по возможности выполните дополнительное тестирование небольшой сети, чтобы реплицировать ошибку и выполнить ее отладку.
Определите, какие входящие или исходящие службы завершили сбой во время тестирования. Получите, в частности, IP-адреса и подсети для каждой из служб, которые завершили сбой. Пройдите схему топологии сети на бумаге и проверьте маршрутизацию. Проверьте конкретно, где объявлена маршрутизация ExpressRoute. Проверьте маршрутизацию во время сбоя, если это возможно, с помощью трассировок.
Запустите PSPing с трассировкой сети к каждой конечной точке клиента и оцените исходные и целевые IP-адреса, чтобы убедиться, что они соответствуют ожиданиям. Запустите telnet на любом почтовом узле, который вы предоставляете через порт 25, и убедитесь, что SNAT скрывает исходный IP-адрес, если это ожидается.
Помните, что при развертывании Microsoft 365 с подключением ExpressRoute необходимо обеспечить оптимальную конфигурацию сети для ExpressRoute, а также оптимизировать другие компоненты в сети, например клиентские компьютеры. Помимо использования этого руководства по планированию для устранения неполадок, которые вы могли пропустить, мы также написали план устранения неполадок производительности для Microsoft 365 .
Вы можете быстро вернуться сюда с помощью этой короткой ссылки: https://aka.ms/implementexpressroute365
Статьи по теме
Оценка сетевого подключения Microsoft 365
Azure ExpressRoute для Microsoft 365
Качество мультимедиа и характеристики сетевого подключения в случае Skype для бизнеса Online
Оптимизация сети для Skype для бизнеса Online
ExpressRoute и качество обслуживания в Skype для бизнеса Online
Поток вызовов с использованием ExpressRoute
План устранения неполадок с производительностью для Microsoft 365