Този раздел описва функцията за поддръжка на прокси за защита на хибридни данни. Той е предназначен да допълни ръководството за разполагане на Cisco Webex Hybrid Data Security, достъпно на https://www.cisco.com/go/hybrid-data-security. В ново разполагане конфигурирате настройката на прокси сървъра на всеки възел след качване и монтиране на HDS конфигурация ISO на възел и преди да регистрирате възела с облака Cisco Webex.

Hybrid Data Security поддържа изрични, прозрачни проверяващи и неинспектационни проксита. Можете да свържете тези проксита към разполагането си, така че да можете да подсигурите и наблюдавате трафика от предприятието навън към облака. Можете да използвате администраторски интерфейс на платформа на възлите за управление на сертификати и да проверите цялостното състояние на свързване, след като настроите прокси сървъра на възлите.

Хибридните възли за защита на данните поддържат следните опции за прокси:

  • Няма прокси– По подразбиране, ако не използвате HDS възел настройка хранилище на доверие & прокси конфигурация за интегриране на прокси. Не се изисква актуализация на сертификата.

  • Прозрачен неинспективен прокси сървър— Възлите не са конфигурирани да използват конкретен прокси сървър адрес и не трябва да изискват никакви промени за работа с неинспективен прокси сървър. Не се изисква актуализация на сертификата.

  • Прозрачно тунелиране или инспектиращ проксисървър — Възлите не са конфигурирани да използват конкретен прокси сървър адрес. На възлите не са необходими промени в конфигурацията на HTTP или HTTPS. Възлите обаче се нуждаят от главен сертификат, така че да се доверяват на прокси. Проверяващите пълномощници обикновено се използват от It за прилагане на политики, на които могат да бъдат посетени уебсайтовете и кои видове съдържание не са разрешени. Този тип прокси дешифрира целия ви трафик (дори HTTPS).

  • Изрично прокси–С изрично прокси, вие казвате на HDS възли кой прокси сървър и удостоверяване схема да използвате. За да конфигурирате изрично прокси, трябва да въведете следната информация на всеки възел:

    1. Прокси IP/FQDN—Адрес, който може да се използва за достигане на прокси машината.

    2. Прокси порт— Номер на порт, който прокси прокси използва, за да слуша за прокси трафик.

    3. Протокол за прокси сървър—В зависимост от това, което поддържа вашият прокси сървър, изберете между следните протоколи:

      • HTTP—Преглежда и контролира всички заявки, които клиентът изпраща.

      • HTTPS—Предоставя канал на сървъра. Клиентът получава и валидира сертификата на сървъра.

    4. Тип удостоверяване—Изберете измежду следните типове удостоверяване:

      • Няма— Не се изисква допълнително удостоверяване.

        Налично, ако изберете или HTTP Или HTTPS като протокол за прокси.

      • Основно—Използва се за HTTP потребителски агент за предоставяне на потребителско име и парола при отправяне на заявка. Използва Base64 кодиране.

        Налично, ако изберете или HTTP Или HTTPS като протокол за прокси.

        Изисква да въведете потребителското име и паролата на всеки възел.

      • Digest—Използва се за потвърждаване на акаунта, преди да изпратите чувствителна информация. Прилага хеш функция на потребителското име и паролата преди изпращане по мрежата.

        Предлага се само ако изберете HTTPS като протокол за прокси.

        Изисква да въведете потребителското име и паролата на всеки възел.

Пример за хибридни данни сигурност възли и прокси

Тази диаграма показва примерна връзка между защитата на хибридните данни, мрежата и прокси. За прозрачния инспектиращ и HTTPS изричен инспектиращ прокси опции, един и същ главен сертификат трябва да бъде инсталиран на прокси и на хибридните възли за защита на данните.

Блокиран режим на външна DNS разделителна способност (изрични прокси конфигурации)

