Технические требования для организации мобильной работы в Lync Server 2013
Последнее изменение раздела: 2014-07-24
Some information in this topic pertains to Cumulative Updates for Lync Server 2013: February 2013.
Мобильные пользователи сталкиваются с различными сценариями мобильных приложений, которые требуют специального планирования. Например, кто-то может начать использовать мобильное приложение, находясь вне работы, подключився к сети 3G, а затем переключиться на корпоративную сеть Wi-Fi при входе на работу, а затем вернуться к 3G при выходе из здания. Необходимо спланировать среду для поддержки таких переходов в сети и обеспечить согласованное взаимодействие с пользователем. В этом разделе описываются требования к инфраструктуре, необходимые для поддержки мобильных приложений и автоматического обнаружения ресурсов мобильности.
Примечание.
Хотя мобильные приложения также могут подключаться к другим службам Lync Server 2013, требование отправлять все веб-запросы мобильных приложений на одно внешнее полное доменное имя (FQDN) применяется только к службе Lync Server 2013 Mobility Service. Для других служб мобильности эта конфигурация не требуется.
Требования к сходствам файлов cookie в аппаратных подсистемах балансировки нагрузки значительно снижаются, и вы заменяете сходство протокола TCP, если используете Lync Mobile, поставляемые с Lync Server 2013. Сходство файлов cookie по-прежнему можно использовать, но веб-службам это больше не требуется.
Важно
Весь трафик службы Mobility Service проходит через обратный прокси-сервер независимо от того, где находится точка начала— внутренний или внешний. В случае с одним обратным прокси-сервером, фермой обратных прокси-серверов или устройством, предоставляющим функцию обратного прокси-сервера, может возникнуть проблема, когда внутренний трафик проходит через интерфейс и пытается немедленно входящий трафик в том же интерфейсе. Это часто приводит к нарушению правила безопасности, известному как спуфинг пакетов TCP или просто спуфинг. Чтобы обеспечить мобильность функции, необходимо разрешить закрепление ветвей (исходящий и непосредственный входящий трафик пакета или ряда пакетов). Один из способов решения этой проблемы — использовать обратный прокси-сервер, который отделен от брандмауэра (правило предотвращения спуфинга всегда должно применяться в брандмауэре в целях безопасности). Разворот может происходить во внешнем интерфейсе обратного прокси-сервера, а не во внешнем интерфейсе брандмауэра. Вы обнаруживаете спуфинг в брандмауэре и отменяйте правило на обратном прокси-сервере, тем самым позволяя использовать вешки, необходимые для мобильности.
Если это возможно, используйте хост-сервер системы доменных имен (DNS) или записи CNAME, чтобы определить обратный прокси-сервер для поведения разворота (а не брандмауэра).
Lync Server 2013 поддерживает службы мобильности для мобильных клиентов Lync 2010 Mobile и Lync 2013. Оба клиента используют службу автообнаружения Lync Server 2013 для поиска точки входа в мобильность, но отличаются от используемой службы мобильности. В Lync 2010 Mobile используется служба Mobility Service, известная как Mcx, представленная в накопительном обновлении для Lync Server 2010: ноябрь 2011 г. Мобильные клиенты Lync 2013 используют веб-API unified Communications ( UCWA) в качестве поставщика услуг мобильности.
Внутренняя и внешняя конфигурация DNS
Службы Mobility Services Mcx (появились в накопительном обновлении для Lync Server 2010: ноябрь 2011 г.) и UCWA (появились в накопительном пакете Обновления для Lync Server 2013: февраль 2013 г.) используют DNS таким же образом.
При использовании автоматического обнаружения мобильные устройства используют DNS для поиска ресурсов. Во время поиска DNS сначала выполняется попытка подключения к FQDN, связанному с внутренней записью DNS (lyncdiscoverinternal).< внутреннее доменное имя>). Если установить подключение с помощью внутренней записи DNS невозможно, попытка подключения выполняется с помощью внешней записи DNS (lyncdiscover).< sipdomain>). Мобильное устройство, внутреннее по сети, подключается к URL-адресу внутренней службы автообнаружения, а мобильное устройство, которое является внешним по сети, подключается к URL-адресу внешней службы автообнаружения. Запросы на внешнее автообнаружение проходит через обратный прокси-сервер. Служба автообнаружения Lync Server 2013 возвращает все URL-адреса веб-служб для домашнего пула пользователя, включая URL-адреса службы Mobility Service (Mcx и UCWA). Однако как внутренний URL-адрес службы Mobility Service, так и URL-адрес внешней службы Mobility Service связаны с FQDN внешних веб-служб. Таким образом, независимо от того, является ли мобильное устройство внутренним или внешним по сети, оно всегда подключается к службе Lync Server 2013 Mobility Service извне через обратный прокси-сервер.
Примечание.
Важно понимать, что развертывание может состоять из нескольких различных пространств имен для внутреннего и внешнего использования. Имя домена SIP может отличаться от имени домена внутреннего развертывания. Например, домен SIP может быть contoso.com, а внутреннее развертывание — contoso.net. Пользователи, которые войдите в Lync Server, будут использовать доменное имя SIP, например john@contoso.com. При адресации внешних веб-служб (определенных в построителе топологий как внешние веб-службы ) доменное имя и доменное имя SIP будут согласованы, как определено в DNS. При адресации внутренних веб-служб (определенных в построителе топологий как внутренние веб-службы ) по умолчанию внутренними веб-службами будет полное доменное имя интерфейсного сервера, пула переднего плана, директора или пула директоров. Вы можете переопределить имя внутренней веб-службы. Следует использовать внутреннее доменное имя (а не доменное имя SIP) для внутренних веб-служб и определить запись A узла DNS (или, для IPv6, AAAA), чтобы отразить переопределенное имя. Например, полное доменное имя внутренних веб-служб по умолчанию может быть pool01.contoso.net. Переопределенное полное доменное имя внутренних веб-служб может быть webpool.contoso.net. Определение веб-служб таким образом помогает обеспечить внутреннее и внешнее локальность служб, а не локальность пользователя, который их использует.
Тем не менее, поскольку веб-службы определены в построителе топологий и имя внутренних веб-служб можно переопределить, если полученное имя веб-службы, сертификат, который его проверяет, и записи DNS, определяющие его, согласованы, можно определить внутренние веб-службы с любым доменным именем, включая доменное имя SIP, которое вы хотите. В конечном счете разрешение имени IP-адреса определяется записями узла DNS и согласованным пространством имен.
В этом разделе и примерах внутреннее доменное имя используется для иллюстрации топологии и определений DNS.
На следующей схеме показан поток веб-запросов мобильных приложений для службы Mobility Service и службы автообнаружения при использовании внутренней и внешней конфигурации DNS.
служба с помощью автообнаружения
.jpg "cdb96424-96f2-4abf-88d7-1d32d1010ffd")
Примечание.
На схеме показаны универсальные веб-службы. Виртуальный каталог с именем Mobility представляет mcx и (или) UCWA служб Mobility Services. Если вы не применили накопительный пакет Обновления для Lync Server 2013: февраль 2013 г., виртуальный каталог Ucwa может быть определен во внутренних и внешних веб-службах. У вас будет служба автообнаружения виртуальных каталогов, а также виртуальный каталог Mcx.
Автообнаружение и обнаружение служб работают одинаково независимо от развернутой технологии служб мобильности.
Чтобы обеспечить поддержку мобильных пользователей как внутри корпоративной сети, так и за ее пределами, внутренние и внешние полные доменные имена веб-сайтов должны соответствовать некоторым предварительным требованиям. Кроме того, может потребоваться выполнить другие требования в зависимости от функций, которые вы решили реализовать:
Новые записи DNS, CNAME или A (узла, если IPv6, AAAA) для автоматического обнаружения.
новое правило брандмауэра, если необходимо обеспечить поддержку push-уведомлений в сети Wi-Fi;
Альтернативные имена субъектов для внутренних сертификатов сервера и сертификатов обратного прокси-сервера для автоматического обнаружения.
Конфигурация аппаратной подсистемы балансировки нагрузки переднего плана изменяет сходство источника.
Топология должна соответствовать следующим требованиям для поддержки службы Mobility Service и службы автообнаружения:
Внутреннее полное доменное имя внешнего веб-пула должно быть отличается от внешнего веб-полного доменного имени пула переднего плана.
Внутреннее полное доменное имя веб-сайта должно разрешаться и быть доступным только из корпоративной сети.
Полное доменное имя внешнего веб-сайта должно разрешаться и быть доступным только из Интернета.
Для пользователя, который находится в корпоративной сети, URL-адрес службы Mobility Service должен быть адресован внешнему полное доменное имя веб-сайта. Это требование относится к службе Mobility Service и применяется только к этому URL-адресу.
Для пользователя, который находится за пределами корпоративной сети, запрос должен перейти на внешнее полное доменное имя веб-сайта пула переднего плана или директора.
Если вы поддерживаете автоматическое обнаружение, необходимо создать следующие записи DNS для каждого домена SIP:
Внутренняя запись DNS для поддержки мобильных пользователей, которые подключаются из сети вашей организации.
Внешняя или общедоступная запись DNS для поддержки мобильных пользователей, подключащихся из Интернета.
Внутренний URL-адрес автоматического обнаружения не должен быть адресоваемым извне сети. Внешний URL-адрес автоматического обнаружения не должен быть адресоваемым из сети. Однако если вы не можете выполнить это требование для внешнего URL-адреса, возможно, это не повлияет на функциональный мобильный клиент, так как внутренний URL-адрес всегда используется в первую очередь.
Записи DNS могут быть либо записями CNAME, либо записями A (узла, если IPv6, AAAA).
Примечание.
Клиенты мобильных устройств не поддерживают несколько SSL-сертификатов из разных доменов. Таким образом, перенаправление CNAME в разные домены не поддерживается по протоколу HTTPS. Например, запись DNS CNAME для lyncdiscover.contoso.com, которая перенаправляет на адрес director.contoso.net не поддерживается по протоколу HTTPS. В такой топологии клиент мобильного устройства должен использовать HTTP для первого запроса, чтобы перенаправление CNAME было разрешено по протоколу HTTP. Последующие запросы затем используют ПРОТОКОЛ HTTPS. Для поддержки этого сценария необходимо настроить обратный прокси-сервер с правилом веб-публикации для порта 80 (HTTP). Дополнительные сведения см. в разделе "Создание правила веб-публикации для порта 80" в разделе "Настройка обратного прокси-сервера для мобильности в Lync Server 2013".
Перенаправление CNAME в тот же домен поддерживается по протоколу HTTPS. В этом случае сертификат конечного домена охватывает исходный домен.
Дополнительные сведения о записях DNS, необходимых для вашего сценария, см. в сводке по DNS — автообнаружение в Lync Server 2013.
Требования к портам и брандмауэру
Если вы поддерживаете push-уведомления и хотите, чтобы мобильные устройства Apple получили push-уведомления по вашей Wi-Fi сети, необходимо также открыть порт 5223 в корпоративной Wi-Fi сети. Порт 5223 — это исходящий TCP-порт, используемый службой push-уведомлений Apple (APNS). Мобильное устройство инициирует подключение. Дополнительные сведения см. в разделе http://support.apple.com/kb/TS1629 .
Предупреждение
Устройство Apple, использующее клиент Lync 2013 Mobile, не требует push-уведомлений.
Обратите внимание, что если пользователь размещен на устройстве для обеспечения связи филиалов (SBA), требуются следующие порты:
Для UcwaSipExternalListeningPort требуется порт 5088
Для UcwaSipPrimaryListeningPort требуется порт 5089
Дополнительные сведения и рекомендации по требованиям к портам и протоколам для автообнаружения см. в сводке по портам — автообнаружение в Lync Server 2013.
Требования к сертификатам
Если вы поддерживаете автоматическое обнаружение мобильных клиентов Lync, необходимо изменить альтернативные списки имен субъектов в сертификатах для поддержки безопасных подключений от мобильных клиентов. Необходимо запросить и назначить новые сертификаты, добавив альтернативные записи имени субъекта, описанные в этом разделе, для каждого сервера переднего плана и директора, на котором выполняется служба автообнаружения. Рекомендуется также изменить списки альтернативных имен субъектов в сертификатах для обратных прокси-серверов. Необходимо добавить альтернативные записи имени субъекта для каждого домена SIP в организации.
Повторная выдача сертификатов с помощью внутреннего центра сертификации обычно является простым процессом, но добавление нескольких альтернативных записей имени субъекта к общедоступным сертификатам, используемым обратным прокси-сервером, может оказаться дорогостоящим. Если у вас много доменов SIP, что делает добавление альтернативных имен субъектов очень ресурсоемким, можно настроить обратный прокси-сервер для выполнения первоначального запроса службы автообнаружения через порт 80 по протоколу HTTP, а не через порт 443 с использованием HTTPS (конфигурация по умолчанию). Затем запрос перенаправляется на порт 8080 в пуле директоров или переднего плана. При публикации первоначального запроса службы автообнаружения на порте 80 изменять сертификаты для обратного прокси-сервера не нужно, так как запрос использует HTTP, а не HTTPS. Этот подход поддерживается, но мы не рекомендуем его использовать.
Требования к службам IIS
Для мобильности рекомендуется использовать IIS 7.5, IIS 8.0 или IIS 8.5. Установщик Mobility Service устанавливает флаги в ASP.NET для повышения производительности. Службы IIS 7.5 устанавливаются по умолчанию в Windows Server 2008 R2, IIS 8.0 — в Windows Server 2012, а IIS 8.5 — на Windows Server 2012 R2. Установщик Службы Mobility Service автоматически изменяет ASP.NET параметров.
Требования к подсистеме балансировки нагрузки оборудования
В аппаратной подсистеме балансировки нагрузки, поддерживающей пул переднего плана, для источника необходимо настроить виртуальные IP-адреса внешних веб-служб для трафика веб-служб. Сходство источников позволяет обеспечить отправку нескольких подключений из одного клиента на один сервер для поддержания состояния сеанса. Дополнительные сведения о требованиях к сходствам см. в разделе "Требования к балансировке нагрузки для Lync Server 2013".
Если вы планируете поддерживать мобильные клиенты Lync только через внутреннюю сеть Wi-Fi, следует настроить виртуальные IP-адреса внутренних веб-служб для источника, как описано для внешних виртуальных IP-адресов веб-служб. В этой ситуации следует использовать source_addr (или TCP) для внутренних виртуальных IP-адресов веб-служб на аппаратной подсистеме балансировки нагрузки. Дополнительные сведения см . в разделе о требованиях к балансировке нагрузки для Lync Server 2013.
Требования к обратному прокси-серверу
Если вы поддерживаете автоматическое обнаружение мобильных клиентов Lync, необходимо обновить текущее правило публикации следующим образом:
Если вы решили обновить списки альтернативных имен субъектов на сертификатах обратного прокси-сервера и использовать HTTPS для первоначального запроса службы автообнаружения, необходимо обновить правило веб-публикации для lyncdiscover.< sipdomain>. Как правило, это сочетание с правилом публикации URL-адреса внешних веб-служб в пуле переднего плана.
Если вы решили использовать HTTP для первоначального запроса службы автообнаружения, чтобы не обновлять список альтернативных имен субъектов на сертификатах обратного прокси-сервера, необходимо создать новое правило веб-публикации для порта HTTP/TCP 80, если оно еще не существует. Если правило для HTTP/TCP 80 уже существует, его можно обновить, включив обнаружение lyncdiscover.< запись sipdomain> .