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

Ці моменти мають вирішальне значення, якщо ви хочете успішно розгорнути гібридний виклик для пристроїв 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 виглядає так:

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

priority = 10

weight = 10

port = 5062

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

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

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 і Remote Access (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 

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

Бізнес-бізнес (B2B), мобільні та Remote Access (MRA) дзвінки використовують порт 5061 для SIP TLS, а трафік Webex використовує порт 5062 для SIP TLS із взаємною аутентифікацією.

Перевірка права власності на домен є частиною перевірки особи. Перевірка домену - це захід безпеки та перевірка особистості, яку впроваджує хмара Webex, щоб довести, що ви є тим, ким ви вважаєте себе.

Перевірка особи виконується в два етапи:

1. Перевірка права власності на домен. Цей крок включає три типи доменів і є одноразовою перевіркою перевірки:

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

   • Expressway-E DNS домен

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

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

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

Хмара 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 вимагає, щоб компанія довела, що вона володіє доменами, які використовуються в Hybrid Calling. Якщо це не так, гібридні служби не працюватимуть.

Щоб забезпечити таку власність, необхідно виконати два етапи перевірки домену:

1. Доведіть, що компанія володіє доменом електронної пошти, доменом Expressway-E, доменом URI Directory.

   • Усі ці домени повинні бути маршрутизовані та відомі загальнодоступними 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 для цього домену зі значенням 123456789abcdef123456789abcdef123456789abcdef 123456789abcdef123456789abcdef, як у наступному прикладі:

     

   • На цьому етапі хмара може перевірити, що запис TXT для домену example.com відповідає токену.

   • Хмара виконує пошук TXT DNS:

     

   • Оскільки значення TXT відповідає значенню токена, ця відповідність доводить, що адміністратор додав запис TXT для власного домену до загальнодоступного DNS і що вона володіє доменом.

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

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

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

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