Когато регистрирате възел или проверете конфигурацията на прокси сървъра на възела, процесът тества DNS справка и свързаност към облака Cisco Webex. В разполагане с изрични прокси конфигурации, които не позволяват външна DNS разделителна способност за вътрешни клиенти, ако възелът не може да заявка DNS сървъри, тя автоматично преминава в режим блокирани външни DNS резолюция. В този режим може да се процедира регистрация на възли и други тестове за свързване на прокси.

  • Ние официално поддържаме следните прокси решения, които могат да се интегрират с вашите възли hybrid Data Security.

    • Прозрачен прокси-Уред за уеб защита cisco (WSA).

    • Изрична прокси-Сепия.


      Сепия проксита, които инспектират HTTPS трафик може да попречи на установяването на websocket (wss:) Връзки. За да заобиколите този проблем, вижте "Websocket не може да се свърже чрез сепия прокси" в прокси проблеми.

  • Ние поддържаме следните комбинации от тип удостоверяване за изрични проксита:

    • Без удостоверяване с HTTP или HTTPS

    • Базово удостоверяване с HTTP или HTTPS

    • Смилане на удостоверяване само с HTTPS

  • За прозрачен проверяващ прокси или HTTPS изрично прокси, трябва да имате копие на главния сертификат на прокси. Инструкциите за разполагане в това ръководство ви казват как да качите копието в магазините за доверие на хибридните възли за защита на данните.

  • Мрежата, хостваща HDS възлите, трябва да бъде конфигурирана да принуди изходящия TCP трафик на порт 443 да маршрутизира през прокси сървъра.

  • Прокситата, които инспектират уеб трафика, може да пречат на връзките с уеб гнездото. Ако възникне този проблем, заобикалянето (не инспектирането) на трафика към wbx2.com и ciscospark.com ще реши проблема.

Ако мрежовата среда изисква прокси, използвайте тази процедура, за да укажете вида на прокси, който искате да интегрирате с Hybrid Data Security. Ако изберете прозрачен проверяващ прокси или HTTPS изричен прокси, можете да използвате интерфейса на възела, за да качите и инсталирате главния сертификат. Можете също да проверите прокси връзката от интерфейса и да отстраните всички потенциални проблеми.

1

Въведете URL адреса за настройка на HDS възел https://[HDS Възел IP или FQDN]/настройка в уеб браузър, въведете администраторски идентификационни данни, които сте настроили за възела и след това щракнете върху Вход.

2

Отидете на Хранилище на доверие & Прокси , след което изберетеопция:

  • No Proxy—Опцията по подразбиране, преди да интегрирате прокси. Не се изисква актуализация на сертификата.
  • Прозрачен прокси сървър, който не проверява— Възлите не са конфигурирани да използват конкретен адрес на прокси сървър и не трябва да изискват никакви промени за работа с прокси сървър, който не проверява. Не се изисква актуализация на сертификата.
  • Прозрачен проверка прокси–възли не са конфигурирани да използват конкретен прокси сървър адрес. Не httpS конфигурация промени са необходими в разполагането на защитата на хибридни данни, обаче HDS възли се нуждаят от главен сертификат, така че те се доверяват на прокси. Проверяващите пълномощници обикновено се използват от It за прилагане на политики, на които могат да бъдат посетени уебсайтовете и кои видове съдържание не са разрешени. Този тип прокси дешифрира целия ви трафик (дори HTTPS).
  • Изрично прокси–С изрично прокси, вие кажете на клиента (HDS възли) кой прокси сървър да използвате и тази опция поддържа няколко типа удостоверяване. След като изберете тази опция, трябва да въведете следната информация:
    1. Прокси IP/FQDN—Адрес, който може да се използва за достигане на прокси машината.

    2. Прокси порт— Номер на порт, който прокси прокси използва, за да слуша за прокси трафик.

    3. Протокол за прокси сървър—Изберете http (изгледи и контролира всички заявки, които са получени от клиента) или https (предоставя канал към сървъра и клиентът получава и валидира сертификата на сървъра). Изберете опция въз основа на това, което поддържа вашият прокси сървър.

    4. Тип удостоверяване—Изберете измежду следните типове удостоверяване:

      • Няма— Не се изисква допълнително удостоверяване.

        Налична за HTTP или HTTPS проксита.

      • Основно—Използва се за HTTP потребителски агент за предоставяне на потребителско име и парола при отправяне на заявка. Използва Base64 кодиране.

        Налична за HTTP или HTTPS проксита.

        Ако изберете тази опция, трябва да въведете и потребителското име и паролата.

      • Digest—Използва се за потвърждаване на акаунта, преди да изпратите чувствителна информация. Прилага хеш функция на потребителското име и паролата преди изпращане по мрежата.

        Предлага се само за HTTPS проксита.

        Ако изберете тази опция, трябва да въведете и потребителското име и паролата.

Изпълнете следващите стъпки за прозрачен проверяващ прокси, HTTP изрично прокси с базово удостоверяване или HTTPS изрично прокси.

3

Щракнете върху Качване на главен сертификат или Сертификат за краен обект и след това навигирайте до изберете главния сертификат запрокси.

