Использование Citrix ADC для развертывания сетевого моста QUIC

Citrix ADC теперь поддерживает режим развертывания сетевого моста QUIC (прокси) для трафика HTTP/3, обеспечивая балансировку нагрузки, расширенную безопасность и более высокую производительность для трафика QUIC. Развертывание прокси предполагает, что Citrix ADC разрывает трафик клиента до сервера и повторно устанавливает новое соединение к серверу для получения запрашиваемой информации.

Citrix ADC обеспечивает постоянные соединения QUIC между клиентом и сервером, что полезно в случае миграции соединений или повторной привязки NAT. Новый зашифрованный транспортный протокол интернета QUIC ускоряет трафик протокола передачи гипертекста (HTTP) за счёт встроенной безопасности и, как ожидается, заменит TCP и TLS в сети. HTTP/3 – это новейшая версия HTTP, она определяет потоки данных между браузерами и веб-сайтами. Ранее я уже писал про преимущества протокола QUIC.

Отличия HTTP/3.

Многие годы протокол HTTP эволюционировал и во многом стал похож на связку протоколов TCP, TLS и HTTP/2, реализованных на базе транспортного протокола UDP. Однако с точки зрения установки соединения и передачи данных – это более эффективно. На диаграмме ниже показано сравнение стеков протокола HTTP/2 и HTTP/3. Типичное квитирование QUIC требует одного цикла обработки между сервером и клиентом по сравнению с двумя циклами для квитирования TCP и TLS. Другими словами, QUIC обрабатывает аутентификацию и шифрование за один шаг.

Отличительные особенности HTTP/3:

• Быстрое квитирование (Faster Handshake): HTTP/3 использует QUIC, объединенный с TLS 1.3, что ускоряет квитирование.
• Улучшенная производительность (Improved Performance): HTTP/3 не подвержен ошибками блокировки заголовка TCP, что является одной из самых больших проблем HTTP/2.
• Встроенная безопасность (Built-in Security): TLS 1.3 новее и более безопасен, чем TLS 1.2 в HTTP/2.
• Устойчивая миграция сети (Reliable Network Migration): HTTP/2 требует пересмотра сессии для браузеров, а с QUIC передача проще.

Сетевой мост QUIC и Citrix ADC.

Сетевой мост QUIC (QUIC Bridge) – это один из возможных сценариев применения HTTP/3 в Citrix ADC. В данном случае Citrix ADC выступает в качестве прокси и маршрутизирует, а также балансирует нагрузку пакетов данных QUIC от клиентов к фоновым серверам.

Рассмотрим пример, в котором клиент с включенной поддержкой HTTP/3 в браузере собирается посетить веб-сайт со своего ноутбука. Клиент вводит URL и имя хоста преобразуется в IP-адрес. В развертывании прокси квитирование происходит между клиентом и Citrix ADC, а другое соединение между Citrix ADC и сервером. Citrix ADC располагается между участниками и управляет трафиком. На диаграмме ниже показан Citrix ADC в режиме прокси.

Режим передачи сетевой мост QUIC (QUIC Bridge) в Citrix ADC:

1. Клиент подключается к URL через сеть Wi-Fi.
2. Сервер DNS разрешает имя хоста в IP-адрес.
3. Устанавливается соединение UDP.
4. Контроллер доставки приложений (ADC) маршрутизирует пакеты QUIC до сервера назначения на базе типа пакета.
5. Выполняется балансировка нагрузки (Load Balancing).
6. Клиент перемещается в мобильную сеть из сети Wi-Fi.
7. Устанавливается соединение UDP.
8. Контроллер доставки приложений (ADC) маршрутизирует пакеты QUIC до сервера назначения на базе типа пакета.
9. Удержание сессии (Session Persistency) гарантирует подключение к тому же серверу после миграции соединения.

QUIC упрощает обработку, когда клиент перемещается из одной сети в другую, так как пакеты QUIC содержат идентификатор подключения сервера, что позволяет конечным точкам связывать пакеты, не полагаясь на адрес. Если клиент перемещается на другое устройство или сеть, QUIC обеспечивает миграцию подключения.

Начать использовать HTTP/3.

Прокси QUIC в Citrix ADC можно использовать и для защиты приложений от уязвимостей. Большинство браузеров на сегодняшний день поддерживают HTTP/3 и Citrix ADC может помочь с балансировкой нагрузки трафика QUIC, вне зависимости от используемых браузеров и приложений.

Поддержка сетевого моста QUIC доступна в Citrix ADC с версии 13.0.76.x. Дополнительную информацию можно получить при помощи следующих ссылок: QUIC, Citrix Application Delivery Controller (ADC) и Citrix Application Delivery Management (ADM).

Тонкости настройки syslog в Citrix ADC

