Реализация средства ExpressRoute для Office 365

Важно :  Данная статья переведена с помощью машинного перевода, см. Отказ от ответственности. Используйте английский вариант этой статьи, который находится здесь, в качестве справочного материала.

Служба ExpressRoute для Office 365 обеспечивает альтернативный путь маршрутизации для многих служб Office 365 с выходом в Интернет. Архитектура ExpressRoute для Office 365 основана на объявлении общедоступных IP-префиксов служб Office 365, которые уже доступны через Интернет, в подготовленных каналах ExpressRoute для последующего повторного распространения этих IP-префиксов в сети. ExpressRoute позволяет эффективно использовать несколько различных путей маршрутизации (через Интернет и через ExpressRoute) для многих служб Office 365. Такое состояние маршрутизации в сети может потребовать значительного изменения топологии внутренней сети.

Состояние: Полное руководство по v2

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

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

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

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

  1. Проведена оценка сети, а также принято и одобрено решение о необходимости использования ExpressRoute.

  2. Выбран поставщик сетевых служб ExpressRoute. См. сведения о партнерах и одноранговых расположениях ExpressRoute.

  3. Вы уже ознакомились и понимаете документации ExpressRoute и внутренней сети возможность удовлетворить ExpressRoute предварительных начала до конца.

  4. Группы имеет ознакомиться со всеми общедоступного руководства и документация по https://aka.ms/expressrouteoffice365, https://aka.ms/ertи отслеживаемых ряд Azure ExpressRoute для Office 365 обучения Channel 9 понимание критических технические сведения, в том числе:

    • зависимости служб SaaS от Интернета;

    • исключение асимметричных маршрутов и обработка сложной маршрутизации;

    • Узнайте, как внедрить периметр группы безопасности, доступности и элементы управления уровня приложения.

Начальное определение требований

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

Чтобы определить требования для организации, выполните указанные ниже действия.

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

  • Соберите документацию по существующей топологии сети со сведениями о топологии и магистрали внутренней глобальной сети (WAN), подключениях к вспомогательным сайтам, подключениях пользователей на завершающем участке, маршрутизации в направлении точек выхода на периметре сети и прокси-службах.

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

    • Определите все географические расположения пользователей и подключения между ними через глобальную сеть, а также точки с выходом в Интернет и предполагаемые точки с выходом на расположение пиринга ExpressRoute.

    • Определите все пограничные устройства, такие как прокси-серверы, брандмауэры и т. д., и зарегистрируйте их связи с потоками, проходящими через Интернет и ExpressRoute.

    • Укажите, как конечные пользователи будут обращаться к службам Office 365 для обоих потоков (через Интернет и через ExpressRoute): напрямую посредством маршрутизации или косвенно через прокси-приложения.

  • Добавьте на схему сети расположение клиента и расположения типа Meet-Me.

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

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

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

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

Каталог сетевого трафика должен содержать списки всех входящих и исходящих сетевых подключений, имеющих между вашей локальной сети и корпорации Майкрософт.

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

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

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

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

Для каждой службы, требующей входящего подключения, потребуются дополнительные сведения. Серверы в облаке Майкрософт будут устанавливать подключения к вашей локальной сети. Чтобы обеспечить правильность этих соединений, рекомендуется описать для них все аспекты, включая общедоступные DNS-записи для служб, которые будут принимать входящие подключения, IPv4-адреса в формате CIDR, используемое оборудование поставщика услуг Интернета и способ обработки правил преобразования сетевых адресов (NAT) источника для входящего или исходящего трафика этих подключений.

Входящие подключения должны быть проверены независимо от того, откуда они поступают (через Интернет или через ExpressRoute), чтобы обеспечить отсутствие асимметричной маршрутизации. В некоторых случаях доступ к локальным конечным точкам, к которым службы Office 365 инициируют входящие подключения, также может потребоваться другим сервисам Майкрософт и сторонним службам. Очень важно, чтобы включение маршрутизации ExpressRoute к этим службам для Office 365 не нарушало работу других сценариев. Во многих случаях клиентам может потребоваться внести во внутреннюю сеть определенные изменения, например обеспечить преобразование сетевых адресов (NAT) на основе источника, чтобы гарантировать симметричность входящих потоков из Майкрософт после включения ExpressRoute.

Ниже приведен пример требуемого уровня детализации. В этом случае гибридное развертывание Exchange будет осуществлять маршрутизацию в локальную систему через ExpressRoute.

Свойство подключения

Значение

Направление сетевого трафика

Входящий

Служба

Гибридное развертывание Exchange