Сертификатът се качва, но все още не е инсталиран, защото трябва да рестартирате възела, за да инсталирате сертификата. Щракнете върху стрелката chevron по името на издателя на сертификата, за да получите повече подробности или щракнете върху Изтрий, ако сте направили грешка и искате да качите повторно файла.

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. Тя е предназначена да допълни ръководството за разполагане на Cisco Webex Video Mesh, достъпно на 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 изрично прокси.)

    • Digest—Използва се за потвърждаване на самоличността на акаунта преди изпращане на чувствителна информация, и прилага хеш функция на потребителското име и паролата преди изпращане по мрежата. (За HTTPS изрично прокси.)

    • NTLM—Подобно на Digest, NTLM се използва за потвърждаване на самоличността на акаунта, преди да изпрати чувствителна информация. Използва идентификационни данни за Windows вместо потребителското име и паролата. Тази схема за удостоверяване изисква няколко обмена да завърши. (За HTTP изрично прокси.)

  • Прозрачен прокси (неинспектър)—Възлите video Mesh не са конфигурирани да използват конкретен адрес на прокси сървър и не трябва да изискват никакви промени за работа с прокси сървър, който не проверява.

  • Прозрачен прокси (инспектиране)—Възлите video Mesh не са конфигурирани да използват конкретен адрес на прокси сървър. Не са необходими http(и) промени в конфигурацията на Video Mesh, обаче, възлите video Mesh се нуждаят от главен сертификат, така че да се доверяват на прокси сървъра. Проверяващите пълномощници обикновено се използват от It за прилагане на политики по отношение на това кои уебсайтове могат да бъдат посетени и видове съдържание, които не са разрешени. Този тип прокси дешифрира целия ви трафик (дори https).

Фигура 1. Пример за Webex видео мрежести възли и прокси.

