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

Ці моменти є вирішальними для успішного розгортання гібридних викликів для пристроїв Webex. Ми виділили ці пункти, зокрема, з таких причин:

• Ми хочемо пояснити їх, щоб ви зрозуміли їхню роль у гібридному розгортанні та відчули заспокоєння.

• Вони є обов'язковими передумовами, які забезпечують безпечне розгортання між нашою хмарою та вашим локальним середовищем.

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

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

Розгортання пари Expressway-C та Expressway-E дозволяє здійснювати дзвінки до та з Інтернету за допомогою технологій обходу брандмауера. Це розгортання безпечно переносить ваше локальне керування викликами та пов’язує його з Webex.

Швидкісна автомагістраль C і Expressway-E не вимагають відкриття будь-якого вхідного порту в брандмауері демілітаризованої зони (DMZ) через архітектуру обходу брандмауера. Але сигнальні порти TCP SIP і медіапорти UDP повинні бути відкриті на вході в інтернет-брандмауер, щоб пропускати вхідні дзвінки. Ви повинні дати час, щоб відповідний порт був відкритий у корпоративному брандмауері.

Архітектура обходу брандмауера показана на наступній схемі:

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

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

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

Приклад

У цьому прикладі ми припускаємо, що порт 5062 використовується для вхідних викликів SIP TLS.

Запис DNS SRV для кластера з двох серверів Expressway виглядає так:

_sips._tcp.example.com Розташування служби SRV:

пріоритет = 10

вага = 10

порт = 5062

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

_sips._tcp.example.com Розташування служби SRV:

пріоритет = 10

вага = 10

порт = 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 перевіряє ідентичність хмари. Наприклад, якщо хмарний ідентифікатор у сертифікаті (CN або SAN) не відповідає тому, що настроєно на швидкісній автомагістралі, з'єднання розривається.

Якщо взаємна аутентифікація ввімкнена, Expressway-E завжди запитує сертифікат клієнта. В результаті мобільний і віддалений доступ (MRA) не працюватимуть, оскільки в більшості випадків сертифікати не розгортаються на клієнтах Jabber. У сценарії business-to-business, якщо суб'єкт, що телефонує, не може надати сертифікат, дзвінок відключається.

Ми рекомендуємо використовувати значення, відмінне від 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. Перевірка права власності на домен. Цей крок включає в себе три типи доменів і являє собою одноразову перевірку перевірки:

   • Домен електронної пошти

   • Домен EXPRESSWAY-E DNS

   • Каталог доменів URI

2. Перевірка права власності на ім'я EXPRESSWAY-E DNS. Цей крок виконується за допомогою впровадження TLS з взаємною аутентифікацією і передбачає використання публічних сертифікатів як на хмарі, так і на швидкісній трасі. На відміну від перевірки ідентичності домену, цей крок виконується під час будь-якого дзвінка, здійсненого та отриманого з хмари.

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

Хмара 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. Вона може це зробити, оскільки хмара не перевіряє домен 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, доменом Directory URI.

   • Усі ці домени повинні бути маршрутизовані та відомі публічним DNS-серверам.

   • Щоб підтвердити право власності, адміністратор DNS повинен ввести текстовий запис DNS (TXT). Запис TXT — це тип запису ресурсу в службі DNS, який використовується для надання можливості пов'язувати деякий довільний і неформатований текст з хостом або іншим іменем.

   • Адміністратор DNS повинен ввести цей запис TXT в зоні, право власності на яку необхідно довести. Після цього кроку хмара Webex виконує запит запису TXT для цього домену.

   • Якщо запит TXT успішний і результат відповідає токену, згенерованому з хмари Webex, домен перевіряється.

   • Наприклад, адміністратор повинен довести, що він є власником домену "example.com", якщо хоче, щоб гібридні послуги Webex працювали на його домені.

   • Через 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 повинен запросити публічний сертифікат для своєї швидкісної автомагістралі-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.

Список сертифікатів центру сертифікації також необхідний для швидкісної дороги-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 не потрібно знати пароль, оскільки значення може ввести в інтерфейс Expressway-C адміністратор Exchange. Пароль чітко не відображається, навіть якщо адміністратор Expressway-C має root-доступ до вікна Expressway-C. Пароль зберігається в зашифрованому вигляді за допомогою того ж механізму шифрування облікових даних, що й інші паролі на Expressway-C.

Для додаткової безпеки виконайте дії, наведені в посібнику з розгортання для служби гібридного календаря Cisco Webex, щоб увімкнути TLS для захисту з 'єднань EWS на дроті.

Щоб отримати додаткову безпеку, виконайте вказівки в розділі Розгортання роз 'єму календаря швидкісних автомагістралей для Microsoft Exchange, щоб увімкнути TLS для захисту з' єднань EWS на дроті.