Този раздел осигурява допълнителен контекст за ключови елементи на конфигуриране, които се отнасят до хибридните услуги.

Тези точки са от решаващо значение, ако искате успешно да разположите хибридни повиквания за устройства с 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._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) трябва да query на 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 винаги изисква сертификата на клиента. В резултат на това Мобилният и отдалеченият достъп (MRA) няма да работят, защото в повечето случаи сертификатите не се разгръщат на jabber клиенти. В сценарий между бизнес, ако повикващият обект не е в състояние да предостави сертификат, повикването е прекъснато.

Препоръчваме ви да използвате стойност, различна от 5061 за TLS с взаимно удостоверяване, например порт 5062. Хибридните услуги на Webex използват същия SIP TLS запис, който е използван за B2B. В случай на порт 5061 някои други услуги, които не могат да предоставят TLS клиентски сертификат няма да работи.

Ако съществуващ запис вече се използва за бизнес комуникации, препоръчваме да посочите поддомейн на корпоративния домейн като местоназначение на SIP в Control Hub, а оттам и публичен DNS SRV запис, както следва:

 Услуга и протокол: _sips._tcp.mtls.example.com Приоритет: 1 Тегло: 10 Номер на порт: 5062 Цел: us-expe1.example.com 

Достъп „бизнес към бизнес“, мобилен и отдалечен достъп и трафик на Webex на една и съща двойка Expressway

Повикванията „бизнес към бизнес“ (B2B) и мобилния и дистанционния достъп (MRA) използват порт 5061 за SIP TLS, а трафикът на Webex използва порт 5062 за SIP TLS с взаимно удостоверяване.

Проверката на собствеността на домейна е част от проверката на самоличността. Потвърждаването на домейн е мярка за защита и проверка на самоличността, която облакът на Webex прилага, за да докаже, че сте този, който казвате, че сте.

Проверката за самоличност се извършва на два етапа:

1. Проверка на собствеността на домейна. Тази стъпка включва три типа домейни и е еднократна проверка за проверка:

   • Имейл домейн

   • Expressway-E DNS домейн

   • Домейн на URI на директорията

2. Проверка на собствеността на DNS имена на Expressway-E. Тази стъпка се извършва чрез изпълнението на TLS с взаимно удостоверяване и включва използването на публични сертификати както на облака, така и на Експресния път. За разлика от проверката за самоличност на домейн, тази стъпка се извършва по време на всяко обаждане, направено до и получено от облака.

Значението на проверката за собственост на домейна

Облакът на Webex изпълнява проверката за притежание на домейна, за да наложи защита. Кражбата на самоличност е една възможна заплаха, ако тази проверка не се извърши.

Следната история подробно описва какво може да се случи, ако не се извърши проверка на собствеността на домейн.

Компания с DNS домейн, зададен на "hacker.com", купува хибридни услуги на Webex. Друга компания, със собствен домейн, настроен на "example.com", също използва хибридни услуги. Един от генералните мениджъри на фирмата Example.com се казва Джейн Рое и има директорията URI jane.roe@example.com.

Администраторът на Hacker.com фирма задава една от нейните URIs директория да 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 трябва да поиска публичен сертификат за своя 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.

При комуникация с устройства инструментът използва надеждни сертификати, които предоставяте. В момента начинът да направите това е като ги поставите в [домашна папка]/.devicestool/сертификати.

За Експресуей-Е в траверсната двойка се изисква и списък на сертификатите на сертифициращия орган. 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 връзки на проводника.