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

Тези точки са от решаващо значение, ако искате успешно да внедрите хибридни разговори за устройства на 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 запис, както следва:

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

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

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

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

Компания с DNS домейн, зададен на „hacker.com“, купува Webex Hybrid Services. Друга компания, със собствен домейн, настроен на "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 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 cloud е TLS сървърът. По този начин Webex Device Connector проверява сертификата на сървъра.

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

Ако Webex Device Connector трябва да валидира сертификата, предоставен от облака, той трябва да използва публичния ключ на сертифициращия орган, който е подписал този сертификат, за да декодира подписа. Публичен ключ се съдържа в сертификата на сертификатния орган. За да се установи доверие със сертифициращите органи, използвани от облака, списъкът със сертификати на тези доверени сертифициращи органи трябва да бъде в хранилището за доверени сертификати на Webex Device Connector.

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

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