У цьому розділі описано функцію підтримки проксі-сервера для гібридної безпеки даних. Він призначений для доповнення Посібника з розгортання гібридної безпекиданих Cisco Webex, доступного за адресою https://www.cisco.com/go/hybrid-data-security. У новому розгортанні ви налаштовуєте налаштування проксі на кожному вузлі після завантаження та монтажу ISO конфігурації HDS на вузлі та перед реєстрацією вузла в хмарі Cisco Webex.

Гібридна безпека даних підтримує явні, прозорі перевірки та неінспектування проксі. Ви можете прив'язати ці проксі до свого розгортання, щоб ви могли захищати та контролювати трафік від підприємства до хмари. Ви можете використовувати інтерфейс адміністратора платформи на вузлах для управління сертифікатами та для перевірки загального стану підключення після налаштування проксі-сервера на вузлах.

Гібридні вузли захисту даних підтримують такі параметри проксі-сервера:

  • Немає проксі-сервера— за замовчуванням, якщо ви не використовуєте конфігурацію вузла HDS Trust Store та проксі для інтеграції проксі-сервера. Оновлення сертифіката не потрібне.

  • Прозорий проксі-сервер, що не перевіряється — вузли не налаштовані на використання певної адреси проксі-сервера і не повинні вимагати будь-яких змін для роботи з проксі-сервером, який не перевіряється. Оновлення сертифіката не потрібне.

  • Прозоре тунелювання або перевірка проксі-сервера— вузли не настроєно на використання певної адреси проксі-сервера. На вузлах не потрібні зміни конфігурації HTTP або HTTPS. Однак вузлам потрібен кореневий сертифікат, щоб вони довіряли проксі. Інспекційні проксі зазвичай використовуються ІТ-серверами для забезпечення дотримання політик, на яких веб-сайтах можна відвідувати та які типи вмісту заборонені. Цей тип проксі розшифровує весь ваш трафік (навіть HTTPS).

  • Явний проксі- За допомогою явного проксі-сервера ви повідомляєте вузлам HDS, який проксі-сервер і схему автентифікації використовувати. Щоб налаштувати явний проксі, необхідно ввести наступну інформацію на кожному вузлі:

    1. Проксі IP/FQDN— адреса, яку можна використовувати для досягнення проксі-машини.

    2. Проксі-порт— номер порту, який проксі-сервер використовує для прослуховування проксі-трафіку.

    3. Проксі-протокол— залежно від того, що підтримує проксі-сервер, виберіть один із таких протоколів:

      • HTTP — Перегляд і контроль усіх запитів, які надсилає клієнт.

      • HTTPS — забезпечує канал серверу. Клієнт отримує та перевіряє сертифікат сервера.

    4. Типавтентифікації – виберіть один із таких типів автентифікації:

      • Немає— подальша автентифікація не потрібна.

        Доступно, якщо в якості проксі-протоколу вибрано HTTP або HTTPS.

      • Базовий— використовується для агента користувача HTTP для надання імені користувача та пароля під час подання запиту. Використовує кодування Base64.

        Доступно, якщо в якості проксі-протоколу вибрано HTTP або HTTPS.

        Потрібно ввести ім'я користувача і пароль на кожному вузлі.

      • Дайджест— використовується для підтвердження облікового запису перед надсиланням конфіденційної інформації. Застосовує хеш-функцію до імені користувача та пароля перед відправкою по мережі.

        Доступно, лише якщо в якості проксі-протоколу вибрано протокол HTTPS.

        Потрібно ввести ім'я користувача і пароль на кожному вузлі.

Приклад гібридних вузлів безпеки даних і проксі-сервера

На цій схемі наведено приклад підключення між гібридною безпекою даних, мережею та проксі-сервером. Для прозорої перевірки та явної перевірки параметрів проксі-сервера HTTPS на проксі-сервері та на вузлах гібридної безпеки даних повинен бути встановлений той самий кореневий сертифікат.

