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

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

• Мы хотим объяснить их, чтобы вы понимали их роль в гибридном развертывании и чувствовали себя уверенно.

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

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

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

Развертывание пар Expressway-C и Expressway-E позволяет звонить в Интернет и из Интернета с использованием технологий обхода брандмауэра. Это развертывание позволяет безопасно управлять локальными вызовами и связывать его с Webex.

Expressway-C и Expressway-E не требуют открытия входящих портов в брандмауэре демилитаризованной зоны (DMZ) из-за архитектуры обхода брандмауэра. Но для приема входящих вызовов необходимо открыть сигнальные порты TCP SIP и мультимедийные порты UDP на брандмауэре Интернета. Необходимо подождать некоторое время, чтобы открыть соответствующий порт на корпоративном брандмауэре.

Архитектура обхода брандмауэра показана на следующей диаграмме:

Например, для входящих корпоративных звонков (B2B) по протоколу SIP на внешнем брандмауэре должны быть открыты порты TCP 5060 и 5061 (5061 используется для протокола SIP TLS), а также мультимедийные порты UDP, используемые для таких сервисов, как передача голоса, видео, обмен контентом, двойное видео и т. д. Какие мультимедийные порты открывать, зависит от количества одновременных вызовов и количества сервисов.

Порт прослушивания SIP на Expressway можно настроить на любое значение в диапазоне от 1024 до 65534. В то же время это значение и тип протокола должны быть указаны в публичных DNS SRV записях и открыть это же значение на брандмауэре Интернета.

Хотя стандартом для SIP TCP является 5060, а для SIP TLS 5061, ничто не препятствует использованию разных портов, как показано в следующем примере.

Пример

В этом примере предполагается, что порт 5062 используется для входящих вызовов SIP TLS.

DNS SRVЗапись для кластера из двух серверов Expressway выглядит следующим образом:

_sips. Местонахождение сервиса SRV _tcp.example.com:

priority = 10

weight = 10

port = 5062

имя хоста svr = us-expe1.example.com

_корабли. Местонахождение сервиса SRV _tcp.example.com:

priority = 10

weight = 10

port = 5062

имя хоста svr = us-expe2.example.com

Эти записи означают, что вызовы направляются на us-expe1.example.com и us-expe2.example.com с равным распределением нагрузки (приоритет и вес) с использованием TLS в качестве типа транспорта и 5062 в качестве номера порта прослушивания.

Внешнее по отношению к сети устройство (в Интернете) , которое звонит по протоколу SIP пользователю корпоративного домена (user1@example.com), должно запросить DNS, чтобы узнать, какой тип транспорта использовать, номер порта, способ распределения трафика и на какие SIP-серверы отправлять вызов.

Если запись DNS содержит _sips. _tcp, в записи указывается протокол SIP TLS.

TLS является протоколом клиент-сервер и в наиболее распространенных реализациях использует сертификаты для аутентификации. В сценарии межкорпоративных звонков клиент TLS является вызывающим устройством, а сервер TLS — вызываемым устройством . При использовании протокола TLS клиент проверяет сертификат сервера и, если проверка не удалась, он отключает вызов. Клиенту не нужен сертификат.

Рукопожатие по протоколу TLS показано на следующей диаграмме:

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

Как показано на следующей диаграмме, как звонящие, так и вызывающие стороны проверяют сертификат другого однорангового узла:

Облако проверяет идентификационные данные Expressway, а Expressway проверяет идентификационные данные в облаке. Например, если идентификатор облака в сертификате (CN или SAN) не совпадает с идентификатором, настроенным на Expressway, соединение прерывается.

Если включена взаимная аутентификация, Expressway-E всегда запрашивает сертификат клиента. В результате Mobile and Remote Access (MRA) не будет работать, поскольку в большинстве случаев сертификаты не развертываются на клиентах Jabber. В сценарии «бизнес-бизнес», если вызывающая организация не может предоставить сертификат, вызов прерывается.

