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

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

_глътки. _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 проверява идентичността на облака. Например, ако идентичността на облака в сертификата (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 

Бизнес-бизнес, мобилен и Webex трафик Remote Access по една и съща двойка скоростни пътища

Разговорите между бизнеса (B2B) и мобилни и Remote Access (MRA) използват порт 5061 за SIP TLS, а трафикът на Webex използва порт 5062 за SIP TLS с взаимно удостоверяване.

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

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

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

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

   • Експресвай-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 задава един от своите URL адреси на 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 на директорията.

   • Всички тези домейни трябва да бъдат маршрутизируеми и известни от публичните 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 запис за този домейн със стойността, зададена на 123456789abcdef123456789abcdef 123456789abcdef123456789abcdef, както в следния пример:

     

   • В този момент облакът може да провери дали TXT записът за домейна example.com съвпада с токена.

   • Облакът извършва TXT DNS търсене:

     

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

2. Проверка на собствеността на името на DNS Expressway-E.

   • Облакът трябва да провери дали Expressway-E има потвърдена самоличност от един от органите за сертифициране, на които облакът има доверие. Администраторът на Expressway-E трябва да поиска публичен сертификат за своя Expressway-E до един от тези органи за сертифициране. За да издаде сертификата, сертифициращият орган извършва процес на проверка на самоличността въз основа на проверка на валидирането на домейна (за валидирани сертификати за домейн) или проверка на валидирането на организацията (за сертифицирани от организацията).

   • Обажданията към и от облака зависят от сертификата, издаден на Expressway-E. Ако сертификатът не е валиден, обаждането се отказва.

Конекторът за устройство Webex трябва да комуникира с 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.

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

За допълнителна сигурност следвайте стъпките в Ръ ководството за внедряване на Cisco Webex хибридна услуга за календар, за да активирате TLS, за да защитите EWS връзките на проводника.

За допълнителна сигурност изпълнете стъпките в Внедряване на конектор за календар на експресните пътища, за Microsoft Exchange да активирате TLS, за да защитите EWS връзките на проводника.