Заблокований зовнішній режим роздільної здатності DNS (явні конфігурації проксі)

Коли ви реєструєте вузол або перевіряєте конфігурацію проксі-сервера вузла, процес перевіряє пошук DNS і підключення до хмари Cisco Webex. У розгортаннях з явними конфігураціями проксі-сервера, які не дозволяють зовнішню роздільну здатність DNS для внутрішніх клієнтів, якщо вузол не може запитувати DNS-сервери, він автоматично переходить у режим блокування зовнішньої роздільної здатності DNS. У цьому режимі можна продовжити реєстрацію вузла та інші тести проксі-підключення.

  • Ми офіційно підтримуємо наступні проксі-рішення, які можуть інтегруватися з вашими вузлами гібридної безпеки даних.

    • Прозорий проксі—пристрій веб-безпеки Cisco (WSA).

    • Явний проксі-кальмар.


      Проксі Squid, які перевіряють HTTPS-трафік, можуть перешкоджати встановленню websocket (wss:) Підключення. Щоб вирішити цю проблему, перегляньте розділ "Websocket не може підключитися через проксі-сервер Squid" у розділі Проблеми зпроксі.

  • Ми підтримуємо такі комбінації типів автентифікації для явних проксі:

    • Немає автентифікації за допомогою HTTP або HTTPS

    • Базова автентифікація за допомогою HTTP або HTTPS

    • Автентифікація дайджесту лише за допомогою ПРОТОКОЛУ HTTPS

  • Для прозорої перевірки проксі-сервера або явного проксі-сервера HTTPS необхідно мати копію кореневого сертифіката проксі-сервера. Інструкції з розгортання в цьому посібнику розповідають, як завантажити копію в надійні сховища вузлів гібридної безпеки даних.

  • Мережа, в якій розміщуються вузли HDS, повинна бути налаштована на примусове витіснення TCP-трафіку на порту 443 для маршрутизації через проксі.

  • Проксі-сервери, які перевіряють веб-трафік, можуть перешкоджати з'єднанню веб-сокетів. При виникненні даної проблеми проблему вирішить обхід (не огляд) трафіку на wbx2.com і ciscospark.com .

Якщо для мережного середовища потрібен проксі-сервер, скористайтеся цією процедурою, щоб указати тип проксі-сервера, який потрібно інтегрувати з hybrid Data Security. Якщо ви виберете прозорий проксі-сервер перевірки або явний проксі-сервер HTTPS, ви можете використовувати інтерфейс вузла для завантаження та встановлення кореневого сертифіката. Ви також можете перевірити проксі-з'єднання з інтерфейсу та усунути будь-які потенційні проблеми.

Перш ніж почати

1.

Введіть URL-адресу для настроювання вузла HDS https://[IP-адреса вузла HDS або FQDN]/setup у веб-браузері, введіть облікові дані адміністратора, які ви налаштували для вузла, а потім натисніть кнопку Увійти.

2.

