Пришло время сделать так чтобы корпоративные сервисы связи были доступны вне офиса без дополнительных телодвижений со стороны пользователя вроде использования приложения Cisco Anyconnect и/или установки дополнительных VPN-туннелей.
В этом выпуске я покажу и объясню, как настроить Cisco Expressway сервера чтобы видеоконференцсвязь работала не только внутри, но и за пределами вашей организации.
Cisco Expressway обеспечивает безопасный межсетевой экран для передачи голоса и видео и поддерживает множество функций, таких как B2B вызовы и мобильный и удаленный доступ (MRA), а также возможности сервера TURN(Traversal Using Relay NAT). Таким образом, это то, что называется решением Single Edge и является предпочтительным пограничным решением Cisco для унифицированных коммуникаций и Cisco Meeting Server.
Серверы Cisco Expressway ставятся, как Core(Expressway-C) и Edge(Expressway-E). При установке с нуля они ещё не являются Expressway'ями как таковыми, они ещё пока VCS-серверы.
Для того чтобы наши свежеустановленные VCS-сервера стали Expressway'ями каждому нужно установить нужные лицензии.
На каждый сервер, независимо будет он Edge или Core требуется лицензия LIC-SW-EXP-K9 или проще говоря Release key.
Чтобы VCS-сервер стал Expressway'ем Core требуются лицензии:
Чтобы VCS-сервер стал Expressway'ем Edge требуются лицензии:
Опционально можно добавить следующие лицензии:
LIC-EXP-MSFT-PMP — Microsoft Interoperability Option (Для Expressway-C) нужна для взаимодействия со Skype for Business
LIC-EXP-DSK — Expressway Desktop Endpoint License (Для Expressway-C) нужна для регистрации на Expressway персональных устройств.
LIC-EXP-ROOM — Expressway ROOM License для регистрации на Expressway кодеков видеоконференцсвязи.
LIC-TP-ROOM — Есть ещё такая лицензия для CUCM, чтобы зарегистрировать кодек на CallManager'е, опционально в неё входит лицензия LIC-EXP-ROOM.
LIC-EXP-AN — Advanced Networking опция дополнительного сетевого интерфейса(Как для Expressway-C, так и для Expressway-Е)
LIC-EXP-RMS-PMP — Rich Media Session лицензии (Как для Expressway-C, так и для Expressway-Е)
Потребление лицензии Rich Media Session в зависимости от типа соединения:
В моём случае предполагается, что виртуальные машины уже установлены и сетевые интерфейсы на них настроены.
Немного забегая вперед скажу, что связку Expressway-С и Expressway-E можно разворачивать по нескольким сценариям.
Относительно доменов может быть два варианта:
Single domain
Это когда, как внутри, так и снаружи вашей сети один и тот же домен example.com.
Dual domain
Это когда внутри у вас домен example.local, а снаружи example.com.
Относительно топологии рекомендуется использовать два сетевых интерфейса по каждому в одну отдельную DMZ, но это достаточно редкий случай, мы рассмотрим два других варианта:
DMZ — что это?
1. DMZ с одним интерфейсом локальной сети Expressway-E.
В это варианте есть возможность задать белый ip-адрес, который вам выдал(или выдаст) провайдер. В таком варианте в дальнейшем не потребуется настройка NAT-Reflection на вашем firewall'е, которая в свою очередь нужна для нормальной работы Cisco Meeting Server'a за пределами сети.
2. DMZ с двумя интерфейсами локальной сети Expressway-E.
Для данного функционала должна быть активирована опция Advanced Networking в ключах лицензий.
Также в обоих случаях в зависимости от вашего сценария нужно указать за NAT'ом этот ip-адрес будет смотреть в Интернет или нет.
В зависимости от того, кластер вы разворачиваете или нет, Single или Dual-Domain на внешнем и внутреннем DNS серверах нужно завести следующие записи:
Обратите внимание, что если у Вас Dual-Domain, то на внутреннем DNS сервере требуется создать зону с внешним доменом и уже в нём создать записи выделенные красным. Делается это для того, чтобы пользователи могли логиниться в своих Cisco Jabber приложениях с одинаковым логином, как снаружи так и внутри корпоративной сети(с внешним доменом, обычно логины совпадают с адресом электронной корпоративной почты) независимо от того где они находятся внутри или снаружи корпоративной сети.
Также требуется создать домены и указать какие сервисы должны подерживаться для этого домена.
На Expressway-C нужно указать оба домена, если используется сценарий Dual-Domain.
На Expressway-E, если используется сценарий Dual-Domain, нужно указать также все(в моем случае их два, а может быть и больше) домены которые требуются.
Серверы Expressway работают друг с другом и с остальными посредством сертификатов. Поэтому корневые и промежуточные сертификаты центров сертификации от которых получены сертификаты теми серверами которые будут работать с Expressway должны быть указаны как доверенные.
В меню Maintenance->Security->Trust CA certificate загружаем эти самые корневые и промежуточные сертификаты.
В нашем случае для Expressway-C сертификат будет выдан своим(серым) центром сертификации, который равносилен самоподписанному, а для Expressway-E сертификат будет выдан от белого центра сертификации Let's encrypt.
Эти сертификаты бесплатные, но каждые три месяца их нужно продлевать, но у Expressway есть функционал автоматического продления, об этом ниже.
Относительно бесплатного белого сертификата Let's Encrypt.
1. Проходим по ссылкам промежуточного сертификата и корневого сертификата
2. Требуется преобразовать цепочку .p7b в корневой сертификат, который примет наш Expressway, для этого для Windows 10:
Нажимаем правой кнопкой мыши на файл и выбираем Open with > Crypto Shell Extensions
Нажимаем правой кнопкой мыши на «DST Root CA X3», выбираем All Tasks, Export и Сохраняем.
Для linux конвертируем p7b формат в формат pem командой:
openssl pkcs7 -inform der -in
dstrootcax3.p7c -print_certs -out dstrootcax3.pem.
3. Копируем содержимое промежуточного сертификата в блокнот и сохраняем, например, как lets-encrypt-x3-cross-signed.pem.txt.
Update: Промежуточный сертификат поменяли на вот этот.
По предыдущему будет вот такая ошибка:
CME deploy operation failed: The trust chain for the pending certificate is missing or invalid.
4. Загружаем оба сертификата в Trust CA на Expressway-E
Красным выделены корневой и промежуточный сертификаты «серого» центра сертификации.
Синим выделены корневой и промежуточный сертификаты «белого» центра сертификации Let's Encrypt.
5. Генерируем запрос на сертификат для Expressway-C.
Никаких SAN-имён для Expressway-C не требуется.
В поле Unified CM phone security profile names нужно указать Phone Security Profiles созданный в Unified CM, это требуется только для взаимодействия между Expressway-C и CUCM по TLS. В нашем сценарии это не понадобится.
6. Запрос скармливаем «серому» центру сертификации, получаем сертификат и загружаем его на Expressway-C.
7. Генерируем запрос на сертификат для Expressway-E. Точно также, как и для Expressway-C, только добавляем в SAN join.example.ru, example.ru или collab-edge.example.ru, если DNS запись типа А example.ru указывает на IP-адрес сайта организации. Также надо не забыть создать DNS запись типа А collab-edge.example.ru на внешнем DNS сервере, иначе запрос будет отклонён.
Иначе без example.ru или collab-edge.example.ru клиенты Cisco Jabber будут ругаться о том, что сертификат не доверенный.
8. Нажимаем Deploy Pending Cert.
9. В итоге, если всё сделано правильно, будет вот такая картина.
Однако, в версии 12.5.6 при работе кластера с этим делом BUG.
В описание бага также описано и решении и по его обходу, пофиксят в 12.5.7 версии.
UPD: Версии 12.5.7 и 12.5.8 отозваны по причине багов и косяков с безопасностью, обновите до 12.5.9.
UPD: Настройки шифрования изменились с версии 14.2, поэтому теперь предпочтение отдается сертификатам ECDSA. Поэтому при свежей установке Expressway проверка цепочки сертификатов будет завершаться неудачно и телефонные сервисы в приложении Cisco Jabber работать не будут. Решить проблему можно либо добавив все сертификаты ECDSA от всех нод CUCM в хранилище доверенных сертификатов Expressway, либо выписать сертификаты ECDSA на CUCM центрами сертификации c соответствующим шаблоном, которым доверяет Expressway, либо изменить список шифров, отдав предпочтение шифрам RSA.
Зона – это абстрактный набор чего угодно (доменов, ip-адресов, устройств, сервисов), к которым применим определенный набор правил. Зоны нужны для управления пропускной способностью, аутентификацией и маршрутизацией звонков, и это применяется сразу ко всему, что есть в зоне. Создавая Dial-plan'ы необходимо указать из какой зоны в какую передать звонок (а не в какой домен).
Существует несколько типов зон.
Итак создаём Neighbor зоны для CUCM и Cisco Meeting Server'a на Expressway-C.
Для каждого CUCM-сервера в кластере publisher'a и subscriber'a(ов) создаётся отдельная зона. Если создать одну зону и указать все сервера в полях address, то звонки будут проходить каждые 1/n раз, где n — количество серверов в кластере CUCM. Тоже самое и с зонами для CMS.
В нашем случае сервера всего два.
Первая зона:
Вторая зона:
Также требуется создать SIP Trunk Security Profile и Trunk c CUCM до Expressway.
SIP Trunk Security Profile
Обратите внимение, что мы здесь указываем порт 5065, иначе работать ничего не будет, по какой причине так сделано, мне пока узнать не удалось.
Trunk
Обратите внимание, что мы здесь указываем порт 5060, если мы укажем порт 5065 всё работать будет, но транк в статусе Full Services не будет, статус будет Unknown. Также требуется указать нужный CSS(это в зависимости от вашей конфигурации), созданный нами ранее SIP Trunk Security Profile и Standart SIP Profile For Cisco VCS в качестве SIP Profile.
Если сервер один и никакого кластера не подразумевается, то достаточно Zone Profile оставить в значении Default.
Если у вас кластер, то в полях address нужно указать FQDN каждого сервера, входящего в кластер и поставить параметр Meeting Server load balancing в состояние ON.
В моём случае никаких H.323 протоколов не используется, поэтому создаём именно UC Traversal зону, а не просто Traversal.
На Expressway-C в зоне UC Traversal настраивается клиентское подключение, т.к.
относительно нашего обходного для Firewall'a туннеля, который строится между Expressway-C и Expressway-E, Expressway-C выступает клиентом и устанавливает туннель из внутренней сети к Expressway-E, который находится в сети DMZ, чтобы сигнализация могла проходить через корпоративный Firewall в обоих направлениях. И поэтому мы должны указать логин и пароль, который мы создадим на Expressway-E, на котором настраивается серверная часть UC Traversal зоны.
В итоге на Expressway-C должна быть примерно такая картина.
Соседские зоны(а также правила для этих зон) CEtcp… создаются автоматически, если явно задать CUCM в Expressway-C(Configuration---Unified Communications---Unified CM servers)
Также в CUCM версии 12.5, автоматически появится Expressway.
Expressway-E обычно находится в демилитаризованной зоне и имеет интерфейс, к которому можно напрямую подключиться из Интернета (некоторых случаях этот адрес интерфейса находится за NAT'ом). Большинство политик Firewall'ов не разрешают подключения из DMZ во внутреннюю сеть. Однако большинство политик Firewall'ов позволяют подключаться из внутренней сети к сети DMZ и Интернету. Expressway-E настроен, как сервер обхода, где он может принимать соединения, инициированные от клиентов обхода firewall'a, таких как Expressway-C, которые находятся во внутренней сети. Это соединение затем используется для двунаправленной связи, позволяя отправлять сообщения с Expressway-E на Expressway-C.
Для работы обходного соединения на Expressway-E должен быть пользователь, которого позже будет использовать Expressway-C для аутентификации. Назовём его uctraversal.
Настраиваем UC Traversal Zone'у.
Зона DNS сначала выполняет различные поиски DNS SRV-записей, пытаясь найти место назначения для вызываемого домена. Для SIP он ищет _sips._tcp. домен и/или _sip.tcp. домен в зависимости от настроек безопасности и шифрования. Если какой-либо из этих поисков SRV-записи дает сбой, Expressway можно настроить так, чтобы он также выполнял стандартные запросы записи A, чтобы найти пункт назначения звонка. Эти поиски позволяют Expressway направлять звонки в пункты назначения, которые не определены явно. Можно просто зарегистрировать эти записи DNS SRV на публичном DNS-сервере, а затем автоматически получать вызовы от внешних клиентов и/или звонить им, если у них сделано тоже самое. Это часто называют открытой федерацией или Business-to-Business(B2B) звонками.
TURN расшифровывается как Traversal Using Relays around NAT. По сути, это устройство, которое находится в публичном доступе в Интернете и отправляет и получает мультимедиа. Для правильного функционирования он должен быть доступен, как внешним устройствам в Интернете, так и внутренним устройствам, таким как CMS, чтобы аудио и видео трафик мог поступать и выходить из организации. Сервер TURN в этом случае действует, как точка привязки для носителя, которому доверяет межсетевой экран.
К слову, CMS может быть развернут в качестве пограничного устройства и функционировать в качестве сервера TURN, но, поскольку Expressway-E также имеет возможности сервера TURN, то лучше настраивать его на Expressway, а не плодить лишние сервера CMS или настраивать лишний функционал, тем самым повысив нагрузку на CMS сервере… Независимо от того, какое устройство используется в качестве сервера TURN для привязки мультимедиа, сервер TURN должен быть настроен в базе данных CMS, чтобы Call Bridge'ы знали, куда отправлять мультимедиа, и, поскольку сервер TURN находится в публичном доступе Интернете, веб-клиент может знать куда отправлять свой трафик. Expressway-E, действующий в качестве сервера TURN, будет соединять трафик, полученный на его внутренних и внешних интерфейсах, так, чтобы пользователи могли устанавливать двустороннюю связь.
Для любого устройства для использования сервера TURN требуется аутентификация. Требуется настроить набор учетных данных аутентификации на Expressway-E, чтобы использовать для его для функционала TURN.
Создаём учетку «Traversal...»
Включаем TURN на Expressway-E.
TURN на Cisco Meeting Server
Если никакого кластера нет, то достаточно указать в Web-интерфейса CMS адреса TURN CMA и TURN CMS.
TURN CMS(serverAddress) — IP-адрес, с которого CMS должен ожидать получения трафика при подключении клиентов в конференцию.
TURN CMA(clientAddress) — IP-адрес, на который клиенты(как внутренние так и внешние) должны отправлять трафик для участия в конференции.
И TURN CMA(clientAddress) и TURN CMS(serverAddress) могут быть одним и тем же адресом, если Expressway-E имеет белый ip-адрес и ни за каким NAT'ом он не расположен. Если же Expressway-E работает за NAT'ом, таким образом TURN CMA — это белый ip-адрес в который NAT'ится Expressway. TURN CMS(serverAddress) — это ip-адрес во внутренний сети организации, который имеет Expressway-E. Для этой же цели и открывается порт 3478 между от Cisco Meeting Server'a в сторону Expressway-E.
Если же Expressway-E всё таки находится за NAT'ом, то в таком случае на Firewall'e требуется настроить так называемый NAT-Reflection. Его суть сводится к тому, что внутренние клиенты и/или устройства подключаясь в конференцию по TURN CMA(clientAddress) перенаправлялись на адрес Cisco Meeting Server'a и всё работало.
Также NAT-Reflection требуется для MRA, т.к. если Expressway-C инициирует связь с Expressway-E «стучась» в серый ip-адрес Expressway-E, то при звонке на/с джаббер(а), который находится вне корпоративной сети, на Expressway-C будет требоваться RMS лицензия, т.е. звонок будет восприниматься, как B2B. Чтобы этого избежать требуется на внутреннем DNS-сервере создать А-запись Expressway-E, которая указывает на его белый ip-адрес, а NAT-Reflection поможет перенаправить трафик в интерфейс Expressway-E на серый ip-адрес.
Если же дело обстоит с кластером, то на любом из серверов CMS-кластера нужно настроить TURN с помощью Postman'a, и эти настройки автоматически применятся на остальных серверах CMS-кластера.
Создаём TURN-сервера и указываем им следующие параметры:
Про первые два параметра я уже писал. Третий и четвертый это логин и пароль от учетки, которую мы создали на Expressway-E. Последний же type это тип TURN- сервера, в нашем случае это expressway, но может быть и CMS.
Если кластер, то создаются два(в моем случае) или более TURN-серверов, их число равно числу сервреров в кластере Expressway.
В status'e мы можем посмотреть доступен ли в итоге на TURN для CMS'a и прочее, см. ниже.
Чтобы Expressway-C корректно увидел наш кластер CMS нужно на внутреннем DNS сервере в зоне для внешнего домена(если у нас Dual-Domain сценарий) создать каталог join, в нем каталог _tls, и уже в нем три DNS записи типа SRV _cms-web с соответствующими приоритетами, которые соответственно указывают на DNS записи типа А cms01.internal-domain.ru, cms02.internal-domain.ru, cms03.internal-domain.ru.
Пишем join.[external]-example.com, чтобы Expressway «увидел» все сервера кластера CMS.
Далее нам требуется включить режим MRA(Mobile and Remote Access).
На Expressway-C
На Expressway-E
На Expressway-E(на всех если кластер) рекомендуется поменять порт по умолчанию с 443, на, например, 445. Если оставить его без изменений, то вместо подключения к CMS извне пользователи будут подключаться к веб-администратору Expressway-E.
Вообще чтобы всё это дело работало в Firewall'ах должны быть открыты порты. Собственно вот они.
Проверяем доступность web-портала снаружи, просто зайдя по нашему адресу join.example.com. Я допилил ещё и брэндинг, но об этом позже.
Маршрутизацию звонков можно организовать по разному.
Разница в том, кто будет выступать в качестве центрального узла маршрутизации звонков. Вообще всё это дело можно гибко настроить с помощью приоритетов на тех же CMS и Expressway. В нашем случае будет второй вариант. См. картинку ниже. Изображение взято из Deployment guide'a, всё что с внешней стороны Firewall'a, сейчас нас не интересует.
Входящие звонки
Исходящие звонки
В качестве SIP-proxy можно указать и CUCM(в качестве первого варианта), но для этого нужно и сам CUCM настроить соответсвующим образом… Транки, SIP Route Pattern'ы, Route List'ы и прочее.
Business to Business (B2B) звонки являются основной особенностью продукта Expressway. В2В позволяет пользователям осуществлять видеовызовы, отправлять и принимать вызовы от/к предприятий, внешних видеосервисов или клиентов через Интернет, при этом безопасным образом обходя корпоративные Firewall'ы.
В основе B2B звонков лежит возможность маршрутизации вызовов через Expressway. Хотя тоже самое можно сделать на основе домена, CUCM и большинстве других объектов управления SIP-вызовами, Expressway также имеет понятие зоны DNS. Таким образом с помощью этой зоны не нужно явно определять удаленный пункт назначения вызова. Вместо этого Expressway DNS, чтобы найти пункт назначения вызова за пределами сети организации. DNS зона у нас уже настроена.
Создаём правило поиска для входящих звонков на Expressway-E.
В моей организации требуется разрешить входящие звонки только в специально предназначенную конференцию, SIP-URI которой meeting@example.ru
Сделаем это с помощью регулярного выражения "meeting@example\.ru\.*"
Про параметры можно почитать в документации и/или подсказки в самом Expressway.
Если совсем по простому, то мы входящий SIP-звонок из DefaultZone в адресе назначения которого meeting@example.ru направляем в зону UC Traversal.
Создаём правило поиска для исходящих звонков на Expressway-E.
Сделаем это с помощью регулярного выражения "(?!.*@%localdomains%.*$).*"
Опять же, если совсем по простому, то мы входящий(именно входящий, потому что пришёл он со стороны Expressway-C, хотя для нас, как для абонентов он является исходящим) SIP-звонок из UC Traversal зоны, в адресе назначения которого что угодно, но не с локальным доменом(-ами) после @, направляем в зону DNS для успешного поиска(сопоставления значения после @ с его ip-адресом в сети Интернет) адреса назначения и успешного звонка.
Transforms
При Dual-Domain нужно преобразовать внешний домен во внутренний. Делаем это с помощью регулярного выражения "(.*)external.ru((:|;).*)?" и "1\@internal.ru"
Создаём правила поиска на Expressway-С
Регулярные выражения соответственно:
Transforms
Также необходимо добавить трансформаций для корректной работы маршрутизации звонков.
Итак проведём тестовые звонки. Позвоним в конференцию с Cisco RoomKit Mini изнутри организации и снаружи B2B-звонком с Cisco RoomKit Plus, при этом через web также в нее присоединимся.
Присоединямся через web в конференцию.
Звоним снаружи.
Звоним изнутри
В итоге конференция собралась.
К слову 1900@external.ru и 999@internal.ru зарегистрированны на своих CUCM.
Как это всё выглядело для Expressway и CMS.
Входящий звонок на Expressway-E
Детальный разбор того, что как проходил вызов через Expressway-E
Входящий звонок на Expressway-С
Детальный разбор того, что как проходил вызов через Expressway-C
Входящий звонок на CMS
Заранее прощу прощения за замазывание некоторых имён и IP-адресов, необходимость в этом есть потому, что я описываю реальную боевую настройку, которая сейчас работает, отсюда некоторые вопросы безопасности.
Источники:
В этом выпуске я покажу и объясню, как настроить Cisco Expressway сервера чтобы видеоконференцсвязь работала не только внутри, но и за пределами вашей организации.
Cisco Expressway обеспечивает безопасный межсетевой экран для передачи голоса и видео и поддерживает множество функций, таких как B2B вызовы и мобильный и удаленный доступ (MRA), а также возможности сервера TURN(Traversal Using Relay NAT). Таким образом, это то, что называется решением Single Edge и является предпочтительным пограничным решением Cisco для унифицированных коммуникаций и Cisco Meeting Server.
Лицензии
Серверы Cisco Expressway ставятся, как Core(Expressway-C) и Edge(Expressway-E). При установке с нуля они ещё не являются Expressway'ями как таковыми, они ещё пока VCS-серверы.
Для того чтобы наши свежеустановленные VCS-сервера стали Expressway'ями каждому нужно установить нужные лицензии.
На каждый сервер, независимо будет он Edge или Core требуется лицензия LIC-SW-EXP-K9 или проще говоря Release key.
Чтобы VCS-сервер стал Expressway'ем Core требуются лицензии:
- LIC-EXP-GW
- LIC-EXP-SERIES
Чтобы VCS-сервер стал Expressway'ем Edge требуются лицензии:
- LIC-EXP-GW
- LIC-EXP-SERIES
- LIC-EXP-E
- LIC-EXP-TURN
Опционально можно добавить следующие лицензии:
- LIC-EXP-MSFT-PMP
- LIC-EXP-RMS-PMP
- LIC-EXP-DSK
- LIC-EXP-ROOM
- LIC-EXP-AN
LIC-EXP-MSFT-PMP — Microsoft Interoperability Option (Для Expressway-C) нужна для взаимодействия со Skype for Business
LIC-EXP-DSK — Expressway Desktop Endpoint License (Для Expressway-C) нужна для регистрации на Expressway персональных устройств.
LIC-EXP-ROOM — Expressway ROOM License для регистрации на Expressway кодеков видеоконференцсвязи.
LIC-TP-ROOM — Есть ещё такая лицензия для CUCM, чтобы зарегистрировать кодек на CallManager'е, опционально в неё входит лицензия LIC-EXP-ROOM.
LIC-EXP-AN — Advanced Networking опция дополнительного сетевого интерфейса(Как для Expressway-C, так и для Expressway-Е)
LIC-EXP-RMS-PMP — Rich Media Session лицензии (Как для Expressway-C, так и для Expressway-Е)
Потребление лицензии Rich Media Session в зависимости от типа соединения:
- Соединения от/на Expressway зарегистрированным устройствам
- Соединения на/от Expressway Non-Registered Endpoints
- Соединения на/от через Traversal Zone
- Соединения на/от Cisco Cloud Service
- Соединения на/от UCM, Conductor, CMS, или Expressway через Neighbor Zone
В моём случае предполагается, что виртуальные машины уже установлены и сетевые интерфейсы на них настроены.
Немного забегая вперед скажу, что связку Expressway-С и Expressway-E можно разворачивать по нескольким сценариям.
Относительно доменов может быть два варианта:
Single domain
Это когда, как внутри, так и снаружи вашей сети один и тот же домен example.com.
Dual domain
Это когда внутри у вас домен example.local, а снаружи example.com.
Относительно топологии рекомендуется использовать два сетевых интерфейса по каждому в одну отдельную DMZ, но это достаточно редкий случай, мы рассмотрим два других варианта:
DMZ — что это?
1. DMZ с одним интерфейсом локальной сети Expressway-E.
В это варианте есть возможность задать белый ip-адрес, который вам выдал(или выдаст) провайдер. В таком варианте в дальнейшем не потребуется настройка NAT-Reflection на вашем firewall'е, которая в свою очередь нужна для нормальной работы Cisco Meeting Server'a за пределами сети.
2. DMZ с двумя интерфейсами локальной сети Expressway-E.
Для данного функционала должна быть активирована опция Advanced Networking в ключах лицензий.
Также в обоих случаях в зависимости от вашего сценария нужно указать за NAT'ом этот ip-адрес будет смотреть в Интернет или нет.
DNS
В зависимости от того, кластер вы разворачиваете или нет, Single или Dual-Domain на внешнем и внутреннем DNS серверах нужно завести следующие записи:
Single Domain
Dual Domain
Обратите внимание, что если у Вас Dual-Domain, то на внутреннем DNS сервере требуется создать зону с внешним доменом и уже в нём создать записи выделенные красным. Делается это для того, чтобы пользователи могли логиниться в своих Cisco Jabber приложениях с одинаковым логином, как снаружи так и внутри корпоративной сети(с внешним доменом, обычно логины совпадают с адресом электронной корпоративной почты) независимо от того где они находятся внутри или снаружи корпоративной сети.
Также требуется создать домены и указать какие сервисы должны подерживаться для этого домена.
Сервисы
SIP registrations and provisioning on Expressway — Указывает, является ли Expressway доверенной для этого SIP-домена. Expressway действует как SIP-регистратор и сервер присутствия для данного домена, а также принимает запросы на регистрацию для любых SIP-клиентов, пытающихся зарегистрироваться с алиасом, который включает этот домен.
SIP registrations and provisioning on Unified CM — Указывает действует ли Expressway в качестве шлюза для CUCM для обеспечения безопасного прохождения брандмауэра и поддержки регистрации конечных устройств на CUCM.
IM and Presence Service — Указывает действует ли Expressway в качестве шлюза для IMP и поддерживает сервис мессенджинга и присутствия.
XMPP federation — Указывает, что федеративные службы XMPP будут предоставляться для этого локального домена. Проще говоря участвует ли этот домен в федерации с какими-либо другими доменами.
Обратите внимание, что если требуются статические маршруты для федеративных внешних доменов, они настраиваются на Expressway-E.
SIP registrations and provisioning on Unified CM — Указывает действует ли Expressway в качестве шлюза для CUCM для обеспечения безопасного прохождения брандмауэра и поддержки регистрации конечных устройств на CUCM.
IM and Presence Service — Указывает действует ли Expressway в качестве шлюза для IMP и поддерживает сервис мессенджинга и присутствия.
XMPP federation — Указывает, что федеративные службы XMPP будут предоставляться для этого локального домена. Проще говоря участвует ли этот домен в федерации с какими-либо другими доменами.
Обратите внимание, что если требуются статические маршруты для федеративных внешних доменов, они настраиваются на Expressway-E.
На Expressway-C нужно указать оба домена, если используется сценарий Dual-Domain.
На Expressway-E, если используется сценарий Dual-Domain, нужно указать также все(в моем случае их два, а может быть и больше) домены которые требуются.
Сертификаты
Серверы Expressway работают друг с другом и с остальными посредством сертификатов. Поэтому корневые и промежуточные сертификаты центров сертификации от которых получены сертификаты теми серверами которые будут работать с Expressway должны быть указаны как доверенные.
В меню Maintenance->Security->Trust CA certificate загружаем эти самые корневые и промежуточные сертификаты.
В нашем случае для Expressway-C сертификат будет выдан своим(серым) центром сертификации, который равносилен самоподписанному, а для Expressway-E сертификат будет выдан от белого центра сертификации Let's encrypt.
Эти сертификаты бесплатные, но каждые три месяца их нужно продлевать, но у Expressway есть функционал автоматического продления, об этом ниже.
Относительно бесплатного белого сертификата Let's Encrypt.
1. Проходим по ссылкам промежуточного сертификата и корневого сертификата
2. Требуется преобразовать цепочку .p7b в корневой сертификат, который примет наш Expressway, для этого для Windows 10:
Нажимаем правой кнопкой мыши на файл и выбираем Open with > Crypto Shell Extensions
Нажимаем правой кнопкой мыши на «DST Root CA X3», выбираем All Tasks, Export и Сохраняем.
Для linux конвертируем p7b формат в формат pem командой:
openssl pkcs7 -inform der -in
dstrootcax3.p7c -print_certs -out dstrootcax3.pem.
3. Копируем содержимое промежуточного сертификата в блокнот и сохраняем, например, как lets-encrypt-x3-cross-signed.pem.txt.
Update: Промежуточный сертификат поменяли на вот этот.
По предыдущему будет вот такая ошибка:
CME deploy operation failed: The trust chain for the pending certificate is missing or invalid.
4. Загружаем оба сертификата в Trust CA на Expressway-E
Красным выделены корневой и промежуточный сертификаты «серого» центра сертификации.
Синим выделены корневой и промежуточный сертификаты «белого» центра сертификации Let's Encrypt.
5. Генерируем запрос на сертификат для Expressway-C.
Никаких SAN-имён для Expressway-C не требуется.
В поле Unified CM phone security profile names нужно указать Phone Security Profiles созданный в Unified CM, это требуется только для взаимодействия между Expressway-C и CUCM по TLS. В нашем сценарии это не понадобится.
6. Запрос скармливаем «серому» центру сертификации, получаем сертификат и загружаем его на Expressway-C.
7. Генерируем запрос на сертификат для Expressway-E. Точно также, как и для Expressway-C, только добавляем в SAN join.example.ru, example.ru или collab-edge.example.ru, если DNS запись типа А example.ru указывает на IP-адрес сайта организации. Также надо не забыть создать DNS запись типа А collab-edge.example.ru на внешнем DNS сервере, иначе запрос будет отклонён.
Иначе без example.ru или collab-edge.example.ru клиенты Cisco Jabber будут ругаться о том, что сертификат не доверенный.
8. Нажимаем Deploy Pending Cert.
9. В итоге, если всё сделано правильно, будет вот такая картина.
Однако, в версии 12.5.6 при работе кластера с этим делом BUG.
В описание бага также описано и решении и по его обходу, пофиксят в 12.5.7 версии.
UPD: Версии 12.5.7 и 12.5.8 отозваны по причине багов и косяков с безопасностью, обновите до 12.5.9.
UPD: Настройки шифрования изменились с версии 14.2, поэтому теперь предпочтение отдается сертификатам ECDSA. Поэтому при свежей установке Expressway проверка цепочки сертификатов будет завершаться неудачно и телефонные сервисы в приложении Cisco Jabber работать не будут. Решить проблему можно либо добавив все сертификаты ECDSA от всех нод CUCM в хранилище доверенных сертификатов Expressway, либо выписать сертификаты ECDSA на CUCM центрами сертификации c соответствующим шаблоном, которым доверяет Expressway, либо изменить список шифров, отдав предпочтение шифрам RSA.
Зоны
Зона – это абстрактный набор чего угодно (доменов, ip-адресов, устройств, сервисов), к которым применим определенный набор правил. Зоны нужны для управления пропускной способностью, аутентификацией и маршрутизацией звонков, и это применяется сразу ко всему, что есть в зоне. Создавая Dial-plan'ы необходимо указать из какой зоны в какую передать звонок (а не в какой домен).
Существует несколько типов зон.
- Neighbor — нужна, например, для связи с CMS, CUCM или другим Expressway-C.
- Localzone — зона в которую входят устройства зарегистрированные на Expressway'ях.
- ENUM — для E.164-запросов.
- DNS — для DNS-запросов.
- Webex — нужна для сценариев, в которых вызовы, инициированные в корпоративной сети, через сеть компании поступают в Интернет, а затем в облако. Аналогично через Интернет происходит маршрутизация вызовов, инициированных в Webex во время совещания, которые в дальнейшем поступают в локальную систему маршрутизации.
- Traversal(Client, Server) — нужна для маршрутизации вызовов между Expressway-C и Expressway-E для обхода Firewall'a(отсюда и слово traversal(обходная)).
- UC Traversal — нужна вывода во внешний мир Jabber'a со всем его функционалом.
- Default — то, что не попало ни в одну зону, попадает в Default-зону, и работает согласно правилам Default-зоны, которую, вообще говоря, можно не заполнять правилами, и всё будет просто отклоняться.
Итак создаём Neighbor зоны для CUCM и Cisco Meeting Server'a на Expressway-C.
Зона для CUCM
Для каждого CUCM-сервера в кластере publisher'a и subscriber'a(ов) создаётся отдельная зона. Если создать одну зону и указать все сервера в полях address, то звонки будут проходить каждые 1/n раз, где n — количество серверов в кластере CUCM. Тоже самое и с зонами для CMS.
В нашем случае сервера всего два.
Первая зона:
Вторая зона:
Также требуется создать SIP Trunk Security Profile и Trunk c CUCM до Expressway.
SIP Trunk Security Profile
Обратите внимение, что мы здесь указываем порт 5065, иначе работать ничего не будет, по какой причине так сделано, мне пока узнать не удалось.
Trunk
Обратите внимание, что мы здесь указываем порт 5060, если мы укажем порт 5065 всё работать будет, но транк в статусе Full Services не будет, статус будет Unknown. Также требуется указать нужный CSS(это в зависимости от вашей конфигурации), созданный нами ранее SIP Trunk Security Profile и Standart SIP Profile For Cisco VCS в качестве SIP Profile.
Зона для CMS
Если сервер один и никакого кластера не подразумевается, то достаточно Zone Profile оставить в значении Default.
Если у вас кластер, то в полях address нужно указать FQDN каждого сервера, входящего в кластер и поставить параметр Meeting Server load balancing в состояние ON.
Зона UC Traversal на Expressway-C
В моём случае никаких H.323 протоколов не используется, поэтому создаём именно UC Traversal зону, а не просто Traversal.
На Expressway-C в зоне UC Traversal настраивается клиентское подключение, т.к.
относительно нашего обходного для Firewall'a туннеля, который строится между Expressway-C и Expressway-E, Expressway-C выступает клиентом и устанавливает туннель из внутренней сети к Expressway-E, который находится в сети DMZ, чтобы сигнализация могла проходить через корпоративный Firewall в обоих направлениях. И поэтому мы должны указать логин и пароль, который мы создадим на Expressway-E, на котором настраивается серверная часть UC Traversal зоны.
В итоге на Expressway-C должна быть примерно такая картина.
Соседские зоны(а также правила для этих зон) CEtcp… создаются автоматически, если явно задать CUCM в Expressway-C(Configuration---Unified Communications---Unified CM servers)
Также в CUCM версии 12.5, автоматически появится Expressway.
Зона UC Traversal на Expressway-E
Expressway-E обычно находится в демилитаризованной зоне и имеет интерфейс, к которому можно напрямую подключиться из Интернета (некоторых случаях этот адрес интерфейса находится за NAT'ом). Большинство политик Firewall'ов не разрешают подключения из DMZ во внутреннюю сеть. Однако большинство политик Firewall'ов позволяют подключаться из внутренней сети к сети DMZ и Интернету. Expressway-E настроен, как сервер обхода, где он может принимать соединения, инициированные от клиентов обхода firewall'a, таких как Expressway-C, которые находятся во внутренней сети. Это соединение затем используется для двунаправленной связи, позволяя отправлять сообщения с Expressway-E на Expressway-C.
Для работы обходного соединения на Expressway-E должен быть пользователь, которого позже будет использовать Expressway-C для аутентификации. Назовём его uctraversal.
Настраиваем UC Traversal Zone'у.
DNS Зона
Зона DNS сначала выполняет различные поиски DNS SRV-записей, пытаясь найти место назначения для вызываемого домена. Для SIP он ищет _sips._tcp. домен и/или _sip.tcp. домен в зависимости от настроек безопасности и шифрования. Если какой-либо из этих поисков SRV-записи дает сбой, Expressway можно настроить так, чтобы он также выполнял стандартные запросы записи A, чтобы найти пункт назначения звонка. Эти поиски позволяют Expressway направлять звонки в пункты назначения, которые не определены явно. Можно просто зарегистрировать эти записи DNS SRV на публичном DNS-сервере, а затем автоматически получать вызовы от внешних клиентов и/или звонить им, если у них сделано тоже самое. Это часто называют открытой федерацией или Business-to-Business(B2B) звонками.
TURN
TURN расшифровывается как Traversal Using Relays around NAT. По сути, это устройство, которое находится в публичном доступе в Интернете и отправляет и получает мультимедиа. Для правильного функционирования он должен быть доступен, как внешним устройствам в Интернете, так и внутренним устройствам, таким как CMS, чтобы аудио и видео трафик мог поступать и выходить из организации. Сервер TURN в этом случае действует, как точка привязки для носителя, которому доверяет межсетевой экран.
К слову, CMS может быть развернут в качестве пограничного устройства и функционировать в качестве сервера TURN, но, поскольку Expressway-E также имеет возможности сервера TURN, то лучше настраивать его на Expressway, а не плодить лишние сервера CMS или настраивать лишний функционал, тем самым повысив нагрузку на CMS сервере… Независимо от того, какое устройство используется в качестве сервера TURN для привязки мультимедиа, сервер TURN должен быть настроен в базе данных CMS, чтобы Call Bridge'ы знали, куда отправлять мультимедиа, и, поскольку сервер TURN находится в публичном доступе Интернете, веб-клиент может знать куда отправлять свой трафик. Expressway-E, действующий в качестве сервера TURN, будет соединять трафик, полученный на его внутренних и внешних интерфейсах, так, чтобы пользователи могли устанавливать двустороннюю связь.
Для любого устройства для использования сервера TURN требуется аутентификация. Требуется настроить набор учетных данных аутентификации на Expressway-E, чтобы использовать для его для функционала TURN.
Создаём учетку «Traversal...»
Включаем TURN на Expressway-E.
TURN на Cisco Meeting Server
Если никакого кластера нет, то достаточно указать в Web-интерфейса CMS адреса TURN CMA и TURN CMS.
Порт 5222 или порт 5223
В поле ServerAddress вообще лучше указать защищенный 5223 порт, однако, в данном случае я указал порт 5222 из-за того, что к CMS я прикрутил wild-сертификат, а в нём, как известно в CN и SAN указываются только домен и "*.домен".
поэтому фактический адрес web-portal'a CMS не совпадает с CN и SAN в сертификате, поэтому 5223 порт указать невозможно, а возможно 5222.
поэтому фактический адрес web-portal'a CMS не совпадает с CN и SAN в сертификате, поэтому 5223 порт указать невозможно, а возможно 5222.
TURN CMS(serverAddress) — IP-адрес, с которого CMS должен ожидать получения трафика при подключении клиентов в конференцию.
TURN CMA(clientAddress) — IP-адрес, на который клиенты(как внутренние так и внешние) должны отправлять трафик для участия в конференции.
И TURN CMA(clientAddress) и TURN CMS(serverAddress) могут быть одним и тем же адресом, если Expressway-E имеет белый ip-адрес и ни за каким NAT'ом он не расположен. Если же Expressway-E работает за NAT'ом, таким образом TURN CMA — это белый ip-адрес в который NAT'ится Expressway. TURN CMS(serverAddress) — это ip-адрес во внутренний сети организации, который имеет Expressway-E. Для этой же цели и открывается порт 3478 между от Cisco Meeting Server'a в сторону Expressway-E.
Если же Expressway-E всё таки находится за NAT'ом, то в таком случае на Firewall'e требуется настроить так называемый NAT-Reflection. Его суть сводится к тому, что внутренние клиенты и/или устройства подключаясь в конференцию по TURN CMA(clientAddress) перенаправлялись на адрес Cisco Meeting Server'a и всё работало.
Также NAT-Reflection требуется для MRA, т.к. если Expressway-C инициирует связь с Expressway-E «стучась» в серый ip-адрес Expressway-E, то при звонке на/с джаббер(а), который находится вне корпоративной сети, на Expressway-C будет требоваться RMS лицензия, т.е. звонок будет восприниматься, как B2B. Чтобы этого избежать требуется на внутреннем DNS-сервере создать А-запись Expressway-E, которая указывает на его белый ip-адрес, а NAT-Reflection поможет перенаправить трафик в интерфейс Expressway-E на серый ip-адрес.
Схема работы при работе через NAT
Если же дело обстоит с кластером, то на любом из серверов CMS-кластера нужно настроить TURN с помощью Postman'a, и эти настройки автоматически применятся на остальных серверах CMS-кластера.
Создаём TURN-сервера и указываем им следующие параметры:
- serverAddress
- clientAddress
- username
- password
- type
Про первые два параметра я уже писал. Третий и четвертый это логин и пароль от учетки, которую мы создали на Expressway-E. Последний же type это тип TURN- сервера, в нашем случае это expressway, но может быть и CMS.
Если кластер, то создаются два(в моем случае) или более TURN-серверов, их число равно числу сервреров в кластере Expressway.
В status'e мы можем посмотреть доступен ли в итоге на TURN для CMS'a и прочее, см. ниже.
Указываем CMS
Чтобы Expressway-C корректно увидел наш кластер CMS нужно на внутреннем DNS сервере в зоне для внешнего домена(если у нас Dual-Domain сценарий) создать каталог join, в нем каталог _tls, и уже в нем три DNS записи типа SRV _cms-web с соответствующими приоритетами, которые соответственно указывают на DNS записи типа А cms01.internal-domain.ru, cms02.internal-domain.ru, cms03.internal-domain.ru.
Пишем join.[external]-example.com, чтобы Expressway «увидел» все сервера кластера CMS.
Далее нам требуется включить режим MRA(Mobile and Remote Access).
Включаем MRA
На Expressway-C
На Expressway-E
На Expressway-E(на всех если кластер) рекомендуется поменять порт по умолчанию с 443, на, например, 445. Если оставить его без изменений, то вместо подключения к CMS извне пользователи будут подключаться к веб-администратору Expressway-E.
Вообще чтобы всё это дело работало в Firewall'ах должны быть открыты порты. Собственно вот они.
Проверяем доступность web-портала снаружи, просто зайдя по нашему адресу join.example.com. Я допилил ещё и брэндинг, но об этом позже.
Маршрутизацию звонков можно организовать по разному.
- Маршрутизировать звонки на Cisco UCM.
- Маршрутизировать звонки на Cisco Expressway-C. (Предпочтительнее).
Разница в том, кто будет выступать в качестве центрального узла маршрутизации звонков. Вообще всё это дело можно гибко настроить с помощью приоритетов на тех же CMS и Expressway. В нашем случае будет второй вариант. См. картинку ниже. Изображение взято из Deployment guide'a, всё что с внешней стороны Firewall'a, сейчас нас не интересует.
Маршрутизация на CMS
Входящие звонки
Исходящие звонки
В качестве SIP-proxy можно указать и CUCM(в качестве первого варианта), но для этого нужно и сам CUCM настроить соответсвующим образом… Транки, SIP Route Pattern'ы, Route List'ы и прочее.
Business to Business звонки
Business to Business (B2B) звонки являются основной особенностью продукта Expressway. В2В позволяет пользователям осуществлять видеовызовы, отправлять и принимать вызовы от/к предприятий, внешних видеосервисов или клиентов через Интернет, при этом безопасным образом обходя корпоративные Firewall'ы.
В основе B2B звонков лежит возможность маршрутизации вызовов через Expressway. Хотя тоже самое можно сделать на основе домена, CUCM и большинстве других объектов управления SIP-вызовами, Expressway также имеет понятие зоны DNS. Таким образом с помощью этой зоны не нужно явно определять удаленный пункт назначения вызова. Вместо этого Expressway DNS, чтобы найти пункт назначения вызова за пределами сети организации. DNS зона у нас уже настроена.
Создаём правило поиска для входящих звонков на Expressway-E.
В моей организации требуется разрешить входящие звонки только в специально предназначенную конференцию, SIP-URI которой meeting@example.ru
Сделаем это с помощью регулярного выражения "meeting@example\.ru\.*"
Про параметры можно почитать в документации и/или подсказки в самом Expressway.
Если совсем по простому, то мы входящий SIP-звонок из DefaultZone в адресе назначения которого meeting@example.ru направляем в зону UC Traversal.
Создаём правило поиска для исходящих звонков на Expressway-E.
Сделаем это с помощью регулярного выражения "(?!.*@%localdomains%.*$).*"
Опять же, если совсем по простому, то мы входящий(именно входящий, потому что пришёл он со стороны Expressway-C, хотя для нас, как для абонентов он является исходящим) SIP-звонок из UC Traversal зоны, в адресе назначения которого что угодно, но не с локальным доменом(-ами) после @, направляем в зону DNS для успешного поиска(сопоставления значения после @ с его ip-адресом в сети Интернет) адреса назначения и успешного звонка.
Transforms
При Dual-Domain нужно преобразовать внешний домен во внутренний. Делаем это с помощью регулярного выражения "(.*)external.ru((:|;).*)?" и "1\@internal.ru"
Создаём правила поиска на Expressway-С
Регулярные выражения соответственно:
- .*@example.ru
- .*@example.ru
- .*@example.ru
- .*@(cucm-01\.|cucm-02\.)?example\.ru\.*
- .*@(cucm-01\.|cucm-02\.)?example\.ru\.*
- (?!.*@(cucm-01\.|cucm-02\.)?example\.ru\.*
Transforms
Также необходимо добавить трансформаций для корректной работы маршрутизации звонков.
- Отрезаем ":5060" порт URI звонящего.
- Преобразуем алиас назначения к виду URI.
- Заменяем IP-адрес на доменное имя при звонках с CUCM-Publisher'a.
- Заменяем IP-адрес на доменное имя при звонках с CUCM-Subscriber'a.
Итак проведём тестовые звонки. Позвоним в конференцию с Cisco RoomKit Mini изнутри организации и снаружи B2B-звонком с Cisco RoomKit Plus, при этом через web также в нее присоединимся.
Присоединямся через web в конференцию.
Звоним снаружи.
Звоним изнутри
В итоге конференция собралась.
К слову 1900@external.ru и 999@internal.ru зарегистрированны на своих CUCM.
Как это всё выглядело для Expressway и CMS.
Входящий звонок на Expressway-E
Детальный разбор того, что как проходил вызов через Expressway-E
Входящий звонок на Expressway-С
Детальный разбор того, что как проходил вызов через Expressway-C
Входящий звонок на CMS
Заранее прощу прощения за замазывание некоторых имён и IP-адресов, необходимость в этом есть потому, что я описываю реальную боевую настройку, которая сейчас работает, отсюда некоторые вопросы безопасности.
Источники:
- Cisco-Expressway-Basic-Configuration-Deployment-Guide-X12-5-4
- Cisco-Expressway-Cluster-Creation-and-Maintenance-Deployment-Guide-X12-5
- Cisco-Expressway-IP-Port-Usage-for-Firewall-Traversal-Deployment-Guide-X12-5
- Cisco-Expressway_MRA-deployment-guide
- Cisco-Meeting-Server-Deployment-Planning-and-Preparation-with-Expressway-Guide
- Cisco-Meeting-Server-2-4-and-later-Deployments-with-CUCM
