Благодарим вас за обратную связь.
Поддержка прокси-серверов для гибридной защиты данных и видеосетки
Отправить обратную связь?В этом разделе описывается функция поддержки прокси-серверов для гибридной защиты данных. Он призван дополнить руководство по развертыванию Cisco Webex гибридной защиты данных, доступное по адресу https://www.cisco.com/go/hybrid-data-security. В новом развертывании вы настраиваете настройку прокси-сервера на каждом узле после загрузки и монтирования ISO конфигурации HDS на узле, а также перед регистрацией узла в облакеCisco Webex.
Hybrid Data Security поддерживает явную и прозрачную проверку и неинспектирование прокси-серверов. Эти прокси-серверы можно привязать к своему развертыванию, чтобы обеспечить защиту и мониторинг корпоративного трафика в облако. Вы можете использовать интерфейс администратора платформы на узлах для управления сертификатами и проверки общего состояния подключения после настройки прокси-сервера на узлах.
Узлы Hybrid Data Security поддерживают следующие варианты прокси-серверов:
-
Без прокси-сервера — по умолчанию, если вы не используете настройку узла HDS, конфигурацию Trust Store и Proxy для интеграции прокси-сервера. Обновление сертификата не требуется.
-
Прозрачный прокси-сервер, не подвергающийся проверке. Узлы не настроены на использование определенного адреса прокси-сервера и не должны требовать каких-либо изменений для работы с прокси-сервером, не проверяющим проверку. Обновление сертификата не требуется.
-
Прозрачное туннелирование или проверка прокси-сервера — узлы не настроены на использование определенного адреса прокси-сервера. Никаких изменений в конфигурации HTTP или HTTPS на узлах не требуется. Однако узлам необходим корневой сертификат, чтобы они могли доверять прокси-серверу. Инспекционные прокси-серверы обычно используются ИТ-отделом для обеспечения соблюдения правил, в соответствии с которыми веб-сайты можно посещать, а какие типы контента запрещены. Этот тип прокси-сервера расшифровывает весь ваш трафик (даже HTTPS).
-
Явный прокси-сервер. Используя явный прокси-сервер, вы указываете узлам HDS, какой прокси-сервер и схему аутентификации использовать. Чтобы настроить явный прокси-сервер, необходимо ввести следующую информацию на каждом узле:
-
IP/FQDN прокси-сервера — адрес, по которому можно связаться с прокси-компьютером.
-
Порт прокси-сервера — номер порта, который прокси-сервер использует для прослушивания прокси-трафика.
-
Протокол прокси-сервера. В зависимости от того, что поддерживает ваш прокси-сервер, выберите один из следующих протоколов:
-
HTTP — просматривает и контролирует все запросы, отправляемые клиентом.
-
HTTPS — предоставляет канал к серверу. Клиент получает и проверяет сертификат сервера.
-
-
Тип аутентификации — выберите один из следующих типов аутентификации:
-
Нет — дополнительная аутентификация не требуется.
Доступно, если в качестве протокола прокси-сервера вы выберете HTTP или HTTPS.
-
Базовый — используется агентом пользователя HTTP для указания имени пользователя и пароля при запросе. Использует кодировку Base64.
Доступно, если в качестве протокола прокси-сервера вы выберете HTTP или HTTPS.
Требуется ввести имя пользователя и пароль на каждом узле.
-
Дайджест — используется для подтверждения учетной записи перед отправкой конфиденциальной информации. Применяет хеш-функцию к имени пользователя и паролю перед отправкой по сети.
Доступно только в том случае, если в качестве протокола прокси-сервера выбран HTTPS.
Требуется ввести имя пользователя и пароль на каждом узле.
-
-
Пример гибридных узлов защиты данных и прокси-сервера
На этой диаграмме показан пример соединения между Hybrid Data Security, сетью и прокси-сервером. Для использования опций прозрачной проверки и эксплицитной проверки по протоколу HTTPS на прокси-сервере и узлах Hybrid Data Security должен быть установлен один и тот же корневой сертификат.
Режим разрешения заблокированных внешних DNS (явные конфигурации прокси-сервера)
Когда вы регистрируете узел или проверяете конфигурацию прокси-сервера узла, процесс проверяет поиск в DNS и подключение к облакуCisco Webex. В развертываниях с явными конфигурациями прокси-серверов, которые не допускают внешнего разрешения DNS для внутренних клиентов, если узел не может запрашивать DNS-серверы, он автоматически переходит в режим разрешения заблокированных внешних DNS. В этом режиме можно продолжить регистрацию узлов и другие тесты подключения к прокси-серверу.
-
Мы официально поддерживаем следующие прокси-решения, которые можно интегрировать с вашими узлами Hybrid Data Security.
-
Прозрачный прокси-сервер — устройство веб-безопасности Cisco (WSA).
-
Явный прокси-сервер — Squid.
Прокси-серверы Squid, проверяющие HTTPS-трафик, могут мешать установлению соединений через websocket (wss:)). Чтобы обойти эту проблему, см. раздел Настройка прокси-серверов Squid для гибридной защиты данных.
-
-
Мы поддерживаем следующие комбинации типов аутентификации для явных прокси:
-
Нет аутентификации по протоколам HTTP или HTTPS
-
Базовая аутентификация с помощью HTTP или HTTPS
-
Дайджест-аутентификация только с использованием HTTPS
-
-
Чтобы использовать прокси-сервер с прозрачной проверкой или прокси-сервер с явным использованием HTTPS, у вас должна быть копия корневого сертификата прокси-сервера. В инструкциях по развертыванию, приведенных в этом руководстве, описано, как загрузить копию в доверительные хранилища узлов Hybrid Data Security.
-
Сеть, в которой расположены узлы HDS, должна быть настроена на принудительную маршрутизацию исходящего TCP-трафика через порт 443 через прокси-сервер.
-
Прокси-серверы, проверяющие веб-трафик, могут препятствовать подключению к веб-сокетам. В случае возникновения этой проблемы проблема
ciscospark.comбудет решена путем обхода (а не проверки) входящегоwbx2.comтрафика.
Если в сетевой среде требуется прокси-сервер, используйте эту процедуру, чтобы указать тип прокси-сервера, который вы хотите интегрировать с Hybrid Data Security. Если вы выберете прозрачный прокси-сервер для проверки или прокси-сервер с явным использованием HTTPS, вы можете использовать интерфейс узла для загрузки и установки корневого сертификата. Вы также можете проверить подключение к прокси-серверу через интерфейс и устранить возможные проблемы.
Прежде чем начать
-
Обзор поддерживаемых опций прокси-сервера см. в разделе Поддержка прокси-серверов.
| 1 |
Введите URL-адрес настройки узла HDS |
| 2 |
Перейдите в раздел Trust Store и Proxy и выберите один из вариантов:
Выполните следующие шаги для создания прокси-сервера с прозрачной проверкой, явного прокси-сервера HTTP с базовой аутентификацией или прокси-сервера с явным HTTPS. |
| 3 |
Нажмите кнопку «Загрузить корневой сертификат» или «Сертификат конечного объекта», а затем выберите корневой сертификат для прокси-сервера. Сертификат загружен, но еще не установлен, так как для установки сертификата необходимо перезагрузить узел. Нажмите на шевронную стрелку рядом с именем эмитента сертификата, чтобы получить дополнительные сведения, или нажмите кнопку Удалить, если вы допустили ошибку и хотите повторно загрузить файл. |
| 4 |
Нажмите «Проверить подключение к прокси-серверу», чтобы проверить сетевое подключение между узлом и прокси-сервером. Если проверка соединения не удалась, вы увидите сообщение об ошибке, в котором указаны причина и способы устранения проблемы. Если вы видите сообщение о том, что внешнее разрешение DNS не было успешным, значит, узлу не удалось связаться с DNS-сервером. Это условие ожидается во многих явных конфигурациях прокси-сервера. Можно продолжить настройку, и узел перейдет в режим разрешения заблокированных внешних DNS. Если вы считаете, что это ошибка, выполните следующие действия, а затем см. раздел Отключение режима разрешения заблокированных внешних DNS. |
| 5 |
После завершения проверки соединения, если прокси-сервер явно настроен только на https, включите переключатель в положение Маршрутизация всех HTTPS-запросов к порту 443/444 с этого узла через явный прокси-сервер. Для вступления этой настройки в силу требуется 15 секунд. |
| 6 |
Нажмите кнопку «Установить все сертификаты в хранилище доверия» (отображается как прокси-сервер с явным доступом по протоколу HTTPS или прокси-сервер с прозрачной проверкой) или «Перезагрузить» (отображается для прокси-сервера с явным именем HTTP), прочтите окно запроса и нажмите кнопку «Установить», если вы готовы. Узел перезагрузится через несколько минут. |
| 7 |
После перезагрузки узла при необходимости снова войдите в систему, а затем откройте страницу «Обзор», чтобы проверить все проверки подключения и убедиться, что все они отмечены зеленым цветом. Проверка соединения с прокси-сервером проверяет только субдомен webex.com. При возникновении проблем с подключением чаще всего некоторые облачные домены, перечисленные в инструкциях по установке, блокируются на прокси-сервере. |
Когда вы регистрируете узел или проверяете конфигурацию прокси-сервера узла, процесс проверяет поиск в DNS и подключение к облакуCisco Webex. Если DNS-сервер узла не может разрешать общедоступные DNS-имена, узел автоматически переходит в режим разрешения заблокированных внешних DNS-адресов.
Если ваши узлы могут разрешать общедоступные DNS-имена через внутренние DNS-серверы, вы можете отключить этот режим, повторно запустив тест прокси-соединения на каждом узле.
Прежде чем начать
| 1 |
В веб-браузере откройте интерфейс узла Hybrid Data Security (IP-адрес или настройка, например, https://192.0.2.0/setup), введите учетные данные администратора, настроенные для узла, а затем нажмите «Войти». |
| 2 |
Перейдите в раздел Обзор (страница по умолчанию). 
Если этот параметр включен, для параметра «Разрешение заблокированных внешних DNS» установлено значение «Да». |
| 3 |
Перейдите на страницу Trust Store и Proxy. |
| 4 |
Нажмите «Проверить прокси-соединение». Если вы видите сообщение о том, что внешнее разрешение DNS не было успешным, значит, узел не смог связаться с DNS-сервером и останется в этом режиме. В противном случае после перезагрузки узла и возврата на страницу «Обзор» для параметра «Разрешение заблокированных внешних DNS» следует задать значение «Нет». |
Что делать дальше
В этом разделе описывается функция поддержки прокси-сервера для Webex Video Mesh. Он призван дополнить руководство по развертыванию Cisco Webex Video Mesh, доступное по адресу https://www.cisco.com/go/video-mesh. В новом развертывании настройка прокси-сервера на каждом узле выполняется после развертывания программного обеспечения Video Mesh в среде виртуальных машин и до регистрации узла в Cisco Webex облаке.
Video Mesh поддерживает явные и прозрачные инспектирующие и неинспектирующие прокси-серверы. Эти прокси можно привязать к развертыванию Video Mesh, чтобы обеспечить защиту и мониторинг корпоративного трафика в облако. Эта функция отправляет на прокси-сервер трафик сигналов и управления на основе HTTPS. Для прозрачных прокси-серверов сетевые запросы от узлов Video Mesh перенаправляются на определенный прокси-сервер в соответствии с правилами маршрутизации корпоративной сети. После внедрения прокси-сервера на узлах можно использовать интерфейс администратора Video Mesh для управления сертификатами и общим состоянием подключения.
Мультимедийные файлы не передаются через прокси-сервер. Все равно необходимо открыть необходимые порты, чтобы медиапотоки могли напрямую поступать в облако. См. раздел Порты и протоколы для управления.
Video Mesh поддерживает следующие типы прокси-серверов:
-
Явный прокси-сервер (проверяющий или не проверяющий). При использовании явного прокси-сервера вы указываете клиенту (узлам Video Mesh), какой прокси-сервер использовать. Эта опция поддерживает один из следующих типов аутентификации:
-
Нет — дополнительная аутентификация не требуется. (Для явного прокси-сервера HTTP или HTTPS.)
-
Базовый — используется пользовательским агентом HTTP для указания имени пользователя и пароля при запросе и использует кодировку Base64. (Для явного прокси-сервера HTTP или HTTPS.)
-
Дайджест — используется для подтверждения личности учетной записи перед отправкой конфиденциальной информации и применяет хеш-функцию к имени пользователя и паролю перед отправкой по сети. (Для явного прокси-сервера HTTPS.)
-
Как и в случае с NTLM, NTLM используется для подтверждения личности учетной записи перед отправкой конфиденциальной информации. Использует учетные данные Windows вместо имени пользователя и пароля. Эта схема аутентификации требует нескольких обменов. (Для явного прокси-сервера HTTP.)
-
-
Прозрачный прокси-сервер (без проверки) — узлы Video Mesh не настроены на использование определенного адреса прокси-сервера и не должны требовать каких-либо изменений для работы с прокси-сервером, не проводящим проверку.
-
Прозрачный прокси-сервер (проверка) — узлы Video Mesh не настроены на использование определенного адреса прокси-сервера. В Video Mesh нет необходимости изменять конфигурацию http (s), однако узлам Video Mesh необходим корневой сертификат, чтобы доверять прокси-серверу. Инспекционные прокси-серверы обычно используются ИТ-отделом для обеспечения соблюдения правил, определяющих, какие веб-сайты можно посещать и какие типы контента запрещены. Этот тип прокси-сервера расшифровывает весь ваш трафик (даже https).
-
Мы официально поддерживаем следующие прокси-решения, которые можно интегрировать с вашими узлами Video Mesh.
-
Устройство веб-безопасности Cisco (WSA) для прозрачного прокси-сервера
-
Squid для явного прокси-сервера
-
-
Чтобы использовать прокси-сервер с явным доступом или прокси-сервер с прозрачной проверкой, который проверяет (расшифровывает трафик), у вас должна быть копия корневого сертификата прокси-сервера, которую необходимо загрузить в доверенное хранилище узлов Video Mesh в веб-интерфейсе.
-
Мы поддерживаем следующие явные комбинации типов прокси-сервера и аутентификации:
-
Нет аутентификации с помощью http и https
-
Базовая аутентификация с использованием http и https
-
Дайджест-аутентификация только с использованием https
-
Аутентификация NTLM только с использованием http
-
-
Для прозрачных прокси-серверов необходимо использовать маршрутизатор/коммутатор, чтобы принудительно передавать трафик HTTPS/443 на прокси-сервер. Вы также можете заставить Web Socket перейти на прокси-сервер. (Веб-сокет использует протокол https.)
Video Mesh требует подключения веб-сокетов к облачным сервисам для правильной работы узлов. При явной проверке и прозрачной проверке прокси-серверов для правильного соединения с веб-сокетами требуются HTTP-заголовки. Если они будут изменены, соединение с веб-сокетом прервется.
При сбое подключения к веб-сокету на порту 443 (при включенном прокси-сервере для прозрачной проверки) в Control Hub после регистрации появляется предупреждение: «Вызовы по протоколу SIP Webex Video Mesh работают неправильно». Тот же сигнал тревоги может возникать и по другим причинам, если прокси-сервер не включен. Когда заголовки веб-сокетов заблокированы на порту 443, медиафайлы не передаются между приложениями и SIP-клиентами.
Если медиаданные не поступают, это часто происходит из-за сбоя HTTPS-трафика с узла через порт 443:
-
Трафик порта 443 разрешен прокси-сервером, но он является проверяющим прокси-сервером и нарушает работу веб-сокета.
Чтобы устранить эти проблемы, вам, возможно, придется «обойти» или «соединить» (отключить проверку) порт 443 на следующие адреса: *.wbx2.com и *.ciscospark.com.
-
Используйте эту процедуру, чтобы указать тип прокси-сервера, который вы хотите интегрировать с сеткой видео. Если вы выберете прокси-сервер с прозрачной проверкой или прокси-сервер с явным доступом, вы можете использовать интерфейс узла для загрузки и установки корневого сертификата, проверки подключения к прокси-серверу и устранения возможных проблем.
Прежде чем начать
-
Обзор поддерживаемых вариантов прокси-сервера см. в разделе Поддержка прокси-серверов для Video Mesh.
| 1 |
Введите URL-адрес настройки Video Mesh | ||||||||||
| 2 |
Перейдите в раздел Trust Store и Proxy и выберите один из вариантов:
Выполните следующие шаги для прозрачной проверки или создания явного прокси-сервера. | ||||||||||
| 3 |
Нажмите «Загрузить корневой сертификат» или «Сертификат конечного объекта», а затем найдите и выберите корневой сертификат для прокси-сервера, осуществляющего явную или прозрачную проверку. Сертификат загружен, но еще не установлен, так как для установки сертификата необходимо перезагрузить узел. Нажмите стрелку рядом с именем эмитента сертификата, чтобы получить дополнительные сведения, или нажмите Удалить, если вы допустили ошибку и хотите повторно загрузить файл. | ||||||||||
| 4 |
Для прозрачной проверки или явной проверки прокси-серверов нажмите «Проверить подключение к прокси-серверу», чтобы проверить сетевое подключение между узлом Video Mesh и прокси-сервером. Если проверка соединения не удалась, вы увидите сообщение об ошибке, в котором указаны причина и способы устранения проблемы. | ||||||||||
| 5 |
После завершения проверки соединения для явного прокси-сервера включите переключатель в положение Маршрутизация всех HTTPS-запросов к порту 443 с этого узла через явный прокси-сервер. Для вступления этой настройки в силу требуется 15 секунд. | ||||||||||
| 6 |
Нажмите кнопку «Установить все сертификаты в хранилище доверия» (появляется при добавлении корневого сертификата во время настройки прокси-сервера) или «Перезагрузить» (появляется, если корневой сертификат не был добавлен), прочтите окно запроса и нажмите кнопку «Установить», если вы готовы. Узел перезагрузится через несколько минут. | ||||||||||
| 7 |
После перезагрузки узла при необходимости снова войдите в систему, а затем откройте страницу «Обзор», чтобы проверить все проверки подключения и убедиться, что все они отмечены зеленым цветом. Проверка соединения с прокси-сервером проверяет только субдомен webex.com. При возникновении проблем с подключением чаще всего некоторые облачные домены, перечисленные в инструкциях по установке, блокируются на прокси-сервере. |
Какой трафик проходит через прокси-сервер
В Video Mesh медиафайлы не проходят через прокси-сервер. Эта функция отправляет на прокси-сервер сигнальный и управляющий трафик на основе HTTPS. При этом необходимо открыть необходимые порты, чтобы медиапотоки могли напрямую поступать в облако.
TCP-порт 444 не включен на прокси-сервере
Этот порт является обязательным для Video Mesh, поскольку Video Mesh использует этот порт для доступа к облачным сервисам, которые необходимо использовать для правильной работы. Для этого и любого порта необходимо сделать исключение для прокси-сервера, как описано в руководстве по развертыванию Video Mesh и требованиях к сети для служб Webex Teams.
Фильтрация сигнального трафика по IP-адресу не поддерживается, поскольку IP-адреса, используемые в наших решениях, являются динамическими и могут измениться в любое время.
Корневой сертификат не установлен
Когда ваши узлы обращаются к прокси-серверу, использующему явный прокси-сервер, необходимо установить корневой сертификат и ввести исключение для этого URL-адреса на брандмауэре.
Сбой при проверке подключения
Если проверка подключения к прокси-серверу прошла и установка прокси-сервера завершена, проверка подключения на странице обзора все равно может завершиться неудачно по следующим причинам:
-
Прокси-сервер проверяет трафик, который не поступает на webex.com.
-
Прокси-сервер блокирует домены, отличные от webex.com.
Данные аутентификации неверны
Для прокси-серверов, использующих механизм аутентификации, убедитесь, что вы добавили правильные данные аутентификации в узле.
Перегрузка на прокси-сервере
Перегрузка прокси-сервера может привести к задержкам и падению трафика в облаке. Проверьте свою прокси-среду, чтобы узнать, требуется ли регулирование трафика.
Websocket не может подключиться через прокси-сервер Squid
Прокси-серверы Squid, проверяющие HTTPS-трафик, могут помешать установлению соединений websocket (wss:), необходимых для обеспечения безопасности гибридных данных. В этих разделах приведены инструкции по настройке различных версий Squid на игнорирование wss:трафика для правильной работы сервисов.
Squid 4 и 5
Добавьте on_unsupported_protocolдирективу в squid.conf:
on_unsupported_protocol tunnel allSquid 3.5.27
Мы успешно протестировали Hybrid Data Security, добавив следующие правила squid.conf. Эти правила могут изменяться по мере разработки функций и обновления облака Webex.
acl wssMercuryConnection ssl::server_name_regex mercury-connection
ssl_bump splice wssMercuryConnection
acl step1 at_step SslBump1
acl step2 at_step SslBump2
acl step3 at_step SslBump3
ssl_bump peek step1 all
ssl_bump stare step2 all
ssl_bump bump step3 all