Перейдіть до Надійного магазину та проксі-сервера, а потім виберіть параметр:

  • Без проксі-сервера— параметр за замовчуванням перед інтеграцією проксі-сервера. Оновлення сертифіката не потрібне.
  • Прозорий проксі-сервер, що не перевіряється — вузли не настроєні на використання певної адреси проксі-сервера і не повинні вимагати будь-яких змін для роботи з проксі-сервером, який не перевіряється. Оновлення сертифіката не потрібне.
  • Прозора перевірка проксі-сервера— вузли не настроєно на використання певної адреси проксі-сервера. У розгортанні гібридної безпеки даних не потрібні зміни конфігурації HTTPS, однак вузлам HDS потрібен кореневий сертифікат, щоб вони довіряли проксі-серверу. Інспекційні проксі зазвичай використовуються ІТ-серверами для забезпечення дотримання політик, на яких веб-сайтах можна відвідувати та які типи вмісту заборонені. Цей тип проксі розшифровує весь ваш трафік (навіть HTTPS).
  • Явний проксі- За допомогою явного проксі-сервера ви повідомляєте клієнту (вузлам HDS), який проксі-сервер використовувати, і цей параметр підтримує кілька типів автентифікації. Після вибору цього параметра необхідно ввести такі відомості:
    1. Проксі IP/FQDN— адреса, яку можна використовувати для досягнення проксі-машини.

    2. Проксі-порт— номер порту, який проксі-сервер використовує для прослуховування проксі-трафіку.

    3. Проксі-протокол— виберіть http (переглядає та контролює всі запити, які надходять від клієнта) або https (надає серверу канал, і клієнт отримує та перевіряє сертифікат сервера). Виберіть варіант, виходячи з того, що підтримує ваш проксі-сервер.

    4. Типавтентифікації – виберіть один із таких типів автентифікації:

      • Немає— подальша автентифікація не потрібна.

        Доступно для проксі HTTP або HTTPS.

      • Базовий— використовується для агента користувача HTTP для надання імені користувача та пароля під час подання запиту. Використовує кодування Base64.

        Доступно для проксі HTTP або HTTPS.

        Якщо вибрати цей варіант, необхідно також ввести ім'я користувача і пароль.

      • Дайджест— використовується для підтвердження облікового запису перед надсиланням конфіденційної інформації. Застосовує хеш-функцію до імені користувача та пароля перед відправкою по мережі.

        Доступно лише для проксі HTTPS.

        Якщо вибрати цей варіант, необхідно також ввести ім'я користувача і пароль.

Виконайте наступні кроки для прозорої перевірки проксі-сервера, явного HTTP-проксі з базовою автентифікацією або явного проксі-сервера HTTPS.

3.

Клацніть « Завантажити кореневий сертифікат» або «Завершити сертифікатсутності», а потім перейдіть до вибору кореневого сертифіката для проксі-сервера.

Сертифікат завантажено, але ще не інстальовано, оскільки для встановлення сертифіката потрібно перезавантажити вузол. Клацніть стрілку шеврона біля імені емітента сертифіката, щоб отримати докладніші відомості, або натисніть кнопку Видалити , якщо ви припустилися помилки та хочете повторно завантажити файл.

4.

Натисніть кнопку Перевірити підключення до проксі, щоб перевірити підключення до мережі між вузлом і проксі-сервером.

Якщо тест підключення не пройшов, ви побачите повідомлення про помилку, у якому вказано причину та способи усунення проблеми.

Якщо ви бачите повідомлення про те, що зовнішня роздільна здатність DNS не була успішною, вузол не зміг дістатися до DNS-сервера. Ця умова очікується в багатьох явних конфігураціях проксі. Можна продовжити настройку, і вузол запрацює. Якщо ви вважаєте, що це помилка, виконайте наведені нижче дії. Потім можна відключити режим. (Див. Вимкніть режимблокування зовнішньої роздільної здатності DNS.)

5.

Після того, як тест з'єднання пройде, для явного проксі-сервера, встановленого лише на https, увімкніть перемикач до Маршрутизація всіх запитів порту 443/444 https з цього вузла через явний проксі. Для набрання чинності цим параметром потрібно 15 секунд.

6

Натисніть кнопку Інсталювати всі сертифікати в надійний магазин (відображається для проксі-сервера HTTPS відвертої перевірки або прозорого проксі-сервера для перевірки) або Перезавантажити (відображається для явного проксі-сервера HTTP), прочитайте запит і натисніть кнопку Інсталювати , якщо все готово.

Вузол перезавантажується протягом декількох хвилин.

7

Після перезавантаження вузла увійдіть знову, якщо потрібно, а потім відкрийте сторінку Огляду , щоб перевірити перевірки підключення, щоб переконатися, що всі вони в зеленому стані.

Перевірка проксі-з'єднання лише тестує субдомен webex.com. Якщо виникають проблеми з підключенням, поширеною проблемою є те, що деякі хмарні домени, перелічені в інструкціях з інсталяції, блокуються на проксі-сервері.

