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

Підтримка проксі

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

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

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

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

  • Прозоре тунелювання чи інспектування проксі— вузли не налаштовані на використання конкретної адреси проксі-сервера. На вузлах не потрібні зміни конфігурації 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. У цьому режимі можна продовжити реєстрацію вузла та інші тести проксі-підключення.

Вимоги до проксі-сервера

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

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

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

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

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

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

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

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

Налаштування вузла HDS для інтеграції проксі

Якщо для мережного середовища потрібен проксі-сервер, скористайтеся цією процедурою, щоб указати тип проксі-сервера, який потрібно інтегрувати з 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. Якщо ви вважаєте, що це помилка, виконайте наведені дії, а потім перегляньте Вимкнути режим роздільної здатності заблокованих зовнішніх DNS.

5

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

6

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

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

7

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

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

Вимкнення режиму роздільної здатності заблокованих зовнішніх DNS

Коли ви реєструєте вузол або перевіряєте конфігурацію проксі-сервера вузла, процес перевіряє пошук 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.

Підтримка проксі для 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 і проксі
Вимоги до підтримки проксі для Video Mesh

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

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

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

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

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

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

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

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

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

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

    Video Mesh вимагає підключення вебсокетів до хмарних служб, щоб вузли працювали правильно. У разі явної перевірки й прозорої перевірки проксі-серверів заголовки HTTP потрібні для належного з’єднання вебсокетів. Якщо їх змінено, підключення вебсокета не вдасться.

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

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

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

    Щоб виправити ці проблеми, вам, можливо, доведеться "обходити" або "splice" (вимкнути перевірку) на порту 443 до: *.wbx2.com і *.ciscospark.com.

Налаштувати Video Mesh Node для інтеграції проксі-сервера

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

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

1

Введіть URL налаштування 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 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

Проксі-сервери, які перевіряють HTTPS-трафік, можуть перешкоджати встановленню з’єднань вебсокетів (wss:), які потребують гібридної безпеки даних. У цих розділах наведено інструкції щодо налаштування різних версій Squid, щоб ігнорувати wss: трафік для належної експлуатації послуг.

Кальмари 4 і 5

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

on_unsupported_protocol тунель усі

Кальмари 3.5.27

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

acl wssMercuryConnection ssl::Mercury-server_name_regex connection ssl_bump splice wssMercuryConnection acl step1 at_step SslBump1 acl step2 at_step SslBump2 acl step3 at_step SslBump3 ssl_bump peek step1 всі ssl_bump stare step2 всі ssl_bump bump step3 всі