Syslog – это один из наиболее часто используемых методов для получения сообщений аудита из различных систем в централизованное расположение. Syslog позволяет вести мониторинг и длительное время хранить аудит, ошибки и прочие системные сообщения со всей инфраструктуры в едином расположении.

С точки зрения безопасности, достаточно важно иметь репозиторий syslog, который не хранит сообщения на исходной системе, так как это гарантирует защиту сообщений аудита в случае компрометации системы.

Можно разделить требования к syslog Citrix ADC на две части: функциональные возможности Citrix ADC и операционная система Citrix ADC. Рассмотрим обе стороны этого вопроса.

Syslog для функциональных возможностей Citrix ADC.

Документация по syslog для Citrix ADC рекомендует использовать выражения продвинутых политик (Advanced Policy Expression) при настройке Citrix ADC, так как выражения классических политик (Classical Policy) устарели и не будут поддерживаться в будущих релизах.

Процесс настройки сообщений syslog для отправки на удаленный сервер в общем виде состоит из 3 шагов:

1. Создание сервера syslog для определения назначения и способа отправки сообщений.
2. Создание политик syslog для определения момента отправки сообщений.
3. Привязка политик syslog для определения сообщений, которые должны быть отправлены.

Если нет особых требований, то абсолютно нормально отправлять все уровни журнала, за исключением уровня отладки (Debug). Уровень отладки может быть включен, в крайнем случае, для устранения неисправностей. Необходимо осторожно подходить к уровню отладки (Debug), так как на этом уровне генерируется значительный объем данных, который быстро заполняет доступное хранилище.

Если существуют требования учёта срабатываний списков контроля доступа (ACL), ведение журнала ACL должно быть включено и для сервера syslog, куда будут отправляться журналы, а также отдельные правила ACL для записи в журнал.

Также не лишним будет включить отправку пользовательских сообщений syslog. В противном случае в журнале не отобразятся настраиваемые действия (Actions).

Пример команд для настройки отправки сообщений syslog для хранения на сервер syslog и Citrix Application Delivery Management (ADM):

add audit syslogAction retention-syslog-SRV -logLevel EMERGENCY ALERT CRITICAL ERROR WARNING NOTICE INFORMATIONAL -acl ENABLED -userDefinedAuditlog YES

add audit syslogAction CitrixADM-syslog-SRV -logLevel EMERGENCY ALERT CRITICAL ERROR WARNING NOTICE INFORMATIONAL -userDefinedAuditlog YES

add audit syslogPolicy retention-syslog-POL true retention-syslog-SRV

add audit syslogPolicy CitrixADM-syslog-POL true CitrixADM-syslog-SRV

bind audit syslogGlobal -policyName retention-syslog-POL -priority 100

bind audit syslogGlobal -policyName CitrixADM-syslog-POL -priority 110

Syslog для операционной системы Citrix ADC.

Довольно часто в развертываниях встречается отсутствующая конфигурация для отправки сообщений о происходящем в операционной системе на внешний сервер syslog. Все, что попадает в журнал, – это вход пользователя в систему и запуск команды shell, ничего более в журнал на сервере syslog не попадает. Это значит, что в случае сбоя и невозможности получить локальный журнал на Citrix ADC, узнать подробности происходившего не получится. Более того, при условии возможности интерактивного входа, передовой опыт не позволяет доверять целостности файлов локальных журналов.

Некоторые конфигурационные файлы, хранящихся в /etc, могут быть скопированы в /nsconfig, для большей устойчивости в процессе перезагрузки. /etc/syslog.conf – один из примеров таких файлов.

Выбор syslog local, зависит от конфигурации сервера syslog, на который будут отправляться сообщения. Для Citrix ADM можно использовать все доступные уровни local от 0 до 7. Звёздочка (*) после local7, определяет все сообщения для отправки на сервер syslog.

Также необходимо отредактировать /nsconfig/rc.netscaler для перезапуска демона syslog после загрузки, чтобы убедиться в использовании корректного конфигурационного файла. Если Citrix ADC сконфигурирован в высоко доступной паре, NSIP не может быть указан в явном виде, вместо этого, он может быть извлечен из файла na.conf, как показано в примере ниже.

Одна последняя вещь, которую нужно учесть – все команды, которые выполняются в оболочке, выполняются от имени пользователя root, который и будет указан в поле имени пользователя (username) в сообщениях syslog.

Для включения отправки сообщений syslog о событиях в операционной системе на внешний сервер выполните следующие действия:

1. Скопируйте /etc/syslog.conf в /nsconfig/syslog.conf.

2. Добавьте следующие строки в /nsconfig/syslog.conf.

local7.*                 @<IP-АДРЕС СЕРВЕРА SYSLOG>

local7.*                 @<IP-АДРЕС СЕРВЕРА SYSLOG>

3. Добавьте следующие строки в /nsconfig/rc.netscaler:

pkill syslogd

nsip=$(grep -i ‘set ns config -IPAddress’ /nsconfig/ns.conf | cut -d ‘ ’ -f 5)

/usr/sbin/syslogd -b $nsip -n -v -v -8 -C &

4. Выполните принудительную синхронизацию высоко доступной пары и перезагрузите оба узла, чтобы изменения вступили в силу.

Надёжный внешний репозиторий для хранения журналов syslog – это критически важный аспект при устранении неисправностей, проведении расследований и прочих задачах. Надеюсь, информация из данного блога окажется для вас полезной и пригодится в дальнейшем. За основу данного материала я хотел бы поблагодарить Magnus Esse, а дополнительную информацию по ведению журнала событий аудита можно получить в документации.

HTTP3, TLS 1.3 и Citrix ADC

Обсудим новинки интернет-безопасности, которые появились за последние несколько лет.

Новейшие браузеры теперь поддерживают HTTP3 (также известный как HTTP-over-QUIC). Раньше это был HTTP2, который являлся улучшенной версией HTTP1.1 за счёт возможностей мультиплексирования. Это увеличивало производительность, но могло привести к некоторым ошибкам блокировки Head-Of-Line (HOL).

Блокировка Head-Of-Line (HOL) – это проблема ограничения производительности, которая происходит при задержке первого пакета в линии. HTTP3 решил данную проблему, позволив остальным потокам пакетов передаваться без ошибок. На данный момент HTTP3 поддерживается всеми основными браузерами: Chrome, Firefox и Safari. 

В связи с непрерывным ростом использования интернета в последнее десятилетие, как никогда актуальна потребность в скорости, производительности и безопасности. HTTP3 вместе с TLS1.3 модернизирует интернет при помощи возможностей безопасности и производительности:

• HTTP3 исправляет ошибки блокировки заголовка линии (HOL), которым подвержен HTTP2.
• HTTP3 использует QUIC, при работе с TLS 1.3. Это минимизирует время на установку соединения, в то же время объединяет криптографическое и транспортное квитирование. QUIC – это транспортный протокол общего назначения, который улучшает производительность веб-приложений, ориентированных на подключение с использованием TCP.
• TLS 1.3 – это новый протокол шифрования, который улучшает безопасность и производительность (сокращая накладные расходы HTTPS) по сравнению с предыдущими версиями TLS.

На диаграмме ниже представлены различия между HTTP2 и HTTP3 с использованием QUIC (интегрированного с TLS 1.3):

Нужно отметить, что Citrix ADC – это первый контроллер доставки приложений (ADC) на рынке, который включил поддержку протокола TLS 1.3 практически сразу после его ратификации. К текущему моменту уже более 1000 клиентов Citrix используют программные возможности TLS 1.3. Аппаратное ускорение TLS 1.3 уже доступно с новейшими моделями Citrix ADC, а вслед за ним ожидается и поддержка HTTP3 с QUIC.

Citrix ADC продолжает использовать современные инновации и продвинутые возможности. Так как ADC использует единую базу кода, Citrix ADC может запущен как локально, так и в облаке. Citrix ADC продолжает поддерживать движение клиентов в сторону гибридных облаков, а за счёт применения новейших протоколов способствует увеличению производительности и безопасности приложений.

Ещё одна замечательная особенность – это возможности Citrix Application Delivery Management (ADM), позволяющие упростить управление Citrix ADC и предоставляющие подробности SSL (SSL Insights). Подробности SSL предоставляют прозрачность безопасности веб-транзакций (HTTPS), позволяя администраторам вести мониторинг всех защищаемых веб-приложений, обслуживаемых Citrix ADC и обеспечивая представления реального времени и исторические тренды безопасных транзакций. При помощи этой расширенной видимости администраторы могут получить следующие преимущества:

• Влияние изменений конфигурации на клиентов: администратор может понять влияние на клиентов перед внесением изменений в конфигурацию, такого как отключение SSLv3 или удаление шифра RC4-MD5. Это может быть выполнено при помощи оценки исторических данных транзакций с указанием протоколов и шифров.
• Качество производительности клиентов: администраторы могут понять влияние на время отклика приложения на базе использованных шифров/протоколов или передаваемых сертификатов.
• Безопасность приложения: администраторы могут оценивать транзакции приложений, запущенные с использованием слабозащищенных протоколов, шифров или слабых ключей.

Также решение на базе Citrix ADC под управлением ADM приобретает особое значение в условиях пандемии, когда многие администраторы работают удаленно и вынуждены подключаться из вне.

Миссия Citrix ADC заключается в непрерывной доставке инноваций и добавлении улучшений производительности и безопасности интернет протоколов.

При помощи следующих ссылок можно подробнее познакомиться с Citrix ADC и Citrix ADM.