Що далі

Повторіть конфігурацію проксі-сервера на кожному вузлі в кластері гібридної безпеки даних.

Коли ви реєструєте вузол або перевіряєте конфігурацію проксі-сервера вузла, процес перевіряє пошук DNS і підключення до хмари Cisco Webex. Якщо DNS-серверу вузла не вдається розпізнати загальнодоступні імена DNS, вузол автоматично переходить у режим блокування зовнішньої роздільної здатності DNS.

Якщо ваші вузли можуть вирішувати загальнодоступні імена DNS через внутрішні DNS-сервери, ви можете вимкнути цей режим, повторивши тест проксі-з'єднання на кожному вузлі.

Перш ніж почати

Переконайтеся, що ваші внутрішні DNS-сервери можуть розпізнавати загальнодоступні імена DNS і що ваші вузли можуть зв'язуватися з ними.

1.

У браузері відкрийте інтерфейс вузла гібридної безпеки даних (IP-адреса/налаштування), наприклад, введіть облікові дані адміністратора, https://192.0.2.0/setup), які настроєно для вузла, а потім натисніть кнопку Увійти.

2.

Перехід до розділу Огляд (сторінка за замовчуванням).

Якщо ввімкнено, для параметра "Заблокована зовнішня роздільна здатність DNS" встановлено значення "Так".

3.

Перейдіть на сторінку Надійний магазин і проксі .

4.

Натисніть Перевірити підключенняпроксі-сервера.

Якщо ви бачите повідомлення про те, що зовнішнє дозвіл DNS не було успішним, вузол не зміг дістатися до DNS-сервера і залишиться в цьому режимі. В іншому випадку, після того, як ви перезавантажите вузол і повернетеся на сторінку огляду , заблоковане зовнішнє дозвіл DNS має бути встановлено на "ні".

Що далі

Повторіть тест проксі-з'єднання на кожному вузлі в кластері гібридної безпеки даних.

У цьому розділі описано функцію підтримки проксі-сервера для Webex Video Mesh. Він призначений для доповнення Посібника з розгортання для Відео MeshCisco Webex, доступного за адресою https://www.cisco.com/go/video-mesh. У новому розгортанні ви налаштовуєте налаштування проксі на кожному вузлі після розгортання програмного забезпечення Video Mesh у середовищі віртуальної машини та перед реєстрацією вузла в хмарі Cisco Webex.

Cisco Webex Video Mesh підтримує явну, прозору перевірку та неінспектування проксі- серверів. Ви можете прив'язати ці проксі до розгортання Webex Video Mesh , щоб ви могли захистити та контролювати трафік від підприємства до хмари. Ця функція надсилає сигналізаторство та керування трафіком на основі https на проксі- сервер. Для прозорих проксі мережеві запити з вузлів Video Mesh пересилаються на певний проксі через правила маршрутизації корпоративної мережі. Ви можете використовувати інтерфейс адміністратора Webex 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).

Малюнок 1. Приклад вузлів сітки відео Webex та проксі- сервера.