Общедоступная конечная точка Office 365 (источник)

Exchange Online (IP-адреса)

Общедоступная локальная конечная точка (назначение)

5.5.5.5

Общедоступная DNS-запись (Интернет)

Autodiscover.contoso.com

Будет ли эта локальная конечная точка использоваться другими службами Майкрософт (отличными от Office 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

Высокая доступность

Активная/активная через 2 геоизбыточных

канала ExpressRoute — Чикаго и Даллас

Контроль симметрии путей

Метод: источника NAT

Путь к Интернету: исходный NAT входящих подключений к 192.168.5.5

ExpressRoute пути: исходный NAT подключения к 192.168.1.0 (Чикаго) и 192.168.2.0 (Даллас)

Ниже приведен пример службы, которая создает только исходящий трафик.

Свойство подключения

Значение

Направление сетевого трафика

Исходящий

Служба

SharePoint Online

Локальная конечная точка (источник)

Рабочая станция пользователя

Общедоступная конечная точка Office 365 (назначение)

SharePoint Online (IP-адреса)

Общедоступная DNS-запись (Интернет)

*.sharepoint.com (и дополнительные полные доменные имена)

Ссылки на сеть доставки содержимого (CDN)

cdn.sharepointonline.com (и дополнительные полные доменные имена) — IP-адреса, обслуживаемые поставщиками CDN

Объявление IP-адреса и используемый метод NAT

Путь в Интернете/NAT источника: 1.1.1.0/24

ExpressRoute пути и источник NAT: 1.1.2.0/24 (Чикаго) и 1.1.3.0/24 (Даллас)

Способ подключения

Интернет: через прокси-сервер 7-го уровня (PAC-файл)

ExpressRoute: Прямая отправка (без прокси-сервера)

Средства управления безопасностью/периметром

Путь в Интернете: DeviceID_002

ExpressRoute пути: DeviceID_003

Высокая доступность

Путь к Интернету: выхода избыточные Интернета

ExpressRoute пути: активный/активный «горячей potato» Маршрутизация через 2 избыточные географического цепи ExpressRoute — Чикаго и Даллас

Контроль симметрии путей

Метод: исходный NAT всех связей

Разобравшись со службами и связанными с ними потоками сетевого трафика, можно создать схему сети, включающую эти новые требования к подключениям и демонстрирующую изменения, которые необходимо внести для использования ExpressRoute для Office 365. Схема должна содержать указанные ниже сведения.

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

  2. Все точки выхода в Интернет и ExpressRoute.

  3. Все устройства, управляющие входящими и исходящими сетевыми подключениями, включая маршрутизаторы, брандмауэры, прокси-серверы приложений, системы обнаружения атак и системы предотвращения вторжений.

  4. Внутренние назначения для всего входящего трафика, такие как внутренние серверы ADFS, принимающие подключения от прокси-серверов веб-приложений ADFS.

  5. Список всех IP-подсетей, которые будут объявлены.

  6. Укажите каждое место, из которого пользователи будут обращаться к Office 365, и составьте список расположений Meet-Me, которые будут использоваться для ExpressRoute.

  7. Расположения и части топологии внутренней сети, в которых будут приниматься и фильтроваться и на которые будут распространяться IP-префиксы Майкрософт из ExpressRoute.

  8. В топологии сети должно быть показано географическое расположение каждого сегмента и способ его подключения к сети Майкрософт (через ExpressRoute или Интернет).

На рисунке ниже показаны все расположения, в которых будет использоваться Office 365, а также входящие и исходящие объявления маршрутизации для Office 365.

ExpressRoute Meet-Me в регионах

Для исходящего трафика пользователи обращаются к Office 365 одним из трех способов:

  1. через расположение Meet-Me в Северной Америке для пользователей из Калифорнии;

  2. через расположение Meet-Me в Гонконге для пользователей из Гонконга;

  3. через Интернет в Бангладеш, где меньше население и отсутствуют каналы ExpressRoute.

Схема исходящих подключений для региона

Точно так же входящий трафик из Office 365 возвращается одним из трех способов:

  1. через расположение Meet-Me в Северной Америке для пользователей из Калифорнии;

  2. через расположение Meet-Me в Гонконге для пользователей из Гонконга;

  3. через Интернет в Бангладеш, где меньше население и отсутствуют каналы ExpressRoute.

Схема входящих подключений для региона

Выбор расположений Meet-Me, являющихся физическими местами, в которых ваша сеть подключается к сети Майкрософт с помощью канала ExpressRoute, зависит от расположений, из которых пользователи будут обращаться к Office 365. Поскольку Office 365 предлагается по схеме SaaS, этот продукт не работает по региональной модели IaaS или PaaS, как это делает Azure. Напротив, Office 365 — это распределенный набор служб для совместной работы, использование которого может потребовать подключения пользователей к конечным точкам через несколько центров обработки данных или регионов, необязательно размещенных в том же месте или регионе, что и клиент пользователя.

Это означает, что самым важным фактором, который необходимо учитывать при выборе расположений Meet-Me для ExpressRoute для Office 365, является место, из которого будут подключаться пользователи организации. Общая рекомендация для оптимизации подключений к Office 365 следующая: маршрутизация должна быть реализована таким образом, чтобы пользовательские запросы к службам Office 365 передавались в сеть Майкрософт по кратчайшему сетевому пути (такой подход также часто называется маршрутизацией без задержек). Например, если большинство пользователей Office 365 находятся в одном или двух расположениях, для создания оптимальной структуры следует выбрать расположения Meet-Me на самом близком расстоянии от местоположения этих пользователей. Если у компании большие группы пользователей в разных регионах, возможно, целесообразно будет использовать несколько каналов ExpressRoute и расположений Meet-Me. Для некоторых расположений пользователей кратчайший и оптимальный путь к сети Майкрософт и Office 365 может проходить не через внутреннюю глобальную сеть (WAN) и точки Meet-Me в ExpressRoute, а через Интернет.

Зачастую существуют несколько расположений Meet-Me, которые можно выбрать в данном регионе и которые находятся относительно близко к пользователям. Чтобы принять решение, заполните следующую таблицу.

Запланированные расположения Meet-Me в Калифорнии и Нью-Йорке

Расположение

Количество пользователей

Ожидаемая задержка в направлении сети Майкрософт через выход в Интернет

Ожидаемая задержка в направлении сети Майкрософт через ExpressRoute

Лос-Анджелес

10 000

~15 мс

~10 мс (через Кремниевую долину)

Округ Вашингтон

15 000

~20 мс

~10 мс (через Нью-Йорк)

Даллас

5 000

~15 мс

~40 мс (через Нью-Йорк)

С помощью разработанной архитектуры глобальной сети, в которой показаны регион Office 365, расположения Meet-Me поставщика сетевых служб ExpressRoute и количество пользователей по расположениям, можно определить возможность оптимизации. В ней также могут быть показаны глобальные сетевые подключения с разворотом, где трафик направляется в отдаленную точку для получения расположения Meet-Me. Если в глобальной сети обнаруживается разворот, для продолжения работы его необходимо устранить. Чтобы избежать разворота, найдите другое расположение Meet-Me или используйте выборочные коммутационные точки выхода в Интернет.

На первом рисунке показан пример клиента с двумя физическими расположениями в Северной Америке. Указаны сведения о местоположениях офисов, расположениях клиентов Office 365 и нескольких точках Meet-Me для ExpressRoute на выбор. В этом примере клиент выбрал расположение Meet-Me по двум принципам в следующем порядке:

  1. ближайшее расстояние до пользователей в организации;

  2. Ближайший по сходству центру обработки данных Майкрософт, где расположен Office 365.

ExpressRoute Meet-Me в США

Если немного раздвинуть рамки этой концепции, на втором рисунке можно увидеть пример транснационального клиента с аналогичными сведениями и принципами принятия решений. У этого клиента небольшой офис в Бангладеш, в котором работает маленькая команда из десяти человек, основной задачей которой является расширение присутствия компании в этом регионе. В Ченнаи существует расположение Meet-Me и центр обработки данных Майкрософт, в котором размещены службы Office 365. Следовательно, использовать расположение Meet-Me вполне разумно, однако расходы на дополнительный канал для десяти человек слишком обременительны. Оценивая сеть, необходимо определить, какой из вариантов эффективнее: отправка сетевого трафика через сеть с задержкой или расходы на создание дополнительного канала ExpressRoute.

Кроме того, десять пользователей в Бангладеш могут ощутить более высокую производительность при отправке сетевого трафика в сеть Майкрософт через Интернет, чем при маршрутизации во внутренней сети, как было показано на вводных схемах и продублировано ниже.

Схема исходящих подключений для региона

Создание плана внедрения ExpressRoute для Office 365

План внедрения должен включать как технические сведения о настройке ExpressRoute, так и сведения о настройке всей остальной инфраструктуры вашей сети. Ниже перечислены некоторые из таких аспектов.

  • Планирование служб, использующих как ExpressRoute, так и Интернет.

  • Планирование пропускной способности, безопасности, высокого уровня доступности и отработки отказа.

  • Проектирование внутренней и внешней маршрутизации, включая правильную оптимизацию путей маршрутизации для различных расположений.

  • Определение границы объявления маршрутов ExpressRoute в сети и механизма выбора клиентами пути через Интернет или ExpressRoute (например, прямая маршрутизация или прокси-приложения).

  • Планирование изменений DNS-записей, включая записи инфраструктуры политики отправителей.

  • Планирование стратегии NAT, включая входящие и исходящие источник выполняя дополнительную настройку.

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

  • Планирование конечным пользователем клиента маршрутизации локальной сети, например настройке файл PAC/WPADмаршрут по умолчанию, прокси-серверов и объявлений маршрутов протокола BGP.

  • Планирование маршрутизации в сети периметра (включая прокси-серверы, брандмауэры и облачные прокси-серверы).

Создайте план для пропускной способности, необходимой для отработки каждой из основных рабочих нагрузок Office 365. Отдельно оцените требования к пропускной способности для служб Exchange Online, SharePoint Online и Skype для бизнеса Online. В качестве отправной точки можно использовать предлагаемые нами калькуляторы оценки для служб Exchange Online и Skype для бизнеса, однако для полного понимания потребностей организации в пропускной способности необходимо выполнить пилотный тест с репрезентативной выборкой профилей и расположений пользователей.

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

Добавьте в план сведения о том, какие пользователи будут затронуты простоями тех или иных типов и как им проще всего выполнять свою работу в полном объеме.

Планирование требований к пропускной способности, включая требования службы Skype для бизнеса в отношении дрожания, задержки, перегрузки и запаса

У службы Skype для бизнеса Online также есть особые дополнительные требования к сети, которые подробно описаны в статье Качество мультимедиа и производительность сетевого подключения в Skype для бизнеса Online.

Прочтите раздел Планирование пропускной способности для Azure ExpressRoute статьи Планирование сети при использовании ExpressRoute для Office 365.

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

Планирование требований к высокому уровню доступности

Создайте план для высокого уровня доступности в соответствии со своими потребностями и включите его в обновленную схему топологии сети. Прочтите раздел Высокий уровень доступности и отработка отказов при использовании Azure ExpressRoute статьи Планирование сети при использовании ExpressRoute для Office 365.

Планирование использования требованиям безопасности сети

Создайте план в соответствии со своими требованиями к безопасности сети и включите его в обновленную схему топологии сети. Прочтите раздел Средства управления безопасностью в Azure ExpressRoute для Office 365 статьи Планирование сети при использовании ExpressRoute для Office 365.

Служба ExpressRoute для Office 365 предъявляет к исходящим сетевым подключениям требования, которые могут быть вам незнакомы. В частности, IP-адреса, которые представляют пользователей и сети службам Office 365 и выступают в качестве конечных точек источников для исходящих сетевых подключений к Майкрософт, должны отвечать перечисленным ниже особым требованиям.

  1. Конечные точки должны иметь общедоступные IP-адреса, которые зарегистрированы на имя вашей компании или оператора, предоставляющего вам возможность подключения к ExpressRoute.

  2. Конечные точки должны быть объявлены в Майкрософт, а также проверены и приняты в ExpressRoute.

  3. Конечные точки не должны быть объявлены в Интернете с теми же или предпочтительными метриками маршрутизации.

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

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

Самый распространенный способ, с помощью которого можно обеспечить соответствие указанными выше требованиям, заключается в использовании NAT источника, реализованного на уровне сети или предоставленного оператором ExpressRoute. NAT источника позволяет абстрагировать частные IP-адреса и сведения о внутренней сети для ExpressRoute и, в сочетании с правильными объявлениями IP-маршрутов, представляет собой простой механизм обеспечения симметрии путей. Если вы используете сетевые устройства с отслеживанием состояния для каждого расположения пиринга ExpressRoute, необходимо реализовать отдельные пулы NAT для каждого такого расположения, чтобы обеспечить симметрию путей.

Дополнительные сведения см. в статье Требования ExpressRoute к NAT.

Добавьте изменения для исходящих подключений в схему топологии сети.

Большинство корпоративных развертываний Office 365 предполагают те или иные входящие подключения служб Office 365 к локальным службам, например при гибридных сценариях для Exchange, SharePoint и Skype для бизнеса, миграции почтовых ящиков и проверке подлинности с помощью инфраструктуры ADFS. При включении в ExpressRoute дополнительного пути маршрутизации между локальной сетью и Майкрософт для исходящих подключений эти входящие подключения могут случайно оказаться под влиянием асимметричной маршрутизации, даже если вы захотите обеспечить дальнейшее прохождение этих потоков через Интернет. Ниже описаны меры предосторожности, которые рекомендуется принять, чтобы исключить влияние на входящие интернет-потоки от служб Office 365 к локальным системам.

Чтобы минимизировать риск асимметричной маршрутизации для потоков входящего сетевого трафика, все входящие подключения должны использовать NAT источника, прежде чем они будут направлены в сегменты сети, в которых обеспечивается видимость маршрутизации для ExpressRoute. Если для сегмента сети, в котором обеспечивается видимость маршрутизации для ExpressRoute, разрешены входящие подключения без использования NAT источника, запросы, создаваемые службами Office 365, будут поступать из Интернета, а ответы, возвращаемые службам Office 365, будут передаваться по сетевому пути ExpressRoute обратно в сеть Майкрософт, в результате чего возникнет асимметричная маршрутизация.

Чтобы обеспечить выполнение этого требования, можно воспользоваться одним из следующих шаблонов внедрения.

  1. Выполняйте NAT источника до того, как запросы направляются во внутреннюю сеть с помощью сетевого оборудования, такого как брандмауэры или балансировщики нагрузки, на пути из Интернета в локальные системы.

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

Точное выполнение этих сценариев в сети и передача всех потоков входящего сетевого трафика через Интернет позволит минимизировать риск асимметричной маршрутизации при развертывании и эксплуатации.

Бывают случаи, когда некоторые входящие потоки должны быть направлены через подключения ExpressRoute. В этих ситуациях необходимо учесть перечисленные ниже дополнительные факторы.

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

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

  3. Для получения входящих сетевых подключений через ExpressRoute общедоступные IP-подсети для этих конечных точек должны быть объявлены в Майкрософт через ExpressRoute.

  4. Тщательно проанализируйте эти потоки входящего сетевого трафика, чтобы к ним применялись правильные средства управления безопасностью и сетью, соответствующие принятым в компании политикам безопасности и сети.

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

  6. В случае отказа канала ExpressRoute или расположения Meet-Me необходимо будет обеспечить доступность локальных входящих конечных точек для принятия запросов по отдельному сетевому пути. Это может означать необходимость объявления подсетей для этих конечных точек через несколько каналов ExpressRoute.

  7. Мы рекомендуем применять NAT источника для всех потоков входящего сетевого трафика, поступающих в вашу сеть через ExpressRoute, особенно в том случае, если эти потоки проходят через сетевые устройства с отслеживанием состояния, такие как брандмауэры.

  8. Некоторые локальные сервисы, такие как прокси-служба ADFS или служба автообнаружения Microsoft Exchange, могут получать входящие запросы как от служб Office 365, так и от пользователей из Интернета. Для таких запросов Office 365 будет применять то же полное доменное имя, что и для пользовательских запросов через Интернет. Разрешение входящих пользовательских подключений из Интернета к этим локальным конечным точкам с одновременным принудительным направлением подключений к Office 365 через ExpressRoute представляет значительную сложность маршрутизации. Подавляющему большинству клиентов не рекомендуется развертывать такие сложные сценарии через ExpressRoute из-за особенностей эксплуатации. Такая дополнительная нагрузка включает контроль над рисками асимметричной маршрутизации и требует тщательного управления объявлениями и политиками маршрутизации с учетом различных факторов.

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

Для начала рассмотрим несколько различных ситуаций, связанных с приведенной ниже схемой сети. На этой схеме все серверы, получающие входящие запросы, такие как ADFS или локальные гибридные серверы, размещены в центре обработки данных в Нью-Джерси и объявлены в Интернете.

  1. Поскольку сеть периметра является безопасной, преобразование сетевых адресов (NAT) для входящих запросов недоступно.

  2. Для серверов центра обработки данных в Нью-Джерси доступны как маршруты через Интернет, так и через ExpressRoute.

Общие сведения о подключениях ExpressRoute

У нас также есть предложения по их исправлению.

Проблема 1. Подключение облака к локальной сети через Интернет

На следующей схеме показан асимметричный сетевой путь, используемый в том случае, когда конфигурация сети не предусматривает NAT для входящих запросов от облака Майкрософт через Интернет.

  1. Входящий запрос от служб Office 365 получает IP-адрес локальной конечной точки из общедоступных DNS-записей и отправляет запрос в сеть периметра.

  2. В этой ошибочной конфигурации в сети периметра, в которую отправляется трафик, не настроено или недоступно преобразование сетевых адресов (NAT) источника, в результате чего в качестве назначения для обратного пути используется фактический IP-адрес источника.

    • Сервер в сети направляет обратный трафик в службы Office 365 через любое доступное сетевое подключение ExpressRoute.

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

Проблема с асимметричной маршрутизацией ExpressRoute 1

Решение 1А. NAT источника

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

  1. Входящие запросы продолжают поступать через сеть периметра центра обработки данных в Нью-Джерси. На этот раз преобразование сетевых адресов (NAT) источника доступно.

  2. Ответ от сервера направляется обратно на IP-адрес, связанный с NAT источника, а не на исходный IP-адрес, в результате чего ответ возвращается по тому же сетевому пути.

Решение для асимметричной маршрутизации ExpressRoute 1

Решение 1Б. Определение области маршрутизации

Вы также можете не допустить объявления BGP-префиксов ExpressRoute, удалив альтернативный сетевой путь для этих компьютеров. На схеме это выглядит следующим образом.

  1. Входящие запросы продолжают поступать через сеть периметра центра обработки данных в Нью-Джерси. На этот раз префиксы, объявленные из Майкрософт через канал ExpressRoute, недоступны для центра обработки данных в Нью-Джерси.

  2. Ответ от сервера направляется обратно на IP-адрес, связанный с исходным IP-адресом, по единственному доступному маршруту, в результате чего ответ возвращается по тому же сетевому пути.

Решение для асимметричной маршрутизации ExpressRoute 2

Проблема 2. Подключение облака к локальной сети через ExpressRoute

На следующей схеме показан асимметричный сетевой путь, используемый в том случае, когда конфигурация сети не предусматривает NAT для входящих запросов от облака Майкрософт через ExpressRoute.

  1. Входящий запрос от служб Office 365 получает IP-адрес из DNS-записей и отправляет запрос в сеть периметра.

  2. В этой ошибочной конфигурации в сети периметра, в которую отправляется трафик, не настроено или недоступно преобразование сетевых адресов (NAT) источника, в результате чего в качестве назначения для обратного пути используется фактический IP-адрес источника.

    • Компьютер в сети направляет обратный трафик в службы Office 365 через любое доступное сетевое подключение ExpressRoute.

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

Проблема с асимметричной маршрутизацией ExpressRoute 2

Решение 2. NAT источника

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

  1. Входящие запросы продолжают поступать через сеть периметра центра обработки данных в Нью-Йорке. На этот раз преобразование сетевых адресов (NAT) источника доступно.

  2. Ответ от сервера направляется обратно на IP-адрес, связанный с NAT источника, а не на исходный IP-адрес, в результате чего ответ возвращается по тому же сетевому пути.

Решение для асимметричной маршрутизации ExpressRoute 3

Проверка симметрии путей в структуре сети на бумаге

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

Это необходимо сделать для всех сетевых служб Office 365, которые ранее были определены как службы, которые будут внедряться в организации.

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

Проектирование конфигурации подключения клиента

Использование PAC-файлов с ExpressRoute

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

Примечание : Конечные точки часто меняются (раз в неделю). Чтобы сократить количество изменений, которые необходимо вносить для актуализации параметров, их следует вносить только на основе служб и функций, развернутых в организации. Обратите особое внимание на дату вступления в силу, указанную в RSS-канале, в котором сообщается об изменениях и записываются все прошлые изменения, поскольку заявленные в нем IP-адреса могут быть не объявлены или удалены из объявления, пока эта дата не наступит.

Создание процедур развертывания и тестирования

План внедрения должен предусматривать тестирование и откат. Он должен сводить к минимуму влияние невыявленных проблем с реализацией. Ниже описаны некоторые общие принципы, которые должен учитывать ваш план.

  1. Проводите внедрение сегментов сети и пользовательских служб поэтапно, чтобы свести к минимуму простои.

  2. Запланируйте тестовые маршруты с использованием traceroute и подключения по TCP с отдельного узла, подключенного к Интернету.

  3. Желательно выполнять тестирование входящих и исходящих служб в изолированной сети с тестовым клиентом Office 365.

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

    • Тестирование также можно выполнять во время сбоев, выделяемых для проверки и мониторинга.

    • Наконец, для него можно использовать проверку маршрутов для каждой службы на каждом узле маршрутизатора уровня 3. Это способ следует применять только в том случае, если другие варианты невозможны, так как отсутствие физического тестирования приводит к риску.

Процедуры развертывания должны выполняться поэтапно в небольших группах пользователей, чтобы обеспечить возможность тестирования до развертывания в больших группах. Ниже описано несколько способов разбивки развертывания ExpressRoute на этапы.

  1. Настройте ExpressRoute с пирингом Майкрософт и организуйте переадресацию объявлений маршрутов на один хост только для поэтапного тестирования.

  2. Объявите маршруты к сети ExpressRoute сначала в одном сегменте сети, а затем распространяйте объявления маршрутов по сегментам сети или регионам.

  3. Если развертывание Office 365 выполняется впервые, используйте развертывание сети ExpressRoute в качестве пилотного для небольшого количества пользователей.

  4. Если используются прокси-серверы, также можно настроить тестовый PAC-файл, чтобы направить небольшое количество пользователей в ExpressRoute для тестирования и получения отзывов, прежде чем добавлять других.

В плане внедрения должны быть перечислены все процедуры развертывания, которые требуется выполнить, или команды, которые необходимо использовать для развертывания конфигурации сети. Когда наступит период простоя сети, все изменения должны будут вноситься в соответствии с написанным планом развертывания, который был разработан заранее и отрецензирован. См. наше руководство по технической настройке ExpressRoute.

  • Обновление TXT-записей инфраструктуры политики отправителей (SPF) при изменении IP-адресов каких-либо локальных серверов, продолжающих отправлять электронную почту.

  • Обновление всех DNS-записей для локальных серверов при изменении IP-адресов в соответствии с новой конфигурацией NAT.

  • Подписка на RSS-канал уведомлений конечных точек Office 365 для обслуживания любых конфигураций маршрутизации или проксирования.

После завершения развертывания ExpressRoute должна выполняться процедуры, описанные в план тестирования. Результаты для каждой процедуры должны войти в систему. Возврат к предыдущей версии в исходной производственной среды в том случае, если результаты план тестирования означает, что реализация не удалось выполнить процедуры необходимо включить.

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

Ниже приведены некоторые примеры действий тестирования.

  1. Команды ping с локальной маршрутизаторе — к маршрутизатору оператор сети.

  2. Проверьте получение 500 и более объявлений IP-адресов служб Office 365 и CRM Online локальным маршрутизатором.

  3. Проверьте работоспособность правил преобразования сетевых адресов (NAT) для входящего и исходящего трафика между ExpressRoute и внутренней сетью.

  4. Проверьте что маршруты к NAT объявляется из на маршрутизаторе.

  5. Убедитесь, что объявленные префиксы приняты в ExpressRoute.

    • Подтверждение авторами рекламные с помощью следующего командлета:

    • Get-AzureRmExpressRouteCircuitRouteTable -DevicePath Primary -ExpressRouteCircuitName TestER -ResourceGroupName RG -PeeringType MicrosoftPeering
  6. Убедитесь, что диапазон общедоступных IP-адресов NAT не объявлен в Майкрософт через какой-либо другой канал ExpressRoute или общедоступный канал сети Интернет, если это не определенное подмножество большего диапазона, как в предыдущем примере.

  7. Проверьте работу обоих BGP-сеансов, наличие которых обусловлено парностью каналов ExpressRoute.

  8. Настройте один хост с внутренней стороны NAT и проверьте подключение к хосту outlook.office365.com по новому каналу с помощью команд ping, tracert и tcpping. Чтобы проверить возможность подключения к IP-адресу, связанному с хостом outlook.office365.com, также можно использовать такую программу, как Wireshark или Microsoft Network Monitor 3.4, на зеркальном порту для MSEE.

  9. Протестируйте функциональность на уровне приложения для Exchange Online.

    • Протестируйте возможность подключения приложения Outlook к Exchange Online, а также возможности отправки и получения электронной почты.

    • Протестируйте возможность использования приложением Outlook интерактивного режима.

    • Протестируйте возможность подключения, а также отправки и получения электронной почты со смартфона.

  10. Протестируйте функциональность на уровне приложения для SharePoint Online.

    • Протестируйте клиент синхронизации OneDrive для бизнеса.

    • Протестируйте веб-доступ к SharePoint Online.

  11. Протестируйте функциональность на уровне приложения для сценариев вызова Skype для бизнеса.

    • Присоединитесь к конференции в качестве пользователя, прошедшего проверку подлинности (приглашение должно быть инициировано конечным пользователем).

    • Пригласите пользователя принять участие в конференции (приглашение должно быть отправлено из MCU).

    • Присоединитесь к конференции в качестве анонимного пользователя с помощью веб-приложения Skype для бизнеса.

    • Присоединитесь к звонку, используя проводное подключение к компьютеру, IP-телефон и мобильное устройство.

    • Вызов Федеративный пользователь o вызов ТСОП проверки: завершить вызов, качество звонка приемлемо, приемлемо время установления соединения.

    • Убедитесь, что состояние присутствия контакта обновляется у обоих участников среди пользователей клиента и федеративных пользователей.

Наиболее распространенной проблемой при внедрении является асимметричная маршрутизация. Обратите внимание на следующие причины:

  • Используется открытая или плоская топология сетевой маршрутизации без NAT источника.

  • SNAT не используется для маршрутизации к входящим службам через подключения к Интернету и ExpressRoute.

  • Входящие службы с ExpressRoute не были проверены в тестовой сети перед широким развертыванием.

Развертывание подключения через ExpressRoute в сети

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

В тестовой, а затем в рабочей среде:

  • Выполните действия по развертыванию, чтобы включить ExpressRoute.

  • Проверьте видимость маршрутов.

  • Выполните тестирование всех входящих и исходящих служб.

  • Выполните откат в случае обнаружения проблем.

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

После завершения описанных выше процедур отметьте готовые элементы и убедитесь, что вы и ваша команда ознакомились с ними до выполнения планов развертывания и тестирования.

  • Список исходящих и входящих служб, которые участвуют в изменении сети.

  • Схема архитектуры глобальной сети, на которой показаны как точки выхода в Интернет, так и расположения Meet-Me для ExpressRoute.

  • Схема сетевой маршрутизации, на которой показаны различные сетевые пути, используемые для каждой развернутой службы.

  • План развертывания, который включает действия по внедрению изменений и откату (при необходимости).

  • План тестирования каждой службы Office 365 и сетевой службы.

  • Проведенная на бумаге проверка рабочих маршрутов для входящих и исходящих служб.

  • Выполненный тест в тестовом сегменте сети, включая тестирование доступности.

Выберите достаточно продолжительное окно простоя для выполнения всего плана развертывания и плана тестирования с некоторым запасом времени на устранение неполадок и откат (при необходимости).

Предупреждение : Из-за сложности одновременной маршрутизации через Интернет и ExpressRoute рекомендуется добавить к этому окну дополнительное буферное время на устранение неполадок, связанных со сложной маршрутизацией.

Использование голосовой связи и собраний в Skype для бизнеса Online требует поддержки высокого качества обслуживания (QoS) пользователей. Перед настройкой QoS необходимо убедиться, что сетевое подключение ExpressRoute не блокирует доступ какой-либо другой службы Office 365. Настройка QoS описана в статье ExpressRoute и качество обслуживания в Skype для бизнеса Online.

Устранение неполадок при внедрении

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

Определите, в работе каких входящих или исходящих служб произошел сбой во время тестирования. В частности, получите для каждой из таких служб IP-адреса и подсети. Затем проверьте маршрутизацию на схеме топологии сети на бумаге. В частности, проверьте место объявления маршрутов ExpressRoute и по возможности протестируйте их во время простоя с трассировками.

Запустите PSPing для сетевой трассировки для каждой конечной точки клиента и проверьте исходного и конечного IP-адресов для проверки, что они являются должным образом. Запустите telnet любой почты настраиваемом предоставлять через порт 25 и убедитесь, что SNAT скрыта исходный IP-адрес источника, если это требуется.

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

Вы можете быстро вернуться сюда с помощью этой короткой ссылки: https://aka.ms/implementexpressroute365.

См. также:

Сетевое подключение к Office 365
Azure ExpressRoute для Office 365
Управление ExpressRoute для Office 365 connectivity
маршрутизации с ExpressRoute для Office 365
сетевое планирование с ExpressRoute для Office 365
с помощью протокола BGP сообществ в ExpressRoute для Office 365 сценарии (ознакомительная версия)
качество файлов мультимедиа и производительность подключения к сети в Скайп для бизнеса Online
оптимизации сети для Скайп для бизнеса Online
ExpressRoute и QoS в Скайп для бизнеса Online
звонок с помощью ExpressRoute поток
Настройка производительности Office 365 с помощью базовых показателей и историю работы
производительности Устранение неполадок план для Office 365
Office 365 URL-адреса и диапазоны IP-адресов
сети Office 365 и настройка производительности

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

Совершенствование навыков
Перейти к обучению
Первоочередный доступ к новым возможностям
Присоединиться к программе предварительной оценки Office

Были ли сведения полезными?

Спасибо за ваш отзыв!

Благодарим за отзыв! Возможно, будет полезно связать вас с одним из наших специалистов службы поддержки Office.

×