Разполагането на двойката Expressway-C и Expressway-E позволява обаждания от и до интернет с помощта на траверсални технологии на защитната стена. Това разполагане е това, което сигурно отнема вашия контрол на повикванията на място и го свързва с Cisco 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 и облака Cisco Webex. Тази концепция се нарича TLS с взаимно удостоверяване и се изисква при интегриране с Cisco Webex.

Както повикващите, така и призованите страни проверяват сертификата на другия връстник, както показва следната диаграма:

Облакът проверява самоличността на Expressway и Expressway проверява самоличността в облака. Ако например самоличността в облака в сертификата (CN или SAN) не съответства на това, което е конфигурирано на Expressway, връзката се отпада.

Ако взаимното удостоверяване е включено, Expressway-E винаги изисква сертификата на клиента. В резултат на това Мобилният и отдалеченият достъп (MRA) няма да работят, защото в повечето случаи сертификатите не се разгръщат на jabber клиенти. В сценарий между бизнес, ако повикващият обект не е в състояние да предостави сертификат, повикването е прекъснато.

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

Трафик от бизнес към бизнес, мобилен и отдалечен достъп и Cisco Webex на една и съща двойка expressway

Разговорите между бизнес и мобилен и отдалечен достъп използват порт 5061 за SIP TLS, а трафикът на Cisco Webex използва порт 5062 за SIP TLS с взаимно удостоверяване.

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

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

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

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

   • Expressway-E DNS домейн

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

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

История за показване на важността на проверката на собствеността на домейна

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

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

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

Администраторът на Hacker.com фирма задава една от нейните URIs директория да 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 трябва да поиска публичен сертификат за своя Expressway-E до един от тези органи за сертификати. За да издаде сертификата, органът за сертификати извършва процес на проверка на самоличността, въз основа на проверка на домейн проверка (за домейн валидирани сертификати) или проверка на организация (за организация валидирани сертификати).

   • Повикванията към и от облака зависят от сертификата, който е издаден на Expressway-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 към Expressway-C.

Докато сертификатите не бъдат качени в хранилището за гаранти Expressway-C, HTTPS връзката не може да бъде установена.

За да избегнете този проблем, Expressway-C е предварително инсталиран с Cisco Webex -надеждни CAсертификати. Тези сертификати се използват само за настройване и валидиране на първоначалната HTTPS връзка и те не се показват в списъка с гаранти expressway-C. След като сертификатите на надеждните органи за сертификати бъдат изтеглени от облака чрез тази първоначална HTTPS връзка, тези сертификати са достъпни за използване в цялата платформа; след това те се появяват в списъка с гаранти Expressway-C.

Този списък показва сертификатите на органа за сертификати, които облакът Cisco Webex използва в момента. Този списък може да се промени в бъдеще:

• C=IE, О=Балтимор, OU=КиберТръст, CN=Балтимор корен на кибертръст

• C=US, O=GTE Корпорация, OU=GTE Решения за кибертръст, Inc., CN=GTE CyberTrust Глобален корен

• C=US, O=The Go Daddy Group, Inc., OU=Go Татко клас 2 сертификат орган

• C=US, ST=Аризона, L=Скотсдейл, O=GoDaddy.com, Inc., CN=Go Татко главен сертификат орган - G2

• C=BM, О=Куовадис Лимитид, CN=Корен от QuoVadis CA 2

• C=US, O=thawte, Inc., OU=Отдел за сертификационни услуги, OU=(c) 2006 размразяване, Inc. - Само за разрешена употреба, CN=размразяване Основен корен CA

• C=US, O=VeriSign, Inc., OU=Клас 3 Публичен орган за първично удостоверение

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

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