Для протокола TLS с взаимной аутентификацией рекомендуется использовать значение, отличное от 5061, например порт 5062. Гибридные сервисы Webex используют ту же запись SIP TLS, что и для B2B. В случае порта 5061 некоторые другие сервисы, которые не могут предоставить сертификат клиента TLS, работать не будут.

Если существующая запись уже используется для обмена данными между компаниями, мы рекомендуем указать субдомен корпоративного домена в качестве места назначения SIP в Control Hub и, следовательно, DNS SRV публичной записи следующим образом:

 Service and protocol: _sips._tcp.mtls.example.com 
Priority: 1 
Weight: 10 
Port number: 5062 
Target: us-expe1.example.com 

Трафик между компаниями, мобильные устройства и трафик Webex на одной Remote Access и той же паре Expressway

Для звонков между компаниями (B2B), мобильных вызовов и Remote Access (MRA) используется порт 5061 для SIP TLS, а трафик Webex использует порт 5062 для SIP TLS с взаимной аутентификацией.

Проверка владения доменом является частью проверки личности. Верификация домена — это мера безопасности и проверка личности, применяемая в облаке Webex для подтверждения того, что вы являетесь тем, за кого себя выдаете.

Проверка личности выполняется в два этапа:

1. Проверка владения доменом. Этот шаг включает три типа доменов и представляет собой одноразовую проверочную проверку:

   • Домен электронной почты

   • DNS-домен Expressway-E

   • URI-домен каталога

2. Проверка владения DNS-именем Expressway-E. Этот шаг выполняется путем внедрения протокола TLS с взаимной аутентификацией и включает использование публичных сертификатов как в облаке, так и на скоростной автомагистрали. В отличие от проверки личности домена, этот шаг выполняется во время любого звонка, поступающего в облако и получаемого из облака.

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

Облако Webex выполняет проверку владения доменом для обеспечения безопасности. Кража личных данных является одной из возможных угроз, если эта проверка не будет выполнена.

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

Компания, в домене DNS которой задано имя «hacker.com», покупает гибридные сервисы Webex. Другая компания с собственным доменом example.com также использует гибридные сервисы. Одну из генеральных менеджеров компании Example.com зовут Джейн Роу, у нее есть каталог URI jane.roe@example.com.

Администратор компании Hacker.com задает одному из URI своего каталога jane.roe@example.com, а адрес электронной почты — jane.roe@hacker.com. Она может это сделать, потому что в данном примере облако не проверяет домен SIP URI.

Затем она входит в приложение Webex, используя адрес jane.roe@hacker.com. Поскольку домен принадлежит ей, письмо с подтверждением прочитано, на него будут даны ответы, и она сможет войти в систему. Наконец, она звонит коллеге Джону Доу по номеру john.doe@example.com в своем приложении Webex. Джон сидит в своем офисе и видит на своем видеоустройстве звонок от jane.roe@example.com; это URI каталога, связанный с этой учетной записью электронной почты.

Он думает: «Она за границей». «Возможно, ей нужно что-то важное». Он отвечает на телефонные звонки, а фальшивая Джейн Роу просит предоставить важные документы. Она объясняет, что ее устройство сломалось, и поскольку она путешествует, она просит его отправить документы на ее личный адрес электронной почты jane.roe@hacker.com. Таким образом, только после возвращения Джейн Роу в офис компания понимает, что важная информация была утечена за пределы компании.

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

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

Чтобы удостовериться в этом праве собственности, необходимо выполнить два этапа проверки домена:

