Розгортання пар Expressway-C і Expressway-E дозволяє здійснювати дзвінки в Інтернет і з нього за допомогою технологійобходу брандмауера. Це розгортання надійно забезпечує контроль над локальним викликом і пов'язує його з Cisco 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 та хмарою Cisco Webex . Це поняття називається TLS з взаємною аутентифікацією і потрібно при інтеграції з Cisco Webex.

Як сторони, що телефонують, так і викликані сторони перевіряють сертифікат іншого однолітка, як показує наступна схема:

Хмара перевіряє ідентичність швидкісної дороги, а Expressway перевіряє ідентичність хмари. Наприклад, якщо хмарний ідентифікатор у сертифікаті (CN або SAN) не відповідає тому, що настроєно на швидкісній автомагістралі, з'єднання розривається.

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

Ми рекомендуємо використовувати значення, відмінне від 5061, для TLS для взаємної автентифікації, наприклад порт 5062. Гібридні служби Cisco Webex використовують той самий запис SIP TLS, який використовується для B2B. У випадку з портом 5061 деякі інші послуги, які не можуть надати сертифікат клієнта TLS, не працюватимуть.

Бізнес-бізнес, мобільний і віддалений доступ та трафік Cisco Webex на одній парі швидкісних автомагістралей

Виклики для бізнесу та мобільного та віддаленого доступу використовують порт 5061 для SIP TLS, а трафік Cisco Webex використовує порт 5062 для SIP TLS із взаємною автентифікацією.

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

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

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

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

   • Домен EXPRESSWAY-E DNS

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

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

Історія, яка показує важливість перевірки права власності на домен

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

У наведеній нижче історії докладно описано, що може статися, якщо не буде проведено перевірку права власності на домен.

Компанія з доменом DNS, для якого встановлено значення "hacker.com", купує гібридні послуги Cisco Webex . Інша компанія, з власним доменом, встановленим на "example.com", також користується гібридними сервісами. Один з генеральних менеджерів компанії Example.com носить ім'я Джейн Роу і має каталог URI jane.roe@example.com.

Адміністратор Hacker.com компанії встановлює один зі своїх URI каталогу для jane.roe@example.com, а адресу електронної пошти jane.roe@hacker.com. Вона може це зробити, оскільки хмара не перевіряє домен SIP URI в цьому прикладі.

Далі вона входить до Cisco Webex Teams з jane.roe@hacker.com. Оскільки вона володіє доменом, електронний лист для підтвердження читається та відповідається, і вона може ввійти. Нарешті, вона телефонує колезі Джону Доу, набираючи john.doe@example.com зі свого додатка Cisco Webex Teams . Джон сидить у своєму офісі і бачить дзвінок на своєму відеопристрої, що надходить з jane.roe@example.com; тобто каталог URI, пов'язаний з цим обліковим записом електронної пошти.

"Вона за кордоном", - думає він. "Можливо, їй знадобиться щось важливе". Він відповідає на телефонні дзвінки, а фальшива Джейн Роу просить важливі документи. Вона пояснює, що її пристрій зламаний, і оскільки вона подорожує, вона просить його надіслати документи на її приватну електронну адресу, jane.roe@hacker.com. Таким чином, компанія розуміє лише після того, як Джейн Роу повертається в офіс, що важлива інформація була просочена за межі компанії.

Компанія Example.com має безліч способів захисту від шахрайських дзвінків, що надходять з інтернету, але один з обов'язків хмари Cisco Webex - переконатися, що особистість будь-якого, хто телефонує з Cisco Webex , є правильною і не сфальсифікованої.

Щоб перевірити особу, Cisco Webex вимагає, щоб компанія довела, що володіє доменами, які використовуються в гібридних дзвінках. Якщо цього не станеться, не спрацює.

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

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

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

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

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

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

   • Як приклад адміністратор повинен довести, що їй належить домен «example.com», якщо вона хоче , щоб на її домені працювала cisco Webex Hybrid Services.

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

     

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

     

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

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

     

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

2. Перевірка права власності на ім'я DNS Expressway-E.

   • Хмара повинна перевірити, чи має Expressway-E підтверджену особу від одного з центрів сертифікації, яким довіряє хмара. Адміністратор Expressway-E повинен запросити публічний сертифікат для своєї швидкісної автомагістралі-E в одному з цих центрів сертифікації. Щоб видати сертифікат, центр сертифікації виконує процес перевірки ідентичності на основі перевірки валідації домену (для сертифікатів, підтверджених доменом) або перевірки валідації організації (для перевірених організацією сертифікатів).

   • Дзвінки в хмару і з неї залежать від сертифіката, який був виданий швидкісній автомагістралі-Е. Якщо сертифікат недійсний, виклик відпадає.

Хост роз'єму Expressway-C повинен бути зареєстрований на Cisco Webex , щоб гібридні сервіси працювали.

