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

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

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

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

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

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

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

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

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

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

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

Несмотря на то, что для SIP TCP стандартным является порт 5060, а для SIP TLS – порт 5061, ограничения на использование других портов отсутствуют (см. следующий пример).

Пример

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

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

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

priority = 10

weight = 10

port = 5062

svr hostname = us-expe1.example.com

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

priority = 10

weight = 10

port = 5062

svr hostname = us-expe2.example.com

Эти записи означают, что вызовы перенаправляются на us-expe1.example.com и us-expe2.example.com с равномерным распределением нагрузки (priority и weight) с помощью 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 проверяет удостоверение облака. Например, если удостоверение облака в сертификате (стандартное или альтернативное имя) не соответствует настройкам Expressway, соединение будет разорвано.

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

Рекомендуется не использовать значение порта 5061 для TLS с взаимной аутентификацией, а использовать другое значение, например 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 по одной и той же паре каналов Expressway.

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

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

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

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

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

   • домен DNS Expressway-E;

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

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

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

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

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

Компания, чей DNS-домен настроен на "hacker.com", приобретает Webex Hybrid Services. Другая компания, владеющая собственным доменом "example.com", также пользуется службами гибридного типа. Один из руководителей компании Example.com по имени Джейн Роу является владельцем URI каталога jane.roe@example.com.

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

Затем она входит в приложение 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.

   • Облако выполнит поиск TXT в DNS.

     

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

2. Проверка права собственности на имя DNS Expressway-E.

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

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

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

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

Для связи с облаком Webex используется протокол TLS. Webex Device Connector — это 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, является рекомендуемым методом Microsoft для решения этой задачи. Администраторы Expressway-C не должны знать пароль, поскольку администратор Exchange может ввести его в интерфейсе Expressway-C. Пароль не отображается даже при наличии у администратора Expressway-C полного доступа к почтовому ящику Expressway-C. Пароль хранится в зашифрованном виде с использованием такого же механизма шифрования учетных данных, как и для остальных паролей в Expressway-C.

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

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