На цій схемі наведено приклад з'єднання між Webex Video Mesh, мережею та проксі-сервером. Для прозорої перевірки та явної перевірки параметрів проксі-сервера на проксі-сервері та на вузлах Video Mesh має бути встановлений той самий кореневий сертифікат.

  • Ми офіційно підтримуємо наступні проксі-рішення, які можуть інтегруватися з вашими вузлами Webex Video Mesh .

    • Cisco Web Security Appliance (WSA) для прозорого проксі

    • Кальмари для явного проксі

  • Для явного проксі-сервера або прозорого проксі-сервера перевірки, який перевіряє (розшифровує трафік), необхідно мати копію кореневого сертифіката проксі-сервера, який потрібно буде завантажити в сховище довіри вузла Webex Video Mesh у веб-інтерфейсі.

  • Ми підтримуємо такі явні комбінації типів проксі та автентифікації:

    • Немає аутентифікації за допомогою http та https

    • Базова автентифікація за допомогою http та https

    • Дайджест аутентифікації лише за допомогою https

    • Автентифікація NTLM лише за допомогою http

  • Для прозорих проксі ви повинні використовувати маршрутизатор /комутатор, щоб змусити трафік HTTPS / 443 перейти до проксі. Ви також можете змусити Web Socket/444 перейти до проксі. (Веб-сокет використовує https.) Порт 444 залежить від параметрів мережі. Якщо порт 444 не маршрутизується через проксі, він повинен бути відкритий безпосередньо від вузла до хмари.


    Webex Video Mesh вимагає підключення веб-сокетів до хмарних сервісів, щоб вузли функціонували коректно. Під час явної перевірки та прозорої перевірки проксі-серверів http-заголовки, необхідні для належного з'єднання з веб-кодом, змінюються, а з'єднання websocket виходять з ладу.

    Симптомом, коли це відбувається на порту 443 (з увімкненим прозорим проксі-сервером для перевірки), є попередження про реєстрацію в Control Hub: "Виклик Webex Video Mesh SIP не працює належним чином". Такий же сигнал тривоги може виникнути і з інших причин, коли проксі не включений. Коли заголовки websocket блокуються на порту 443, медіа не перетікають між програмами та SIP-клієнтами.

    Якщо медіа не протікає, це часто відбувається, коли трафік https з вузла через порт 444 або порт 443 виходить з ладу:

    • Проксі не перевіряється, але трафік порту 444 не дозволений проксі.

    • Трафік порту 443 або порту 444 дозволений проксі-сервером, але він є проксі-сервером для перевірки та порушує веб-сайт.

    Щоб виправити ці проблеми, можливо, доведеться «обійти» або «злити» (відключити перевірку) на портах 444 і 443, щоб: *.wbx2.com і *.ciscospark.com.

Використовуйте цю процедуру, щоб вказати тип проксі-сервера, який потрібно інтегрувати з Webex Video Mesh. Якщо ви виберете прозорий проксі-сервер для перевірки або явний проксі-сервер, ви можете використовувати інтерфейс вузла для завантаження та встановлення кореневого сертифіката, перевірки проксі-з'єднання та усунення будь-яких потенційних проблем.

Перш ніж почати

1.

Введіть URL-адресу інсталяції Webex Video Mesh https://[IP або FQDN/setup у веб-браузері, введіть облікові дані адміністратора, які ви налаштували для вузла, а потім натисніть кнопку Увійти.

2.