Expressway-C розгортається у внутрішній мережі, і спосіб реєстрації в хмарі здійснюється через вихідне з'єднання HTTPS - той самий тип, який використовується для будь-якого браузера, який підключається до веб-сервера.

Реєстрація та зв'язок з хмарою Cisco Webex використовує TLS. Expressway-C - це клієнт TLS, а хмара Cisco Webex - сервер TLS. Таким чином, Expressway-C перевіряє сертифікат сервера.

Центр сертифікації підписує сертифікат сервера за допомогою власного закритого ключа. Будь-який користувач, який має відкритий ключ, може розшифрувати цей підпис і довести, що той самий центр сертифікації підписав цей сертифікат.

Якщо Expressway-C має перевірити сертифікат, наданий хмарою, він повинен використовувати відкритий ключ центру сертифікації, який підписав цей сертифікат, щоб розшифрувати підпис. Відкритий ключ міститься в сертифікаті центру сертифікації. Щоб встановити довіру до центрів сертифікації, які використовуються хмарою, список сертифікатів цих надійних центрів сертифікації має зберігатися в довірчому магазині Expressway. Роблячи це, швидкісна автомагістраль може переконатися, що дзвінок дійсно надходить з хмари Cisco Webex .

За допомогою завантаження вручну ви можете завантажити всі відповідні сертифікати центру сертифікації в надійний магазин Expressway-C.

Завдяки автоматичному завантаженню хмара сама завантажує ці сертифікати в надійний магазин Expressway-C. Рекомендуємо використовувати автоматичне передавання. Список сертифікатів може змінитися, і автоматичне передавання гарантує отримання найбільш оновленого списку.

Якщо дозволити автоматичну інсталяцію сертифікатів центру сертифікації, вас буде переспрямовано на https://admin.webex.com (портал керування). Перенаправлення здійснюється самою Expressway-C без будь-якого втручання користувача. Ви, як адміністратор Cisco Webex , повинні пройти автентифікацію через HTTPS-з'єднання. Незабаром після цього хмара переміщує сертифікати CA на швидкісну автомагістраль C.

Поки сертифікати не будуть завантажені в магазин довіри Expressway-C, з'єднання HTTPS не може бути встановлено.

Щоб уникнути цієї проблеми, на expressway-C попередньо інстальовано сертифікати ЦС Cisco Webex. Ці сертифікати використовуються лише для налаштування та перевірки початкового з'єднання HTTPS, і вони не відображаються в списку довіри Expressway-C. Після того, як сертифікати надійних центрів сертифікації будуть витягнуті з хмари через це початкове з'єднання HTTPS, ці сертифікати доступні для використання на всій платформі; потім вони з'являються в списку довіри Expressway-C.

У цьому списку відображаються сертифікати центру сертифікації, які зараз використовує хмара Cisco Webex . Цей список може змінитися в майбутньому:

• C=IE, O=Baltimore, OU=CyberTrust, CN=Baltimore CyberTrust Root

• C=US, O=GTE Corporation, OU=GTE CyberTrust Solutions, Inc., CN=GTE CyberTrust Global Root

• C= US, O = The Go Daddy Group, Inc., OU = Go Daddy Class 2 Центр сертифікації

• C=US, ST=Арізона, L=Scottsdale, O=GoDaddy.com, Inc., CN=Go Daddy Root Certificate Authority - G2

• C=BM, O=QuoVadis Limited, CN=QuoVadis Root CA 2

• C=US, O=thawte, Inc., OU=Відділ сертифікаційних послуг, OU=(c) 2006 thawte, Inc. - Лише для дозволеного використання, CN=thawte Primary Root CA

• C=US, O=VeriSign, Inc., OU=Державний первинний орган сертифікації класу 3

Список сертифікатів центру сертифікації також необхідний для швидкісної дороги-E в обхідній парі. Expressway-E зв'язується з хмарою Cisco Webex за допомогою SIP з TLS, що забезпечується взаємною аутентифікацією. Expressway-E довіряє дзвінкам, що надходять з хмари і надходять до неї, тільки якщо CN або SAN сертифіката, представленого хмарою під час налаштування TLS-з'єднання, збігається з ім'ям теми, налаштованої для зони DNS на Expressway («callservice.ciscospark.com»). Центр сертифікації видає сертифікат лише після перевірки особи. Право власності на callservice.ciscospark.com домен необхідно довести, щоб отримати підписаний сертифікат. Оскільки ми (Cisco) володіємо цим доменом, ім'я DNS "callservice.ciscospark.com" є прямим доказом того, що віддалений аналог дійсно Cisco Webex.

З'єднувач календаря інтегрує Cisco Webex з Microsoft Exchange 2010, 2013, 2016 або Office 365 через обліковий запис видавання себе за іншу особу. Роль керування видаванням себе за програму в Exchange дає змогу програмам видавати себе за користувачів в організації для виконання завдань від імені користувача. Роль уособлення програми повинна бути налаштована в Exchange і використовуватися в з'єднувачі календаря як частина конфігурації Exchange в інтерфейсі Expressway-C .

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

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