1. Докажите, что компания владеет доменом электронной почты, доменом Expressway-E, доменом URI каталога.

   • Все эти домены должны быть маршрутизируемыми и известными общедоступным DNS-серверам.

   • Чтобы подтвердить право собственности, администратор DNS должен ввести текстовую запись DNS (TXT). Запись TXT — это тип ресурсной записи в DNS, используемый для связывания произвольного и неформатированного текста с именем хоста или другим именем.

   • Администратор DNS должен ввести эту TXT-запись в зоне, право собственности на которую необходимо подтвердить. После этого шага облако Webex выполняет запрос к записи TXT для этого домена.

   • Если запрос TXT выполнен успешно и результат совпадает с токеном, созданным в облаке Webex, домен проверяется.

   • Например, администратор должен доказать, что она владеет доменом example.com, если он хочет, чтобы Webex Hybrid Services работал в этом домене.

   • На сайте https://admin.webex.com она начинает процесс проверки с создания TXT-записи, соответствующей токену, созданному облаком Webex:

     

   • Затем администратор DNS создает TXT-запись для этого домена со значением 123456789abcdef123456789abcdef123456789abcdef123456789abcdef, как показано в следующем примере:

     

   • На этом этапе облако может проверить, соответствует ли TXT-запись домена example.com токену.

   • Облако выполняет поиск в DNS в формате TXT:

     

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

2. Проверка владения DNS-именем Expressway-E.

   • Облако должно убедиться, что Expressway-E имеет подтвержденную идентификацию от одного из центров сертификации, которым доверяет облако. Администратор Expressway-E должен запросить публичный сертификат для своего Expressway-E в одном из этих центров сертификации. Чтобы выдать сертификат, центр сертификации выполняет процесс проверки личности на основе проверки домена (для валидированных сертификатов домена) или проверки организации (для валидированных сертификатов организации).

   • Вызовы в облако и из облака зависят от сертификата, выданного Expressway-E. Если сертификат недействителен, вызов будет прерван.

Для работы гибридных вызовов соединитель устройства Webex должен взаимодействовать с Webex.

Webex Device Connector развернут во внутренней сети и обменивается данными с облаком через исходящее HTTPS-соединение — тот же тип, который используется в любом браузере, подключающемся к веб-серверу.

Для связи с облаком Webex используется протокол TLS. Коннектор устройств Webex является клиентом TLS, а облако Webex — сервером TLS. Таким образом, Webex Device Connector проверяет сертификат сервера.

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

Если Webex Device Connector необходимо проверить сертификат, предоставленный облаком, для декодирования подписи необходимо использовать открытый ключ центра сертификации, подписавшего этот сертификат. Открытый ключ содержится в сертификате центра сертификации. Чтобы установить доверие к центрам сертификации, используемым в облаке, список сертификатов этих доверенных центров сертификации должен находиться в доверенном хранилище Webex Device Connector.

При обмене данными с устройствами инструмент использует предоставленные вами доверенные сертификаты. В настоящее время это можно сделать, разместив их [home folder]/.devicestool/certs.

Для Expressway-E в обходной паре также необходим список сертификатов центров сертификации. Expressway-E взаимодействует с облаком Webex с использованием протокола SIP и TLS, обеспечиваемого взаимной аутентификацией. Expressway-E доверяет звонкам, поступающим из облака и отправляемым в облако, только если CN или SAN сертификата, представленного облаком при настройке соединения TLS, совпадают с именем субъекта, настроенным для зоны DNS на Expressway («callservice.webex.com»). Центр сертификации выпускает сертификат только после проверки личности. Для подписания сертификата необходимо подтвердить право собственности на домен callservice.webex.com. Поскольку этот домен принадлежит нам (Cisco), DNS-имя «callservice.webex.com» является прямым доказательством того, что удаленным узлом действительно является Webex.

Коннектор календаря интегрирует Webex с Microsoft Exchange 2013, 2016, 2019 или Office 365 с помощью учетной записи, выдающей себя за другое лицо. Роль управления выдачей себя за другое лицо в Exchange позволяет приложениям выдавать себя за пользователей в организации для выполнения задач от имени пользователя. Роль выдачи себя за приложение должна быть настроена в Exchange и использоваться в соединителе календаря как часть конфигурации Exchange в интерфейсе Expressway-C.

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

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

Для дополнительной безопасности следуйте инструкциям в разделе Развертывание Expressway Calendar ConnectorMicrosoft Exchange, чтобы включить протокол TLS для защиты проводных подключений EWS.