Тази диаграма показва примерна връзка между Webex Video Mesh, мрежа и прокси. За прозрачните опции за проверка и изрично инспектиране на прокси, един и същ главен сертификат трябва да бъде инсталиран на прокси и на възлите Video Mesh.

  • Ние официално поддържаме следните прокси решения, които могат да се интегрират с вашите Webex Video Mesh възли.

    • Уред за уеб защита cisco (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 (с разрешен прозрачен проверяващ прокси) е предупреждение след регистрацията в контролния център: "Webex Видео Mesh SIP повикване не работи правилно." Същата аларма може да възникне по други причини, когато прокси не е разрешен. Когато заглавки на websocket са блокирани на порт 443, носител не тече между приложения и SIP клиенти.

    Ако носител не тече, това често се случва, когато https трафик от възела над порт 444 или порт 443 е неуспешно:

    • Прокси не е проверка, но порт 444 трафик не е разрешено от прокси.

    • Порт 443 или порт 444 трафик е разрешено от прокси, но това е инспектиращ прокси и е разбиване на уебсокет.

    За да коригирате тези проблеми, може да се наложи да "заобиколите" или "splice" (деактивирате проверката) на портове 444 и 443, за да: *.wbx2.com и *.ciscospark.com.

Използвайте тази процедура, за да укажете вида на прокси, който искате да интегрирате с Webex Video Mesh. Ако изберете прозрачен проверяващ прокси или изричен прокси, можете да използвате интерфейса на възела, за да качите и инсталирате главния сертификат, да проверите прокси връзката и да отстраните всички потенциални проблеми.

Преди да започнете

1

Въведете URL адреса за настройка на Webex Video Meshhttps://[IP или FQDN/настройка в уеб браузър, въведете идентификационни данни за администратор, които сте задали за възела, след което щракнете върху Влизане.

2

Отидете на Хранилище на доверие & Прокси , след което изберетеопция:

  • No Proxy—Опцията по подразбиране, преди да интегрирате прокси. Не се изисква актуализация на сертификата.
  • Прозрачен неинспектиран проксисървър —Възлите на Видео мрежа не са конфигурирани да използват конкретен адрес на прокси сървър и не трябва да изискват никакви промени за работа с прокси сървър, който не проверява. Не се изисква актуализация на сертификата.
  • Прозрачни проверка прокси–Видео мрежа възли не са конфигурирани да използват конкретен прокси сървър адрес. Не са необходими http(и) промени в конфигурацията на Video Mesh; обаче, възлите Video Mesh се нуждаят от главен сертификат, така че да се доверяват на прокси. Проверяващите пълномощници обикновено се използват от It за прилагане на политики по отношение на това кои уебсайтове могат да бъдат посетени и видове съдържание, които не са разрешени. Този тип прокси дешифрира целия ви трафик (дори 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 домейн. Въведете името на прокси работнатастанция (наричана също акаунт на работна или машинна сметка) в рамките на указания NTLM домейн в полето NTLM Workstation.

Следвайте следващите стъпки за прозрачен инспектиращ или изрично прокси.

3

Щракнете върху Качване на главен сертификат или Сертификат за краен обект , след което намерете и изберете главния сертификат за изрично или прозрачнопроверяващо прокси.

Сертификатът е качен, но все още не е инсталиран, защото възелът трябва да се рестартира, за да инсталирате сертификата. Щракнете върху стрелката по името на издателя на сертификата, за да получите повече подробности или щракнете върху Изтрий, ако сте направили грешка и искате да качите повторно файла.

4

За прозрачни инспектиращи или изрични проксита щракнете върху Проверка на прокси връзката, за да тествате мрежовата свързаност между възела Video Mesh и прокси.

Ако тестът за връзка е неуспешен, ще видите съобщение за грешка, което показва причината и как можете да коригирате проблема.

5

След като тестът за свързване премине, за изрично прокси, включете превключването към Маршрут всички порт 443/444 https заявки от този възел чрез изрично прокси. Тази настройка изисква 15 секунди, за да влязат в сила.

6

Щракнете върху Инсталиране на всички сертификати в хранилището на гаранти (появява се винаги, когато е добавен главен сертификат по време на настройката на прокси) или Рестартиране (появява се, ако не е добавен главен сертификат), прочетете подканата и след това щракнете върху Инсталиране, ако сте готови.

Възелът се рестартира в рамките на няколко минути.

7

След рестартирането на възела влезте отново, ако е необходимо, след което отворете страницата Общ преглед, за да проверите проверките за свързване, за да се уверите, че всички те са в зелено състояние.

Проверката на прокси връзката тества само поддомейн от webex.com. Ако има проблеми със свързването, често срещан проблем е, че някои от облачните домейни, изброени в инструкциите за инсталиране, се блокират в прокси.

Какво трафик преминава през прокси

За Video Mesh мултимедията не трасва прокси. Тази функция изпраща сигнализация и управление https-базирани трафик на прокси. Все още трябва да отворите необходимите портове за мултимедийни потоци, за да достигнете директно до облака.

TCP порт 444 не е разрешен на прокси

Този порт е изискване за Video Mesh, защото видео mesh използва този порт за достъп до услуги, базирани на облак, които трябва да използва, за да функционира правилно. Трябва да се направи прокси изключение за този порт и ANY, както е документирано в ръководството за разполагане на видео мрежа имрежовите изисквания за услугите на Webex Teams.


Филтрирането на трафика за сигнализация по IP адрес не се поддържа, тъй като IP адресите, използвани от нашите решения, са динамични и могат да се променят по всяко време.

Няма инсталиран главен сертификат

Когато възлите ви говорят с изрично прокси, трябва да инсталирате главния сертификат и да въведете изключение за този URL адрес на защитната ви стена.

Проверката на свързаността е неуспешна

Ако проверката за свързване на прокси прокси е преминала и инсталирането на прокси е приключило, проверките за свързване на страницата за общ преглед може все още да са неуспешни поради тези причини:

  • Проксиът инспектира трафика, който не отива на webex.com.

  • Проксиът блокира домейни, различни от webex.com.

Подробности за удостоверяването са неправилни

За проксита, които използват механизъм за удостоверяване, се уверете, че добавяте правилните подробности за удостоверяване в възела.

Задръствания по Прокси

Задръстванията по проксито ви могат да причинят забавяне и капки с трафик към облака. Проверете прокси средата си, за да видите дали се изисква дроселиране на трафика.

Websocket не може да се свърже чрез сепия прокси

Сепия проксита, които инспектират HTTPS трафик може да попречи на установяването на websocket (wss:) връзки, които защитата на хибридните данни и Webex Video Mesh изискват. Може да видите поредица от предупреждения в регистрационните файлове като" Повторно свързване на WebSocket..." като възел се опитва да достигне уебекс облака. Опитайте следната конфигурация на Squid, в зависимост от вашата версия на Squid, за да получите прокси сървъра, за да игнорирате WSS: трафик за правилна работа.

Калмята 4 и 5

Добавяне на on_unsupported_protocol директива към squid.conf:

on_unsupported_protocol tunnel all

Сепия 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

Успешно тествахме 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