Перейдіть до Надійного магазину та проксі-сервера, а потім виберіть параметр:

  • Без проксі-сервера— параметр за замовчуванням перед інтеграцією проксі-сервера. Оновлення сертифіката не потрібне.
  • Прозорий проксі-сервер, що не перевіряється— вузли Video Mesh не настроєні на використання певної адреси проксі-сервера і не повинні вимагати будь-яких змін для роботи з проксі-сервером, який не перевіряється. Оновлення сертифіката не потрібне.
  • Прозора перевірка проксі- вузли Video Mesh не налаштовані на використання певної адреси проксі-сервера. На Video Mesh не потрібні зміни конфігурації http(s); однак вузли Video Mesh потребують кореневого сертифіката, щоб вони довіряли проксі-серверу. Інспекційні проксі зазвичай використовуються ІТ-серверами для забезпечення дотримання політик щодо того, які веб-сайти можна відвідувати, і типів вмісту, які заборонені. Цей тип проксі розшифровує весь ваш трафік (навіть https).
  • Явний проксі- За допомогою явного проксі-сервера ви повідомляєте клієнту (вузли Video Mesh), який проксі-сервер використовувати, і цей параметр підтримує кілька типів автентифікації. Після вибору цього параметра необхідно ввести такі відомості:
    1. Проксі IP/FQDN— адреса, яку можна використовувати для досягнення проксі-машини.

    2. Проксі-порт— номер порту, який проксі-сервер використовує для прослуховування проксі-трафіку.

    3. Проксі-протокол— виберіть http (Video Mesh тунелює свій https-трафік через проксі-сервер http) або https (трафік від вузла Video Mesh до проксі-сервера використовує протокол https). Виберіть варіант, виходячи з того, що підтримує ваш проксі-сервер.

    4. Виберіть один із наведених нижче типів автентифікації, залежно від середовища проксі-сервера:

      Параметр

      Використання

      Ні

      Виберіть для явних проксі HTTP або HTTPS, де немає методу автентифікації.

      Базове

      Доступно для явних проксі HTTP або HTTPS.

      Використовується для агента користувача HTTP для надання імені користувача та пароля при складанні запиту, а також використовує кодування Base64.

      Дайджест

      Доступно лише для явних проксі HTTPS.

      Використовується для підтвердження облікового запису перед надсиланням конфіденційної інформації та застосовує хеш-функцію до імені користувача та пароля перед надсиланням через мережу.

      NTLM

      Доступно лише для явних проксі HTTP.

      Як і Digest, використовується для підтвердження облікового запису перед надсиланням конфіденційної інформації. Використовує облікові дані Windows замість імені користувача та пароля.

      Якщо вибрати цей параметр, введіть домен Active Directory, який проксі-сервер використовує для автентифікації, у поле NTLM Domain . Введіть ім'я робочої станції проксі-сервера (також називається обліковим записом робочої станції або обліковим записом машини) у вказаному домені NTLM у полі NTLM Workstation .

Виконайте наступні кроки для прозорої перевірки або явного проксі-сервера.

3.

Натисніть кнопку Завантажити кореневий сертифікат або Сертифікаткінцевої сутності, а потім знайдіть і виберіть кореневий сертифікат для явного або прозорого проксі-сервера перевірки.

Сертифікат завантажено, але ще не встановлено, оскільки для встановлення сертифіката вузол потрібно перезавантажити. Клацніть стрілку біля імені емітента сертифіката, щоб отримати докладніші відомості, або натисніть кнопку Видалити , якщо ви припустилися помилки та хочете повторно завантажити файл.

4.

Для прозорої перевірки або явних проксі-серверів натисніть кнопку «Перевірити підключення до проксі-сервера », щоб перевірити підключення до мережі між вузлом Video Mesh і проксі-сервером.

Якщо тест підключення не пройшов, ви побачите повідомлення про помилку, у якому вказано причину та способи усунення проблеми.

5.

Після проходження тесту з'єднання для явного проксі-сервера увімкніть перемикач до Маршрут всіх запитів порту 443/444 https з цього вузла через явний проксі. Для набрання чинності цим параметром потрібно 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:) з'єднання, яких вимагає гібридна безпека даних і Webex Video Mesh. Ви можете побачити серію попереджень у журналах, таких як "Повторне підключення WebSocket ..." як вузол намагається досягти хмари Webex. Спробуйте наступну конфігурацію Squid, залежно від вашої версії Squid, щоб проксі-сервер ігнорував wss: трафік для правильної роботи.

Кальмари 4 і 5

Додайте on_unsupported_protocol директива до squid.conf:

on_unsupported_protocol tunnel all

Кальмари 3.5.27

Ми успішно протестували гібридну безпеку даних за допомогою наступних правил, доданих до 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

Ми успішно протестували Video Mesh з наступними правилами, доданими до squid.conf. (Video Mesh вимагає двох додаткових acls порівняно з гібридним захистом даних.) Ці правила можуть змінюватися в міру розробки функцій і оновлення хмари Webex.

acl wssMercuryConnection ssl::server_name_regex mercury-connection
acl ciscoCloud1 ssl::server_name .wbx2.com
acl ciscoCloud2 ssl::server_name .ciscospark.com

ssl_bump splice wssMercuryConnection
ssl_bump splice ciscoCloud1
ssl_bump splice ciscoCloud2

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