5. Параметры bind и server
Ключи “bind”, “server” и “default-server” поддерживают ряд настроек, зависящих от некоторых опций сборки и от системы, на которой был собран HAProxy. Эти настройки в целом состоят из одного слова, иногда сопровождаемого значением, записанным на той же строке, что и строка “bind” или “server”. Все эти опции описаны в этой секции.
5.1. Параметры bind
Ключ “bind” поддерживает определённое количество настроек, которые передаются как аргументы на той же строке. Порядок, в котором эти аргументы приводятся, не имеет значения, при условии, что они находятся после адреса привязки. Все эти параметры являются необязательными. Некоторые из них состоят из одного слова (логические значения), в то время как другие ожидает значение после них. В этом случае значение должно быть указано немедленно после имени настройки.
Текущие настройки, поддерживаемые в данный момент, следующие.
accept-netscaler-cip <magic number>
Обязательно используется протокол вставки IP-адреса клиента NetScaler при любом соединении, принятом любым из сокетов TCP, объявленных на той же строке. Протокол вставки IP-адреса клиента NetScaler определяет использование адресов слоя 3/4 входящего соединения во всех случаях, где используется адрес, с единственным исключением — правила “tcp-request connection”, которые увидят только реальный адрес соединения. В логах будут отражаться адреса, указанные в протоколе, за исключением случаев нарушения, в которых будет использоваться реальный адрес. Данное ключевое слово в сочетании с поддержкой внешних компонентов может быть использовано как эффективное и надежное решение в качестве альтернативы механизму X-Forwarded-For, который не всегда надежен и не всегда может быть использован. См. также “tcp-request connection expect-netscaler-cip” для более тонкой настройки того, какие клиенты могут использовать протокол.
accept-proxy
Требует использования протокола PROXY для любого соединения, принятого любым сокетом, объявленным в той же строке. Версии 1 и 2 протокола PROXY поддерживаются и корректно определяются. Протокол PROXY задаёт адреса уровня 3/4 входящего соединения, которые используются везде, где требуется адрес, за единственным исключением правил “tcp-request connection”: они видят только реальный адрес соединения. В журналах отражаются адреса, указанные в протоколе, если только он не нарушен; при нарушении используется реальный адрес. Эта директива совместно с поддержкой внешних компонентов может эффективно и надёжно заменять механизм X-Forwarded-For, который не всегда надёжен и даже не всегда применим. Для более точного определения клиентов, которым разрешено использовать протокол, см. также “tcp-request connection expect-proxy”.
allow-0rtt
Разрешает приём ранних данных при использовании TLSv1.3. По соображениям безопасности эта возможность по умолчанию отключена. Она уязвима к атакам повторного воспроизведения, поэтому её следует разрешать только для запросов, которые безопасно повторять, то есть идемпотентных запросов. Для любого запроса, небезопасного при использовании ранних данных, можно применять действие “wait-for-handshake”. Для QUIC режим 0rtt поддерживается с QuicTLS, OpenSSL >= 3.5.2 и AWS-LC. Для TCP/TLS режим 0rtt поддерживается только с OpenSSL и требует передачи ALPN клиентом; иначе ранние данные не рассматриваются до выполнения рукопожатия.
alpn <protocols>
Это включает расширение TLS ALPN и объявляет указанный список протоколов как поддерживаемый в дополнение к ALPN. Список протоколов состоит из запятой-разделённого списка названий протоколов, например:
“http/1.1,http/1.0” (без кавычек). Это требует, чтобы библиотека SSL была собрана с включённой поддержкой
расширений TLS (проверьте с помощью haproxy -vv). Расширение ALPN заменяет инициальное расширение NPN. На уровне протокола требуется ALPN для включения HTTP/2 на фронтенде HTTPS и HTTP/3 на фронтенде QUIC. Однако, когда такие фронтенды не имеют установленных значений “npn”, “alpn” и “no-alpn”, будет использован по умолчанию значение “h2,http/1.1” для обычного фронтенда HTTPS и “h3” для фронтенда QUIC. Версии OpenSSL до 1.0.2 не поддерживали ALPN и использовали теперь устаревшее расширение NPN. В момент написания этого текста большинство браузеров всё ещё поддерживают оба протокола ALPN и NPN для HTTP/2, поэтому переключение на NPN может продолжаться ещё некоторое время. Однако следует использовать ALPN в любом случае. Протоколы, не объявленные в списке, не договариваются. Например, возможно принять только соединения HTTP/2 с помощью этого:
QUIC поддерживает только h3 и hq-interop как ALPN. h3 предназначен для HTTP/3 и hq-interop используется для http/0.9 и QUIC interop runner (см. https://interop.seemann.io ). Каждое утверждение “alpn” заменяет предыдущее. Для их удаления используйте “no-alpn”.
Примечание, что некоторые старые браузеры, такие как Firefox 88, ранее испытывали проблемы с WebSocket через H2, и в случае такого настроения может потребоваться явно отключить HTTP/2 в строке “alpn”, установив её в “http/1.1” или “no-alpn”, или включить “h2-workaround-bogus-websocket-clients” глобально.
backlog <backlog>
Устанавливает размер очереди сокета в указанное значение. Если значение не указано или 0, используется значение очереди фронтенда, что в целом по умолчанию соответствует значению maxconn.
ca-file <cafile>
Этот параметр доступен только тогда, когда поддержка OpenSSL была включена. Он указывает на файл PEM, из которого загружаются сертификаты CA, используемые для проверки сертификата клиента. Возможна загрузка каталога, содержащего несколько CA, в этом случае HAProxy попытается загрузить каждый “.pem”, “.crt”, “.cer” и .crl в каталоге, файлы, начинающиеся с точки, игнорируются.
Предупреждение: Параметр “@system-ca” может быть использован вместо cafile для использования доверенных CA системы, как это делается с директивой server. Но его использование не рекомендуется, если вы не понимаете, что делаете. Настройка таким образом означает, что подключение будет принимать любой сертификат клиента, сгенерированный на одном из CA, находящихся на вашей системе, что является чрезвычайно небезопасным.
ca-ignore-err [all|<errorID>,...]
Этот параметр доступен только тогда, когда поддержка OpenSSL была включена. Устанавливает запятую разделённый список errorIDs для игнорирования при проверке на глубине > 0. Может быть числовым идентификатором или именем константы (X509_V_ERR), доступным в документации OpenSSL:
https://www.openssl.org/docs/manmaster/man3/X509_STORE_CTX_get_error.html#ERROR-CODES
Рекомендуется использовать имя константы, так как числовое значение может изменяться в новых версиях OpenSSL. При установке в ‘all’ игнорируются все ошибки. SSL если ошибка игнорируется, сессия рукопожатия не завершается.
ca-sign-file <cafile>
Этот параметр доступен только тогда, когда в HAProxy включена поддержка OpenSSL. Он обозначает файл PEM, содержащий как сертификат доверенного центра (CA), так и приватный ключ этого центра, используемый для создания и подписи сертификатов серверов. Этот параметр является обязательным при включении динамической генерации сертификатов. См. ‘generate-certificates’ для подробностей.
ca-sign-pass <passphrase>
Этот параметр доступен только тогда, когда поддержка OpenSSL была включена. Это пароль от приватного ключа CA. Параметр является необязательным и используется только при включении динамической генерации сертификатов. См. ‘generate-certificates’ для подробностей.
ca-verify-file <cafile>
Этот параметр указывает на файл PEM из которого загружаются сертификаты CA, используемые для проверки сертификата клиента. Он указывает на сертификаты CA, которые не должны содержаться в названиях CA, передаваемых в сообщении server hello. Обычно “ca-file” должен быть задан сертификатами промежуточных узлов, а “ca-verify-file” — сертификатами, завершающими цепочку, такими как корневой CA.
cc <algo>
Этот параметр доступен только на системах, которые определяют TCP_CONGESTION, и был протестирован на Linux и FreeBSD. Он принимает имя алгоритма управления перегрузкой TCP и настраивает слушатель на использование этого алгоритма для всех соединений, принимаемых через данный слушатель. Типичные имена включают “reno”, “cubic” и зависят от операционной системы. На некоторых системах для настройки определённых алгоритмов могут потребоваться специальные разрешения. На Linux список доступных алгоритмов можно найти в sysctl “net.ipv4.tcp_available_congestion_control”, а список разрешённых без привилегий — в “net.ipv4.tcp_allowed_congestion_control”. Для доступа к алгоритмам, требующим дополнительных разрешений, может потребоваться возможность “cap_net_admin” (см. “setcap” в глобальной секции). В случае неудачи при настройке конкретного алгоритма управления перегрузкой используется значение по умолчанию, и выводится предупреждение, сообщающее об ошибке. См. также: ключевое слово сервера “cc” ( секция 5.2 ). Пример:
ciphers <ciphers>
Этот параметр доступен только тогда, когда поддержка OpenSSL была включена. Он задаёт строку, описывающую список алгоритмов шифрования (“cipher suite”), которые участвуют в обмене во время SSL/TLS-рукопожатия до TLSv1.2. Формат строки определён в документации “man 1 ciphers” от OpenSSL. Для дополнительной информации и рекомендаций см. например,
(https://wiki.mozilla.org/Security/Server_Side_TLS
) и
(https://mozilla.github.io/server-side-tls/ssl-config-generator/
). Для настройки алгоритмов шифрования в TLSv1.3, см. ключевое слово “ciphersuites”.
ciphersuites <ciphersuites>
Этот параметр доступен только тогда, когда поддержка OpenSSL была включена, и использовалась версия OpenSSL 1.1.1 или новее. Он задаёт строку, описывающую список алгоритмов шифрования (“комплект шифрования”), которые устанавливались во время обмена TLSv1.3. Формат строки определён в разделе “ciphersuites” в документации OpenSSL “man 1 ciphers”. Для настройки шифрования в TLSv1.2 и более ранних версиях, см. ключевое слово “ciphers”. Этот параметр может принимать комплекты шифрования TLSv1.2, однако это неофициальное поведение и не рекомендуется, так как может быть нестабильным или багоносным. По умолчанию OpenSSL использует следующие комплекты шифрования TLSv1.3: “TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256”
TLSv1.3 поддерживает только 5 симметрических ключей:
- TLS_AES_128_GCM_SHA256
- TLS_AES_256_GCM_SHA384
- TLS_CHACHA20_POLY1305_SHA256
- TLS_AES_128_CCM_SHA256
- TLS_AES_128_CCM_8_SHA256
Пример:
client-sigalgs <sigalgs>
Этот параметр доступен только тогда, когда в HAProxy был включён поддержка OpenSSL. Он задаёт строку, описывающую список алгоритмов подписи, связанных с аутентификацией клиента, которые согласовываются. Формат строки определён в «man 3 SSL_CTX_set1_client_sigalgs» из страниц справки OpenSSL. Не рекомендуется использовать этот параметр, если не было идентифицировано конкретного сценария использования.
crl-file <crlfile>
Этот параметр доступен только тогда, когда встроенная поддержка OpenSSL. Он обозначает файл PEM из которого необходимо загрузить список отмены сертификатов, используемый для проверки сертификата клиента. Для каждого сертификата вашей цепочки сертификатов доверия необходимо предоставить список отмены сертификатов.
crt <cert>
Этот параметр доступен только тогда, когда встроенная поддержка OpenSSL.
HAProxy использует систему кэширования, файлы загружаются только один раз в хранилище сертификатов, и каждый последующий ключ “crt” будет использовать эту кэшированную версию. Когда сертификат указан в виде “crt-store”, хранилище сертификатов заполняется из этого источника и не пытается загружать дополнительные файлы путём определения расширений файлов.
Он обозначает файл PEM, содержащий необходимые сертификаты и любые связанные приватные ключи.
Этот файл может быть создан путём конкатенации нескольких файлов PEM в один (например, cat cert.pem key.pem > combined.pem). Если ваша СА требует промежуточного сертификата, его также можно конкатенировать в этот файл. Промежуточный сертификат также может быть размещён в каталоге через директиву “issuers-chain-path”.
Если файл не содержит приватного ключа, HAProxy попытается загрузить ключ по тому же пути, дополненному суффиксом “.key”.
Если в используемом OpenSSL поддерживается Diffie-Hellman, параметры, присутствующие в этом файле, загружаются.
Если вместо файла PEM используется имя каталога, то все файлы, найденные в этом каталоге, будут загружены в алфавитном порядке, за исключением тех, названия которых заканчиваются на ‘.key’, ‘.issuer’, ‘.ocsp’ или ‘.sctl’ (зарезервированные расширения). Файлы, начинающиеся с точки, также игнорируются. Данная директива может быть указана несколько раз для загрузки сертификатов из нескольких файлов или каталогов. Сертификаты будут представлены клиентам, предоставляющим действительное поле TLS Server Name Indication, соответствующее одному из их CN или альтернативных подъектов. Поддерживаются шаблоны, где символ ‘*’ используется вместо первого компонента имени хоста (например, *.example.org соответствует www.example.org , но не www.sub.example.org ). Если используется пустой каталог, HAProxy не запустится, если не используется ключевое слово “strict-sni”.
Если клиент не предоставляет SNI или если библиотека SSL не поддерживает расширения TLS, или если клиент предоставляет имя хоста SNI, которое не соответствует никакому сертификату, то будет представлен первый загруженный сертификат. Это означает, что при загрузке сертификатов из каталога крайне рекомендуется загружать по умолчанию один как файл или обеспечивать, чтобы он всегда был первым в каталоге. Для выбора нескольких по умолчанию сертификатов (1 rsa и 1 ecdsa), существуют 3 опции:
- Многосертификатный пакет может быть настроен как первый сертификат (
crt foobar.pemв конфигурации, где существующие файлы являютсяfoobar.pem.ecdsaиfoobar.pem.rsa). - Или фильтр ‘*’ для каждого сертификата в строке crt-list.
- Можно использовать ключевое слово ‘default-crt’.
Примечание, что один и тот же сертификат может быть загружен несколько раз без побочных эффектов.
Некоторые CA (например, GoDaddy) предлагают выпадающий список типов серверов, в котором HAProxy не включён при получении сертификата. Если такое происходит, убедитесь, что выбран тип веб-сервера, который по мнению CA требует промежуточного CA (для GoDaddy выбор Apache Tomcat обеспечит правильный пакет, в то время как многие другие, например nginx, приводят к неправильному пакету, который не будет работать для некоторых клиентов).
Для каждого файла PEM HAProxy проверяет наличие файла по тому же пути, дополняемого суффиксом “.ocsp”. Если такой файл найден, поддержка расширения запроса статуса сертификата TLS (также известного как «OCSP stapling») включается автоматически. Содержимое этого файла является необязательным. Если оно не пустое, оно должно содержать действительный ответ OCSP в формате DER. Для того чтобы ответ OCSP был действительным, он должен соответствовать следующим правилам: он должен указывать хороший статус, должен быть единственным ответом на сертификат файла PEM и должен быть действительным в момент добавления. Если эти правила не соблюдены, ответ OCSP игнорируется и выдается предупреждение. Для определения того, к какому сертификату относится ответ OCSP, необходим сертификат издающего. Если сертификат издающего не найден в файле PEM, он будет загружен из файла по тому же пути, что и файл PEM, дополняемого суффиксом “.issuer”, если такой файл существует, иначе будет выдано сообщение об ошибке.
Для каждого файла PEM HAProxy также проверяет наличие файла по тому же пути, дополняемого суффиксом “.sctl”. Если такой файл найден, поддержка расширения прозрачности сертификатов (RFC6962) TLS включается. Файл должен содержать действительный список подписанного времени сертификата, как описано в RFC. Файл анализируется для проверки базовой синтаксической корректности, но подписи не проверяются.
В некоторых случаях желательно поддерживать несколько типов ключей, например, RSA и ECDSA в наборах шифров, предлагаемых клиентам. Это позволяет клиентам, поддерживающим сертификаты на основе EC, использовать шифры на основе EC, при этом одновременно поддерживать более старые клиенты, RSA только.
Для достижения этого требуется OpenSSL 1.1.1. Это поведение можно настроить путём указания одного записи crt на каждый тип сертификата или настройкой «пакета сертификатов», как это требовалось ранее в HAProxy 1.8. См. “ssl-load-extra-files”.
crt-ignore-err <errors>
Этот параметр доступен только тогда, когда поддержка OpenSSL была включена. Устанавливает запятую разделённый список errorIDs для игнорирования при проверке на уровне == 0. Может быть числовое значение или имя константы (X509_V_ERR), доступное в документации OpenSSL:
https://www.openssl.org/docs/manmaster/man3/X509_STORE_CTX_get_error.html#ERROR-CODES
Рекомендуется использовать имя константы, так как числовое значение может изменяться в новых версиях OpenSSL. При установке в ‘all’ игнорируются все ошибки. SSL ручной обмен не прерывается, если ошибка игнорируется.
crt-list <file>
Этот параметр доступен только тогда, когда поддержка OpenSSL была включена. Он обозначает список PEM файла с опциональной конфигурацией ssl и фильтром SNI на каждый сертификат, с следующим форматом для каждой строки:
Пустые строки, а также строки, начинающиеся с символа решётки (’#’), будут игнорироваться.
Фронтенд crt-list может быть изменён динамически через сокет статистики. (См. “add ssl crt-list”, “del ssl crt-list”, “show ssl crt-list” в руководстве по управлению).
crt-list обычно являются отдельными файлами, однако каталог, загруженный с помощью директивы “crt”, представляется внутренне как crt-list. Директива “ssl-f-use” в фронтенде также объявляет crt-list, связанную с этим фронтенда.
crtfile:
sslbindconf:
snifilter:
Пример:
default-crt <cert>
Этот параметр выполняет то же самое, что и параметр “crt”, с тем отличием, что этот сертификат будет использоваться и как по умолчанию. Возможна добавление нескольких сертификатов по умолчанию, чтобы иметь один ECDSA и один RSA, но наличие большего количества не является особенно полезным.
Этот параметр не отключает скрытые по умолчанию сертификаты; если сертификат ‘crt’ указан первым, до любого ‘default-crt’ или других ‘crt’, он всё ещё будет использоваться как сертификат по умолчанию.
Используется стандартный сертификат, когда в строке bind не указано “strict-sni”. Стандартный сертификат предоставляется тогда, когда расширение servername не использовалось клиентом, или когда значение servername не совпадает с настроенным сертификатом.
Пример:
См. также ключевое слово “crt”.
curves <curves>
Этот параметр доступен только тогда, когда поддержка OpenSSL была включена. Он задаёт строку, описывающую список алгоритмов эллиптических кривых (“набор кривых”), которые устанавливаются в ходе SSL/TLS-обмена с ECDHE. Формат строки — это список названий кривых, разделённых двоеточием. Пример: “X25519:P-256” (без кавычек). При задании “curves” параметр “ecdhe” игнорируется.
defer-accept
Является опциональным ключевым словом, поддерживающимся только на определённых ядрах Linux. Оно означает, что соединение будет принято только после поступления каких-либо данных на него, или в худшем случае — после первого повторного передачи. Это следует использовать только для протоколов, в которых клиент говорит первым (например, HTTP). Оно может немного улучшить производительность, обеспечивая, что большая часть запроса уже доступна к моменту принятия соединения. С другой стороны, оно не сможет обнаруживать соединения, в которых клиент не говорит. Важно отметить, что данная опция не работает в всех ядрах до 2.6.31, поскольку соединение никогда не принимается до того, как клиент начнёт говорить. Это может привести к проблемам с передовыми фильтрами, которые увидят установленное соединение, в то время как прокси увидит его только в SYN_RECV. Данная опция поддерживается только для сокетов TCPv4/TCPv-6 и игнорируется другими.
ecdhe <named curve>
Этот параметр доступен только тогда, когда встроенная поддержка OpenSSL. Он задаёт имя кривой (RFC 4492), используемой для генерации ECDH временных ключей. По умолчанию используется кривая prime256v1.
ech <dir> [ EXPERIMENTAL ]
Применяйте все ключи ECH из <dir> к строке привязки. Файлы должны иметь расширение .ech и должны использовать формат файла PEM для ECH. ( https://datatracker.ietf.org/doc/draft-farrell-tls-pemesni/
)
Этот ключ включает ECH в режиме shared. при работе HAProxy как конца TLS и как конца ECH. См. https://datatracker.ietf.org/doc/draft-ietf-tls-esni/
Это экспериментальная функция, которая требует опции “expose-experimental-directives” в секции global. Она также требует версии OpenSSL, поддерживающей ECH (https://github.com/openssl/openssl/tree/feature/ech ), и HAProxy должен быть скомпилирован с USE_ECH=1. Функция ECH API в AWS-LC не поддерживается.
Пример:
expose-fd listeners
Этот параметр применим только к сокету статистики. Он предоставляет сокету статистики возможность передавать файловые описатели слушателей в другой процесс HAProxy. В режиме master-worker такая передача уже не требуется, файловые описатели слушателей передаются через внутренние сокет-пары между мастером и рабочими процессами. См. также “-x” в руководстве по управлению.
force-sslv3
Этот параметр обеспечивает использование только SSLv3 для соединений SSL, созданных из этого слушателя. SSLv3 в целом менее затратен, чем соответствующие варианты TLS, при высокой интенсивности соединений. Данный параметр также доступен в глобальном утверждении “ssl-default-bind-options”. См. также “ssl-min-ver” и “ssl-max-ver”.
force-tlsv10
Этот параметр обеспечивает использование только TLSv1.0 на соединениях SSL, созданных из этого слушателя. Данный параметр также доступен в глобальном утверждении “ssl-default-bind-options”. См. также “ssl-min-ver” и “ssl-max-ver”.
force-tlsv11
Этот параметр обеспечивает использование только TLSv1.1 на соединениях SSL, созданных из этого слушателя. Данный параметр также доступен в глобальном утверждении “ssl-default-bind-options”. См. также “ssl-min-ver” и “ssl-max-ver”.
force-tlsv12
Этот параметр обеспечивает использование TLSv1.2 только на соединениях SSL, созданных из этого слушателя. Данный параметр также доступен в глобальном утверждении “ssl-default-bind-options”. См. также “ssl-min-ver” и “ssl-max-ver”.
force-tlsv13
Этот параметр обеспечивает использование TLSv1.3 только на соединениях SSL, созданных из этого слушателя. Данный параметр также доступен в глобальном утверждении “ssl-default-bind-options”. См. также “ssl-min-ver” и “ssl-max-ver”.
generate-certificates
Этот параметр доступен только тогда, когда поддержка OpenSSL была включена. Он включает динамическое создание SSL
сертификатов. Необходимо наличие сертификата CA и его приватного ключа (см. ‘ca-sign-file’).
Когда HAProxy настроен как прозрачный прокси, SSL запросы генерируют ошибки из-за несоответствия имени общего имени в сертификате, представленном клиенту. При включении данного параметра HAProxy пытается создать сертификат, используя имя хоста SNI, указанное клиентом. Это происходит только в случае, если нет сертификата, соответствующего имени хоста SNI (см. ‘crt-list’).
В случае ошибки при создании сертификата соединение переключается на стандартный сертификат. При использовании ‘strict-sni’ стандартный сертификат не используется и соединение приводит к сбою рукопожатия.
Данный параметр также может использоваться при настройке HAProxy как обратного прокси для упрощения развёртывания архитектуры с множеством бэкендов.
Создание SSL сертификата — дорогостоящая операция, поэтому используется LRU кэш для хранения сгенерированных сертификатов (см. ’tune.ssl.ssl-ctx-cache-size’). Это увеличивает потребление памяти HAProxy с целью сокращения задержки при многократном использовании одного сертификата.
gid <gid>
Устанавливает группу сокетов UNIX на указанный системный идентификатор группы. Этот параметр также может быть задан по умолчанию в утверждении секции “unix-bind” глобальной секции. Примечание: на некоторых платформах этот параметр игнорируется. Данное настройка эквивалентно настройке “group”, за исключением того, что используется идентификатор группы вместо её имени. Данное настройка игнорируется для не UNIX сокетов.
group <group>
Устанавливает группу сокетов UNIX на указанную системную группу. Она также может быть задана по умолчанию в утверждении секции global “unix-bind”. Примечание, что на некоторых платформах эта настройка игнорируется. Эта настройка эквивалентна настройке “gid”, за исключением того, что используется имя группы вместо её идентификатора. Эта настройка игнорируется для не UNIX сокетов.
guid-prefix <string>
Генерируйте уникальные и чувствительные к регистру идентификаторы для каждого слушателя, выделенного на данной строке привязки.
Предфикс будет сконкатенирован к индексу позиции слушателей на текущей строке привязки, с использованием символа ‘-’ в качестве разделителя. См. описание ключевого слова “guid” прокси для получения дополнительной информации о его формате. См. также “shm-stats-file”.
id <id>
Исправляет идентификатор сокета. По умолчанию идентификаторы сокетов автоматически присваиваются, но в некоторых случаях удобнее их фиксировать для упрощения мониторинга. Значение должно быть строго положительным и уникальным в пределах слушателя/фронтенда. Данное опция может быть использована только при определении единственного сокета.
idle-ping <delay>
Может использоваться в следующих контекстах: tcp, http, log
Задаёт интервал периодической проверки работоспособности простаивающих соединений фронтенда. Если другая сторона не отвечает до следующей запланированной проверки, соединение закрывается. Иначе тайм-аут клиента обновляется, а соединение сохраняется. Учтите: таймеры http-request/http-keep-alive работают параллельно и не обновляются через idle-ping.
Для этой возможности требуется поддержка нижележащего протокола. Пока она реализована только в мультиплексоре H2. Остальные протоколы просто игнорируют idle-ping.
Параметр особенно полезен при использовании обратного HTTP. Его указание в строке bind полезно для узла, который активно устанавливает соединения, а затем получает по ним входящий трафик.
interface <interface>
Ограничивает сокет до определённого интерфейса. При указании сокет обрабатывает только пакеты, полученные с указанного интерфейса. Данный функционал доступен только на Linux. Интерфейс должен быть первичным системным интерфейсом, а не алиасированным интерфейсом. Возможна привязка нескольких фронтендов к одному адресу, если они привязаны к разным интерфейсам. Примечание: привязка к сетевому интерфейсу требует прав root. Данный параметр совместим только с сокетами TCPv4/TCPv6. При указании, выходной трафик использует тот же интерфейс, что и входной трафик, и соответствующую таблицу маршрутизации, даже если настроены явные маршруты через другие интерфейсы. Это может быть полезно для устранения проблем асимметричной маршрутизации, когда одинаковые IP-адреса клиентов должны быть способны доставлять запросы к фронтендам, размещённым на разных интерфейсах.
ktls <on|off> [ EXPERIMENTAL ]
Включает или отключает ktls для соответствующих сокетов. При включении kTLS будет использоваться, если ядро поддерживает это и шифрование совместимо. Доступно только для ядра Linux 4.17 и выше. Примечание: некоторые сетевые драйверы и/или TLS стеки могут ограничивать использование kTLS только для TLS v1.2. См. также “force-tlsv12”.
label <label>
Устанавливает опциональную метку для этих сокетов. Может быть использован для группировки сокетов по метке, независимо от того, где были объявлены строки bind.
level <level>
Этот параметр используется только с сокетами статистики для ограничения характера команд, которые можно отправить по сокету. Он игнорируется другими сокетами. <level> может принимать одно из следующих значений:
- “user” — наименее привилегированный уровень; допускается только чтение нечувствительных статистик, изменений не допускается. Подходит для систем, где ограничение доступа к сокету затруднено.
- “operator” — стандартный уровень и подходит для большинства распространённых случаев. Допускается чтение всех данных, разрешены только нечувствительные изменения (например, очистка максимальных счётчиков).
- “admin” следует использовать с осторожностью, так как разрешены все действия (например, очистка всех счётчиков).
maxconn <maxconn>
Ограничивает сокеты количеством одновременных соединений. Дополнительные соединения остаются в очереди системы до того, как соединение будет освобождено. Если не указано иное, ограничение будет таким же, как у фронтенда maxconn. Примечание: в случае диапазонов портов или нескольких адресов одинаковое значение будет применено к каждому сокету. Эта настройка позволяет устанавливать различные ограничения для дорогостоящих сокетов, например SSL записей, которые могут легко занять всю память.
mode <mode>
Устанавливает восьмеричный режим, используемый для определения разрешений доступа к сокету UNIX. Этот параметр также может быть задан по умолчанию в команде “unix-bind” секции глобальной конфигурации. Примечание: на некоторых платформах этот параметр просто игнорируется. Данное настройка игнорируется для не UNIX сокетов.
mss <maxseg>
Задаёт значение максимального размера сегмента (MSS) для TCP, которое будет объявляться при входящих соединениях. Это может использоваться для принудительного установления меньшего MSS для определённых портов, например, при соединениях, проходящих через VPN. Обратите внимание, что эта функция зависит от функции ядра, которая теоретически поддерживается в Linux, но была нестабильной во всех версиях до 2.6.28. Она может не работать на других операционных системах. Также возможно, что значение не изменится, но изменится эффективный размер исходящих сегментов. Обычно объявляемое значение TCPv4 в сетях Ethernet составляет 1460 = 1500(MTU) - 40(IP+TCP). Если это значение положительное, оно будет использоваться как объявляемое MSS. Если отрицательное — оно указывает, на сколько следует уменьшить объявляемое MSS входящего соединения для исходящих сегментов. Этот параметр совместим только с сокетами TCP v4/v6.
name <name>
Устанавливает опциональное имя для этих сокетов, которое будет отображаться на странице статистики.
namespace <name>
На Linux возможно указать, к какому сетевому пространству принадлежит сокет. Эта директива позволяет явно привязать слушатель к пространству имен, отличному от стандартного. См. документацию операционной системы для получения дополнительной информации о сетевых пространствах имен.
nbconn <nbconn> [ EXPERIMENTAL ]
Этот параметр действует только для экземпляров слушателей, использующих обратный HTTP. Он определяет количество соединений, которые будут размещаться параллельно. Если параметр не указан, используется значение по умолчанию 1.
Обратный HTTP в настоящее время всё ещё находится на стадии активного развития. Механизм конфигурации может измениться в будущем. Поэтому он внутренне помечен как экспериментальный, что означает, что “expose-experimental-directives” должен быть указан на строке перед этим директивой.
nice <nice>
Устанавливает «дружелюбность» соединений, инициируемых из сокета. Значение должно находиться в диапазоне -1024..1024
включительно и по умолчанию равно нулю. Положительные значения означают, что такие соединения более дружелюбны к другим и легко предоставляют место в планировщике. Напротив, отрицательные значения означают, что соединения хотят работать с более высоким приоритетом по сравнению с другими. Разница проявляется только при высоких нагрузках, когда система приближается к насыщению. Отрицательные значения подходят для служб с низкой задержкой или администрирования, а высокие значения в целом рекомендуются для CPU интенсивных задач, таких как SSL обработка или массовые передачи, которые менее чувствительны к задержке. Например, может быть оправдано использование положительного значения для сокета SMTP и отрицательного значения для сокета RDP.
no-alpn
Отключает обработку ALPN (с технической точки зрения это устанавливает строку ALPN в пустую, которая не будет объявляться). Это позволяет отменить предыдущее значение настройки “alpn” и отключить переговоры по протоколу приложения. Может также использоваться для предотвращения переговоров ALPN с клиентом на слушателе HTTPS или QUIC; по умолчанию слушатели HTTPS объявляют “h2,http/1.1” и слушатели QUIC — “h3”. См. также “alpn” выше. Примечание: при использовании “crt-list” сертификат может перекрыть настройку “alpn” и включить повторную обработку.
no-ca-names
Этот параметр доступен только тогда, когда встроенная поддержка OpenSSL. Он предотвращает отправку имён СА в сообщении сервера hello при использовании ca-file. Используйте “ca-verify-file” вместо “ca-file” с “no-ca-names”.
no-sslv3
Этот параметр доступен только тогда, когда поддержка OpenSSL была включена. Он отключает поддержку SSLv3 на любых сокетах, создаваемых из слушателя, при наличии SSL. Примечание: поддержка SSLv2 принудительно отключена в коде и не может быть включена с помощью настроек конфигурации. Этот параметр также доступен в глобальном утверждении “ssl-default-bind-options”. Используйте “ssl-min-ver” и “ssl-max-ver” вместо этого.
no-strict-sni
Этот параметр доступен только тогда, когда поддержка OpenSSL была включена. Он отключает strict-sni внедрение из предыдущего директивы “strict-sni”. Может быть необходим для селективного отключения использования strict-sni на строке “bind”, когда оно уже было глобально включено через “ssl-default-bind-options”. См. также опцию привязки “strict-sni”.
no-tls-tickets
Этот параметр доступен только тогда, когда поддержка OpenSSL была включена. Он отключает состояние-независимое восстановление сессии (RFC 5077 TLS Ticket extension) и вынуждает использовать состояние-зависимое восстановление сессии. Состояние-независимое восстановление сессии более затратно в CPU использовании. Этот параметр также доступен в глобальном утверждении “ssl-default-bind-options”. Механизм TLS ticket используется только до TLS 1.2. Прямая безопасность нарушается при использовании TLS тикетов, если ключи тикетов не периодически пересылаются (через перезагрузку или с помощью “tls-ticket-keys”).
no-tlsv10
Этот параметр доступен только тогда, когда поддержка OpenSSL была включена. Он отключает поддержку TLSv1.0 на любых сокетах, создаваемых из слушателя, при наличии поддержки SSL. Примечание: SSLv2 выключена в коде и не может быть включена с помощью любого параметра конфигурации. Этот параметр также доступен в глобальном утверждении “ssl-default-bind-options”. Используйте “ssl-min-ver” и “ssl-max-ver” вместо этого.
no-tlsv11
Этот параметр доступен только тогда, когда поддержка OpenSSL была включена. Он отключает поддержку TLSv1.1 на любых сокетах, создаваемых из слушателя, при наличии поддержки SSL. Примечание: SSLv2 принудительно отключена в коде и не может быть включена с помощью любого параметра конфигурации. Этот параметр также доступен в глобальном утверждении “ssl-default-bind-options”. Используйте “ssl-min-ver” и “ssl-max-ver” вместо этого.
no-tlsv12
Этот параметр доступен только тогда, когда поддержка OpenSSL была включена. Он отключает поддержку TLSv1.2 на любых сокетах, создаваемых из слушателя, при наличии поддержки SSL. Примечание: SSLv2 выключена в коде и не может быть включена с помощью любого параметра конфигурации. Этот параметр также доступен в глобальном утверждении “ssl-default-bind-options”. Используйте “ssl-min-ver” и “ssl-max-ver” вместо этого.
no-tlsv13
Этот параметр доступен только тогда, когда поддержка OpenSSL была включена. Он отключает поддержку TLSv1.3 на любых сокетах, создаваемых из слушателя, при наличии поддержки SSL. Примечание: SSLv2 принудительно отключена в коде и не может быть включена с помощью любого параметра конфигурации. Этот параметр также доступен в глобальном утверждении “ssl-default-bind-options”. Используйте “ssl-min-ver” и “ssl-max-ver” вместо этого.
npn <protocols>
Это включает расширение NPN TLS и объявляет указанный список протоколов как поддерживаемый в дополнение к NPN. Список протоколов состоит из запятой-разделённого списка названий протоколов, например:
“http/1.1,http/1.0” (без кавычек). Требуется, чтобы библиотека SSL была собрана с включённой поддержкой расширений TLS (проверьте с помощью haproxy -vv). Примечание, что расширение NPN было заменено расширением ALPN (см. ключевое слово “alpn”), хотя последнее доступно только начиная с OpenSSL 1.0.2. Если требуется поддержка HTTP/2 на более ранней версии OpenSSL, возможно, всё ещё можно использовать NPN, поскольку большинство клиентов по-прежнему поддерживают его на момент написания этого текста. Возможна одновременная включение как NPN, так и ALPN, хотя, вероятно, это не имеет смысла при тестировании.
prefer-client-ciphers
Используйте предпочтения клиента при выборе набора шифров, по умолчанию предпочтения сервера применяются. Эта опция доступна также в глобальном утверждении “ssl-default-bind-options”.
Примечание: при использовании OpenSSL >= 1.1.1 ChaCha20-Poly1305 автоматически приоритизируется (без настройки данного параметра), если шифр ChaCha20-Poly1305 находится на вершине списка шифров клиента.
При использовании настройки с двумя алгоритмами (RSA + ECDSA) алгоритм выбора будет выбирать между RSA и ECDSA и всегда будет приоритизировать ECDSA. После выбора правильного сертификата, библиотека SSL будет приоритизировать шифры, кривые и т.д. Следовательно, данный параметр не может быть использован для приоритизации сертификата RSA над сертификатом ECDSA.
proto <name>
Обязательно заставляет мультиплексер использовать протокол для входящих соединений. Он должен быть совместим с режимом фронтенда (TCP или HTTP). Он также должен быть применим с точки зрения фронтенда. Список доступных протоколов приведён в haproxy -vv.. Свойства протоколов приведены: режим (TCP/HTTP), сторона (FE/BE), имя мультиплексера и его флаги.
Некоторые протоколы подвержены блокировке на стороне сервера (флаг=HOL_RISK). Наконец, некоторые протоколы не поддерживают обновление (флаг=NO_UPG). Также отображается совместимость HTX (флаг=HTX).
Вот протоколы, которые могут использоваться в качестве аргумента директивы “proto” на строке bind:
Понятие за счёт этого параметра — обойти выбор оптимального протокола мультиплексера для всех соединений, создаваемых из этого слушающего сокета. Например, возможно принудительно задать протокол http/2 на прозрачном канале TCP, указав “proto h2” в строке привязки.
Если настроены параметры ALPN или NPN, указанные протоколы должны быть совместимы с протоколом мультиплексера, чтобы избежать проблем. Например, если задан “proto h1”, то ALPN не должен быть установлен в значение “h2”.
QMux — подмножество QUIC, работающее над TCP. Оно соответствует следующему черновому протоколу https://www.ietf.org/archive/id/draft-ietf-quic-qmux-01.html . На данный момент оно считается экспериментальным в HAProxy.
quic-cc-algo { cubic | newreno | bbr | nocc }[(<args,...>)]
Это QUIC специфичное настройка для выбора алгоритма контроля перегрузки для любых попыток соединения к настроенным QUIC слушателям. Они аналогичны тем, которые используются в TCP.
Пакетирование активируется поверх алгоритма перегрузки для снижения потерь и повышения пропускной способности. Его можно отключить с помощью глобального ключевого слова “tune.quic.fe.tx.pacing”. В большинстве случаев пакетирование должно оставаться включённым, особенно при использовании BBR, поскольку оно зависит от него для корректной работы. Использование BBR без пакетирования может привести к замедлению или высокой доле потерь при передаче.
Значение по умолчанию: cubic
Для дополнительной настройки можно указать список параметров после токена алгоритма. Он должен быть записан между скобками, разделёнными запятой. Каждый аргумент является необязательным и может быть пустым, если необходимо. Ниже приведён обязательный порядок параметров:
- максимальный размер окна в байтах. Должен превышать 10 кб и быть меньше 4 гб. По умолчанию
“tune.quic.fe.cc.max-win-size” значение используется.
Пример:
Значение «nocc» может быть использовано для принудительного установления окна перегрузки в фиксированном режиме, при котором оно всегда будет равно максимальному размеру. Оно предназначено исключительно для случаев отладки с целью исключения любых побочных эффектов, вызванных контроллером перегрузки. Оно не должно использоваться в производственной среде, поскольку может быстро привести к сетевым проблемам, таким как высокий уровень потерь.
quic-force-retry
Специальный параметр QUIC, принудительно включающий QUIC Retry для всех попыток подключения к настроенным слушателям QUIC. Он проверяет, способны ли удалённые узлы получать пакеты по транспортному адресу, с которого они начали новое соединение: им отправляется пакет Retry с токеном. Токен должен быть возвращён отправителю Retry, поскольку только тот может проверить его. Учтите, что QUIC Retry будет использоваться всегда, даже если задан порог Retry (см. “tune.quic.fe.sec.retry-threshold”).
Для этого параметра должен быть задан секрет кластера, иначе при запуске будет выдана ошибка (см. “cluster-secret”).
Дополнительные сведения о QUIC retry см. в https://www.rfc-editor.org/rfc/rfc9000.html#section-8.1.2 .
quic-socket [ connection | listener ]
Этот QUIC специфический настройка позволяет определить режим распределения сокетов для конкретных слушателей.
См. “tune.quic.fe.sock-per-conn” для полного описания преимуществ и недостатков каждого режима.
Эта настройка применяется в сочетании с глобальным опцией “tune.quic.fe.sock-per-conn”. Если
режим “default-on” активен на глобальном настройке (это значение по умолчанию), каждое соединение QUIC
использует свой собственный сокет, за исключением слушателей с “quic-socket listener”. Однако, если глобальный
режим установлен в “force-off”, настройка отдельных слушателей будет игнорироваться.
severity-output <format>
Этот параметр используется только с сокетами статистики для настройки уровня серьёзности, добавляемого к информационным сообщениям о ответах. Уровень серьёзности сообщений может варьироваться от 0 до 7, в соответствии с rfc5424. Запросы к сокетам, которые успешно требуют данных (например, “show map”, “get acl foo” и т.д.), никогда не получают добавленного уровня серьёзности. Другие сокеты игнорируют этот параметр. <format> может быть одним из следующих:
- “none” (по умолчанию) к сообщениям не добавляется уровень серьёзности.
- “number” уровень серьёзности добавляется как число.
- “string” уровень серьёзности добавляется как строка в соответствии с конвенцией rfc5424.
shards { <number> | by-thread | by-group }
В режиме многопоточности на операционных системах, поддерживающих несколько слушателей на один IP:порт, автоматически создаются такое же количество идентичных слушателей для одной строки, все привязанные к равномерному распределению количества потоков, присоединённых к этому слушателю. Это может быть полезно при использовании очень больших количеств потоков, когда блокировка на уровне ядра для одного сокета начинает вызывать значительную нагрузку. В этом случае входящий трафик распределяется по нескольким сокетам, а конкуренция снижается. Примечание: выполнение этого может легко увеличить использование CPU за счёт того, что больше потоков работают немного.
Если количество шардов превышает количество доступных потоков, оно автоматически будет сокращено до количества потоков (то есть один шард на поток). Специальное значение «by-thread» также создаёт столько шардов, сколько потоков на строке “bind”. Поскольку система равномерно распределяет входящий трафик между всеми этими шардами, важно, чтобы это число было целым делителем количества потоков. Альтернативно, другое специальное значение «by-group» создаёт один шард на группу потоков. Это может быть полезно при работе с большим количеством потоков и желании избежать создания слишком большого числа сокетов. Распределение нагрузки будет немного менее оптимальным, но конкуренция (особенно в системе) всё ещё будет ниже, чем при использовании одного сокета.
На операционных системах, не поддерживающих несколько сокетов, привязанных к одному адресу, «by-thread» и «by-group» автоматически переходят к одному шарду. Для «by-group» это делается без предупреждения, поскольку это не меняет ничего в случае одной группы, и сокеты всё равно будут дублироваться для каждой группы. Однако для «by-thread» при этом будет выдано диагностическое предупреждение, поскольку итоговое количество слушателей не будет соответствовать ожидаемому.
sigalgs <sigalgs>
Этот параметр доступен только тогда, когда поддержка OpenSSL была включена. Он задаёт строку, описывающую список алгоритмов подписи, устанавливаемых во время переговоров TLSv1.2 и TLSv1.3. Формат строки определён в «man 3 SSL_CTX_set1_sigalgs» из справочной документации OpenSSL. Использование этого параметра не рекомендуется, если не требуется совместимость с промежуточным устройством.
ssl
Этот параметр доступен только тогда, когда поддержка OpenSSL была включена. Он включает расшифровку SSL на соединениях, создаваемых из этого слушателя. Необходим сертификат (см. “crt” выше). Все содержимое в буферах будет отображаться в открытом виде, поэтому ACLs и обработка HTTP будут иметь доступ только к расшифрованному содержимому. Поддержка SSLv3 отключена по умолчанию; для включения используйте “ssl-min-ver SSLv3”.
ssl-max-ver [ SSLv3 | TLSv1.0 | TLSv1.1 | TLSv1.2 | TLSv1.3 ]
Этот параметр обеспечивает использование <version> или ниже на соединениях SSL, создаваемых из этого слушателя.
Использование этого настройки без “ssl-min-ver” может быть неясным, поскольку значение по умолчанию ssl-min-ver может измениться в будущих версиях HAProxy. Этот параметр также доступен в глобальном утверждении “ssl-default-bind-options”. См. также “ssl-min-ver”.
ssl-min-ver [ SSLv3 | TLSv1.0 | TLSv1.1 | TLSv1.2 | TLSv1.3 ]
Этот параметр обеспечивает использование <version> или выше на соединениях SSL, создаваемых из этого слушателя.
Значение по умолчанию — “TLSv1.2”. Этот параметр также доступен в глобальном утверждении “ssl-default-bind-options”. См. также “ssl-max-ver”.
strict-sni
Этот параметр доступен только при включённой поддержке OpenSSL. Согласование SSL/TLS разрешено только в том случае, если клиент предоставил SNI, соответствующий сертификату. По умолчанию сертификат не используется. Этот параметр также позволяет запускаться без сертификата на строке bind, поэтому может использоваться пустая директория, которая позже будет заполнена через статический сокет. Этот параметр также доступен в глобальном блоке “ssl-default-bind-options” и может быть отключён по отдельности на строке “bind” с помощью “no-strict-sni”. Дополнительную информацию см. в опции “crt”. См. команду “add ssl crt-list” в руководстве по управлению.
tcp-md5sig <password>
Включает подпись TCP MD5 (RFC 2385 Защита сессий BGP через опцию подписи TCP MD5) для всех входящих соединений, инициированных из этого прослушиваемого сокета. Эта опция доступна только на Linux. При включении используется строка <password> для подписи каждого сегмента TCP с помощью 16-байтового MD5 хэша. Это обеспечивает защиту соединения TCP от фальшивизации. Основное применение этой опции — защита BGP от введения фальшивых сегментов TCP в поток соединения. Однако она может быть полезна для любых очень долговременных соединений TCP.
tcp-ss <mode>
Задаёт параметр TCP Save SYN для всех входящих соединений, создаваемых этим прослушивающим сокетом. Он доступен в Linux начиная с версии 4.3 и предписывает ядру попытаться сохранить копию входящего пакета IP с флагом TCP SYN для последующего анализа через функцию извлечения образцов “fc_saved_syn”. Поддерживаются 3 режима: 0 — сохранение пакета SYN отключено, это значение по умолчанию; 1 — сохранение пакета SYN включено, сохраняются заголовки IP и TCP; 2 — сохранение пакета SYN включено, сохраняются заголовки ETH, IP и TCP.
Это работает только для обычных соединений TCP и игнорируется для других протоколов (например, UNIX сокетов).
См. также “fc_saved_syn”.
tcp-ut <delay>
Устанавливает тайм-аут пользователя TCP для всех входящих соединений, создаваемых из этого слушающего сокета. Опция доступна на Linux с версии 2.6.37. Позволяет HAProxy настроить тайм-аут для сокетов, содержащих данные, не получающие подтверждения в течение заданного периода. Особенно полезна в случае долговременных соединений с длительными периодами бездействия, таких как удалённые терминалы или пулы соединений с базами данных, где тайм-ауты клиента и сервера должны быть высокими, чтобы допускать длительный период бездействия, но при этом важно обнаруживать исчезновение клиента для освобождения всех ресурсов, связанных с его соединением (и сессией сервера). Аргумент — задержка, выраженная в миллисекундах по умолчанию. Работает только для обычных TCP соединений и игнорируется для других протоколов.
tfo
Является опциональным ключевым словом, поддерживающимся только на ядрах Linux >= 3.7. Включает TCP Fast Open на слушающем сокете, что означает, что клиенты, поддерживающие данную функцию, смогут отправлять запрос и получать ответ в ходе 3-стороннего рукопожатия, начиная с второго соединения, тем самым экономя один круг-проход после первого соединения. Это имеет смысл только в протоколах с высокой интенсивностью соединений, где каждый круг-проход имеет значение. Это может привести к проблемам с большинством фильтров, которые не принимают данные в SYN пакетах, поэтому данное опция следует включать только после тщательного тестирования. Данная опция поддерживается только для сокетов TCPv4/TCPv6 и игнорируется для других типов сокетов. Возможно, потребуется собрать HAProxy с USE_TFO=1, если ваша libc не определяет TCP_FASTOPEN.
thread [<thread-group>/]<thread-set>[,...]
Это ограничивает список потоков, на которых разрешено запускать данный слушатель. Оно не обеспечивает выполнение ни одного из них, но исключает те, которые не соответствуют. Оно ограничивает потоки, разрешённые для обработки входящих соединений для данного слушателя.
Существует два схемы нумерации. По умолчанию номера потоков являются абсолютными в процессе и варьируются от 1 до значения, указанного в global.nbthread. Также возможно указать номер потока с помощью его относительного номера внутри группы потоков, указав сначала номер группы потоков, затем слэш (’/’) и относительный номер потока(ов). В этом случае номера потоков также начинаются с 1 и заканчиваются на 32 или 64 в зависимости от платформы. При указании абсолютных номеров потоков они автоматически переводятся в относительные номера после того, как известны группы потоков. Обычно для простых конфигураций предпочтительны абсолютные номера, а для сложных конфигураций, где CPU расстановка имеет значение для производительности, — относительные.
После необязательного номера группы потоков формат спецификации «множества потоков» должен быть следующим:
Как их названия подразумевают, «все» проверяет все потоки в наборе (все потоки группы при наличии группы или все потоки процесса), “odd” проверяет все нечётные потоки (каждый второй поток, начиная с 1) либо для процесса, либо для группы, и “even” проверяет все чётные потоки (каждый второй поток, начиная с 2). Если вместо этого используются диапазоны номеров потоков, то проверяются все потоки, включённые в диапазон от первого до последнего номера потока. Номера могут быть относительными к группе или абсолютными в зависимости от наличия номера группы потоков. Если первый номер потока не указан, используется “1”, представляющий либо первый поток группы, либо первый поток процесса. Если последний номер потока не указан, используется либо последний номер потока группы (32 или 64), либо последний номер потока процесса (global.nbthread).
Такие диапазоны могут повторяться и разделяться запятой, чтобы можно было указывать несмежные наборы потоков, и при этом группа, если она присутствует, должна указываться заново для каждого нового диапазона. Примечание: разрешено не смешивать относительных и абсолютных обозначений, поскольку вся строка “bind” должна использовать либо абсолютную, либо относительную запись, так как неустановленные значения будут разрешены в конце парсинга.
Важно понимать, что каждый слушатель, описанный строкой “bind”, создаёт как минимум один сокет, представленный как минимум одним файловым описателем. Поскольку файловые описатели не могут охватывать несколько групп потоков, если строка “bind” указывает диапазон потоков, охватывающий более одной группы, автоматически создаются несколько файловых описателей, чтобы для каждой группы был хотя бы один. Технически все они ссылаются на один и тот же сокет в ядре, но они получат отдельный идентификатор в HAProxy и даже будут иметь отдельную запись в статистике, если используется “option socket-stats”.
Основная цель — иметь несколько строк bind, использующих одинаковый IP:порт, но разные потоки в слушателе, чтобы система могла распределять входящие соединения по нескольким очередям, обходя внутреннюю балансировку нагрузки очередей HAProxy. В настоящее время поддержка такой конфигурации известна для Linux 3.9 и выше. См. также ключевое слово “shards”, описанное выше, которое автоматически дублирует строки “bind” и присваивает их нескольким группам потоков.
Этот ключевое слово совместим с обратными HTTP привязками. Однако запрещено указывать набор потоков, охватывающий несколько групп потоков для такого слушателя, поскольку это может привести к тому, что “nbconn” не работает как задумано.
tls-tickets
Этот параметр доступен только тогда, когда поддержка OpenSSL была включена. Он включает механизм Stateless session resumption (RFC 5077 TLS Ticket extension). Он является стандартным, но может потребоваться для целенаправленного включения этой функции на строке “bind”, если она была глобально отключена через “no-tls-tickets”, упомянутую в “ssl-default-bind-options”. См. также параметр bind “no-tls-tickets”.
tls-ticket-keys <keyfile>
Устанавливает файл ключей TLS для загрузки ключей. Ключи должны быть длиной 48 или 80 байт,
в зависимости от того, используется aes128 или aes256, закодированные с помощью base64, один ключ на строку (например, OpenSSL rand 80 | OpenSSL base64 -A | xargs echo). Первый ключ определяет длину ключа, используемую для последующих ключей: нельзя смешивать ключи aes128 и aes256. Количество ключей задаётся опцией сборки TLS_TICKETS_NO (по умолчанию 3) и в файле должно быть не менее такого количества ключей. Последние TLS_TICKETS_NO ключей будут использоваться для дешифровки, а предпоследний — для шифрования. Это позволяет легко выполнять вращение ключей, просто добавляя новые ключи в файл и перезагружая процесс. Ключи должны периодически вращаться (например, каждые 12h), иначе нарушается совершенная передача секретности. Также рекомендуется хранить ключи вне любых постоянных носителей, таких как жесткие диски (см. подсказку: использовать tmpfs и не использовать обменные файлы). Срок службы может быть изменён с помощью tune.ssl.timeout.
transparent
Является опциональным ключевым словом, поддерживающимся только на определённых версиях ядра Linux. Оно указывает на то, что адреса будут привязаны даже в случае, если они не принадлежат локальной машине, и пакеты, направляемые к этим адресам, будут перехвачены так же, как если бы эти адреса были настроены локально. Обычно требуется включение пересылки IP-пакетов. Внимание! не используйте это в сочетании с стандартным адресом ‘*’, иначе произойдёт перенаправление всего трафика на указанном порту. Это ключевое слово доступно только при сборке HAProxy с USE_LINUX_TPROXY=1. Этот параметр совместим только с сокетами TCPv4 и TCPv6, в зависимости от версии ядра. Некоторые дистрибутивы ядер включают бэкпорт данной функции, поэтому проверьте поддержку у поставщика.
uid <uid>
Устанавливает владельца сокетов UNIX в указанный идентификатор пользователя системы. Этот параметр также может быть задан по умолчанию в утверждении секции “unix-bind” глобальной секции. Примечание: на некоторых платформах этот параметр игнорируется. Этот параметр эквивалентен параметру “user”, за исключением того, что используется числовое значение идентификатора пользователя вместо его имени. Этот параметр игнорируется для не UNIX сокетов.
user <user>
Устанавливает владельца сокетов UNIX для указанного системного пользователя. Этот параметр также может быть задан по умолчанию в утверждении секции глобальной “unix-bind”. Примечание: на некоторых платформах этот параметр просто игнорируется. Этот параметр эквивалентен настройке “uid”, за исключением того, что используется имя пользователя вместо его идентификатора. Этот параметр игнорируется для не UNIX сокетов.
v4v6
Является опциональным ключевым словом, поддерживающимся только на наиболее новых системах, включая ядра Linux >=
2.4.21. Используется для привязки сокета к как IPv4, так и к IPv6 при использовании стандартного адреса. Такая настройка иногда необходима на системах, которые по умолчанию привязываются только к IPv6. Не оказывает влияния на сокеты, не относящиеся к IPv6, и подавляется опцией “v6only”.
v6only
Является опциональным ключевым словом, поддерживающимся только на последних системах, включая ядра Linux >=
2.4.21. Используется для привязки сокета к IPv6 только в случае использования адреса по умолчанию. Такое действие иногда предпочтительнее выполнения системно в целом, поскольку оно действует на уровне слушателя. Не влияет на сокеты, не относящиеся к IPv6, и имеет приоритет перед опцией “v4v6”.
verify [none|optional|required]
Этот параметр доступен только тогда, когда поддержка OpenSSL была включена. Если установлено значение ’none’, запрос сертификата клиента не требует. Это значение по умолчанию. В остальных случаях требуется сертификат клиента. Если клиент не предоставляет сертификат после запроса и если ‘verify’ установлено в ‘required’, то рукопожатие прерывается, в то время как оно успешно завершится, если значение установлено в ‘optional’. Сертификат, предоставляемый клиентом, всегда проверяется с помощью ЦА из ‘ca-file’ и опциональных CRL из ‘crl-file’. При неудаче проверки рукопожатие прерывается независимо от значения ‘verify’, если ошибка не соответствует ни одному из кодов ошибок, перечисленных в ‘ca-ignore-err’ или ‘crt-ignore-err’.
5.2. Параметры server и default-server
Ключевые слова “server” и “default-server” поддерживают определённое количество настроек, которые передаются как аргументы на строке сервера. Порядок, в котором эти аргументы приводятся, не имеет значения, и они все являются необязательными. Некоторые из этих настроек — одиночные слова (логические значения), в то время как другие ожидает один или несколько значений после них. В этом случае значения должны сразу следовать за названием настройки. В случае использования всех настроек, кроме default-server, они должны быть указаны после адреса сервера:
Примечание: все эти настройки поддерживаются как для “server”, так и для “default-server”, за исключением “id”, который поддерживается только для “server”.
На данный момент поддерживаются следующие настройки.
addr <ipv4|ipv6>
Допустимые контексты: tcp, http, log
Используя параметр “addr”, становится возможным отправку проверок работоспособности или пробы на agent-check с другого IP-адреса. На некоторых серверах может быть желательно выделить IP-адрес для конкретного компонента, способного выполнять сложные тесты, более подходящие для проверок работоспособности, чем приложение. Параметр игнорируется, если параметр “check” не задан. См. также параметр “port”.
agent-check
Допустимые контексты: tcp, http, log
Включить проверку работоспособности вспомогательного агента, выполняемую независимо от обычной проверки работоспособности. Проверка работоспособности агента осуществляется путём установления соединения TCP на порт, заданный параметром “agent-port”, и чтения строки ASCII, завершающейся первым вхождением ‘\r’ или ‘\n’. Строка состоит из ряда слов, разделённых пробелами, табуляциями или запятыми в любом порядке, каждое из которых состоит из:
Представление ASCII положительного целого процента, например, “75%”. Значения в этом формате будут
устанавливать вес пропорционально начальному весу сервера, заданному при запуске HAProxy.
Примечание: нулевой вес отображается на странице статистики как “DRAIN”, поскольку он оказывает одинаковое влияние на сервер (сервер удаляется из группы балансировки). Это устаревший способ установки веса сервера.
Рекомендуется использовать установку с префиксом “weight:”.Строка “weight:” за которой следует положительное целое число или положительное целое число в процентах, без пробела. Если значение заканчивается знаком ‘%’, то новый вес будет пропорционален первоначальному весу сервера. В противном случае значение считается абсолютным весом и должно находиться в диапазоне 0 до 256. Серверы, входящие в ферму, работающую по статическому алгоритму балансировки нагрузки, имеют более жесткие ограничения, поскольку вес не может изменяться после установки. Таким образом, для этих серверов допускаются только значения 0 и 100% (или 0 и первоначальный вес). Изменения вступают в силу немедленно, хотя некоторые алгоритмы балансировки нагрузки требуют определённого количества запросов, чтобы учесть изменения. Примечание: нулевой вес отображается на странице статистики как “DRAIN”, поскольку он оказывает такое же влияние на сервер (сервер удаляется из фермы балансировки нагрузки).
Строка “maxconn:” за которой следует целое число (без пробела). Значения в таком формате устанавливают
параметр maxconn сервера. Максимальное количество соединений, объявленное в этом параметре, должно быть умножено на
количество балансировщиков нагрузки и различных бэкендов, использующих эту проверку работоспособности, чтобы получить
общее количество соединений, которое может получить сервер. Пример: maxconn:30Слово “ready”. Это изменит административное состояние сервера на режим READY, тем самым
отменяя любые состояния DRAIN или MAINTСлово “drain”. Это изменит административное состояние сервера на режим DRAIN, тем самым
он не будет принимать новые соединения, кроме тех, которые принимаются через сохранение соединения.Слово “maint”. Это установит административное состояние сервера в режиме MAINT, таким образом, он не будет принимать никакие новые соединения, и проверки работоспособности будут остановлены.
Слова “down”, “fail” или “stopped”, опционально сопровождаемые описательной строкой после знака решетки (’#’). Все эти слова указывают на состояние работы сервера как DOWN, но поскольку само слово отображается на странице статистики, различие позволяет администратору понять, было ли это ожидаемым или нет: сервис может быть намеренно остановлен, может быть в состоянии “up”, но не проходить некоторые проверки работоспособности, или может быть отмечен как “down” (например, отсутствует процесс, или порт не отвечает).
Слово “up” устанавливает состояние работы сервера как UP, если проверки работоспособности также сообщают, что сервис доступен.
Параметры, которые не объявляются агентом, не изменяются. Например, агент может быть спроектирован для мониторинга CPU и отчётности только о относительном весе, не взаимодействуя с состоянием работы. Аналогично, агент может быть спроектирован как интерфейс для конечного пользователя с 3 кнопками радио, позволяющими администратору изменять только административное состояние. Однако важно учитывать, что только сам агент может отменить свои действия, поэтому если сервер установлен в режим DRAIN или в состояние DOWN с помощью агента, то агент должен реализовать другие эквивалентные действия для возврата сервиса в рабочее состояние.
Невозможность подключения к агенту не считается ошибкой, поскольку подключение проверяется через регулярную проверку работоспособности, включаемую с помощью параметра “check”. Предупреждение: не рекомендуется останавливать агент после того, как он сообщает «down», поскольку только агент, отчётно сообщающий «up», сможет включить сервер. Примечание: CLI на Unix-сокете статистики также может принудительно установить результат агента для обхода ошибочного агента, если это необходимо.
Требуется установить параметр “agent-port”. См. также параметры “agent-inter” и “no-agent-check”.
agent-send <string>
Допустимые контексты: tcp, http, log
Если указано это опция, HAProxy отправит заданную строку (без изменений) агенту серверу при соединении. Например, можно закодировать имя бэкенда в эту строку, что позволит агенту отправлять разные ответы в зависимости от бэкенда. Убедитесь, что включена строка ‘\n’, если вы хотите завершить запрос символом переноса строки.
agent-inter <delay>
Допустимые контексты: tcp, http, log
Параметр “agent-inter” задаёт интервал между двумя проверками агента в <delay> миллисекунд. Если параметр не указан, задержка по умолчанию равна 2000 ms.
Так же, как и для любого другого параметра, зависящего от времени, значение может быть указано в любой из явных единиц: { us, ms, s, m, h, d }. Параметр “agent-inter” также служит тайм-аутом для проверок работоспособности агента, если “timeout check” не задан. Чтобы снизить эффекты «резонанса» при размещении нескольких серверов на одном оборудовании, запуск агентов и проверок работоспособности всех серверов производится с небольшим временным сдвигом между ними. Также возможно добавить некоторую случайную погрешность в интервалы агентов и проверок работоспособности с помощью глобального параметра “spread-checks”. Это имеет смысл, например, когда большое количество бэкендов использует одни и те же серверы.
См. также параметры “agent-check” и “agent-port”.
agent-addr <addr>
Допустимые контексты: tcp, http, log
Параметр “agent-addr” задаёт адрес проверки агента.
Вы можете передать agent-check на другой целевой узел, чтобы обеспечить централизованное управление статусом и весами серверов, заданных в HAProxy, в случае, если невозможно реализовать самоосознаваемые и самоуправляющие сервисы. Вы можете указать как IP-адрес, так и имя хоста, оно будет разрешено.
agent-port <port>
Допустимые контексты: tcp, http, log
Параметр “agent-port” задаёт порт TCP, используемый для проверок агента.
См. также параметры “agent-check” и “agent-inter”.
allow-0rtt
Может быть использован в следующих контекстах: tcp, http, log, peers, ring
Разрешает отправку ранних данных серверу при использовании TLS 1.3. Примечание: ранние данные будут отправлены только если клиент использовал ранние данные, или если бэкенд использует “retry-on” с ключевым словом “0rtt-rejected”. С QUIC, 0rtt поддерживается с QuicTLS, OpenSSL >= 3.5.2 и AWS-LC. С TCP/TLS, 0rtt поддерживается только с OpenSSL.
alpn <protocols>
Допустимые контексты: tcp, http
Это включает расширение TLS ALPN и объявляет указанный список протоколов как поддерживаемый в дополнение к ALPN. Список протоколов состоит из запятой-разделённого списка названий протоколов, например:
“http/1.1,http/1.0” (без кавычек). Это требует, чтобы библиотека SSL была собрана с включённой поддержкой
расширений TLS (проверьте с помощью haproxy -vv). Расширение ALPN заменяет первоначальное расширение NPN. Расширение ALPN необходимо для подключения к серверам HTTP/2. Оно также необходимо для использования HTTP/3 через сервер QUIC. Значение по умолчанию для серверов QUIC без настройки “alpn” — “h3”. Версии OpenSSL до 1.0.2 не поддерживали ALPN и использовали теперь устаревшее расширение NPN. Если ожидается поддержка как HTTP/2, так и HTTP/1.1, оба варианта могут быть объявлены в порядке предпочтения, как указано ниже:
См. также “ws” для использования альтернативного ALPN для потоков WebSocket.
backup
Допустимые контексты: tcp, http, log
Когда на строке сервера присутствует “backup”, сервер используется только при балансировке нагрузки, если все остальные серверы, не являющиеся резервными копиями, недоступны. Запросы, поступающие с cookie-памятью, указывающей на этот сервер, будут всегда обслуживаться. По умолчанию используется только первый работающий сервер-резервная копия, если в бэкенде не установлен параметр “allbackups”. См. также параметры “no-backup” и “allbackups”.
ca-file <cafile>
Может использоваться в следующих контекстах: tcp, http, log, peers, ring
Этот параметр доступен только тогда, когда в HAProxy включена поддержка OpenSSL. Он указывает на файл PEM из которого загружаются сертификаты CA, используемые для проверки сертификата сервера. Возможна загрузка каталога, содержащего несколько CA, в этом случае HAProxy попытается загрузить каждый “.pem”, “.crt”, “.cer” и .crl, доступный в каталоге, файлы, начинающиеся с точки, игнорируются.
Чтобы использовать доверенные CA вашей системы, параметр “@system-ca” может быть использован вместо cafile. Путь к этому каталогу может быть перезаписан с помощью установки переменной среды SSL_CERT_DIR.
cc <algo>
Может использоваться в следующих контекстах: tcp, http, log, одноранговые узлы, ring
Этот параметр доступен только на системах, которые определяют TCP_CONGESTION, и был протестирован на Linux и FreeBSD. Он принимает имя алгоритма управления перегрузкой TCP и настраивает исходящие соединения на использование этого алгоритма. Типичные имена включают “reno” или “cubic” и зависят от операционной системы. На некоторых системах для настройки определённых алгоритмов могут потребоваться специальные разрешения. На Linux доступные алгоритмы перечислены в sysctl “net.ipv4.tcp_available_congestion_control”, а разрешённые без прав доступа — в “net.ipv4.tcp_allowed_congestion_control”. Для доступа к алгоритмам, требующим дополнительных разрешений, может потребоваться возможность “cap_net_admin” (см. “setcap” в глобальной секции). В случае неудачи при настройке конкретного алгоритма управления перегрузкой используется алгоритм по умолчанию. См. также: ключевое слово bind “cc” ( секция 5.1 ).
check
Допустимые контексты: tcp, http, log
Этот параметр включает проверку работоспособности сервера: — при отсутствии настройки проверка работоспособности не выполняется, и сервер считается всегда доступным. — при наличии настройки и отсутствии других методов проверки работоспособности, сервер считается доступным, если на наивысшем настроенным уровне транспортного слоя удалось установить соединение. Это означает TCP по умолчанию, или SSL/TLS при настройке “ssl” или “check-ssl”, оба возможных в сочетании с префиксами соединения, такими как заголовок протокола PROXY при настройке “send-proxy” или “check-send-proxy”. Это поведение немного отличается для динамических серверов, см. следующие абзацы для дополнительной информации. — при наличии настройки и определении проверки работоспособности на уровне приложения, обмены на уровне приложения выполняются на основе настроенного уровня транспортного слоя, и сервер считается доступным, если все обмены успешно завершились.
По умолчанию проверки работоспособности выполняются на том же адресе и порту, что настроено для сервера, используя те же параметры оболочки (SSL/TLS, заголовок прокси-протокола и т.д.). Возможность изменить адрес назначения с помощью “addr” и порт с помощью “port”. При этом предполагается, что сервер не проверяется на порту сервиса, и настроенные параметры оболочки не повторяются. Обязательно нужно явно установить “check-send-proxy” для отправки заголовков соединения, “check-ssl” для использования SSL/TLS.
Примечание: не выполняется скрытая конфигурация ssl и протокола PROXY для динамических серверов.
В этом случае требуется явно использовать “check-ssl” и “check-send-proxy” при необходимости, даже
если порт проверки не переопределён.
Когда “sni” или “alpn” заданы на строке сервера, их значение не используется для проверки работоспособности и необходимо использовать “check-sni” или “check-alpn”.
По умолчанию адрес источника для трафика проверки работоспособности совпадает с тем, который определён в бэкенде.
Он может быть изменён с помощью ключевого слова “source”.
Интервал между проверками можно задать с помощью ключевого слова “inter”, а ключевые слова “rise” и “fall” могут быть использованы для определения количества успешных или неудачных проверок работоспособности, необходимых для обозначения сервера как доступного или недоступного.
Опциональные проверки работоспособности на уровне приложения могут быть настроены с помощью “option httpchk”, “option mysql-check” “option smtpchk”, “option pgsql-check”, “option ldap-check”, или “option redis-check”.
Пример:
check-reuse-pool
Допустимые контексты: tcp, http
Этот параметр позволяет проверкам использовать свободные соединения, если они доступны, вместо открытия отдельного соединения. Соединение возвращается в пул после завершения проверки. Основная цель — ограничить количество открытия и закрытия соединений на конкретном сервере. Эта функция совместима только с http-check правилами. Для других типов проверок она игнорируется без уведомления. Кроме того, политика повторного использования должна быть установлена на агрессивную на бэкенде, поскольку каждая попытка проверки выполняется через отдельную сессию.
Для упрощения конфигурации этот параметр игнорируется без уведомления, если определён какой-либо конкретный параметр подключения проверки, либо на строке сервера, либо через пользовательскую tcp-check правило подключения.
Этот параметр автоматически включается для серверов, работающих в качестве пассивного обратного HTTP гейтвей, поскольку для таких серверов подключение поддерживается только через переиспользование.
См. также: “check-pool-conn-name”
check-send-proxy
Допустимые контексты: tcp, http
Этот параметр заставляет генерировать строку протокола PROXY при исходных проверках работоспособности, независимо от того, использует ли сервер send-proxy для обычного трафика. По умолчанию, протокол PROXY включается для проверок работоспособности, если он уже включен для обычного трафика, и если отсутствуют директивы “port” и “addr”. Однако, если такие директивы присутствуют, для принудительного использования протокола необходимо использовать параметр “check-send-proxy”. Дополнительную информацию см. в отношении параметра “send-proxy”.
check-alpn <protocols>
Допустимые контексты: tcp, http
Определяет, какие протоколы следует рекламировать с помощью ALPN. Список протоколов состоит из запятой-разделённого списка названий протоколов, например: “http/1.1,http/1.0” (без кавычек). Если этот параметр не задан, используется сервер ALPN.
check-pool-conn-name <name>
Допустимые контексты: tcp, http
При использовании переработки соединений для проверок, применяется <name> как идентификатор соединения для соответствующего соединения в пуле. Это служит эквивалентом ключевого слова “pool-conn-name” сервер. “check-sni” также будет использоваться как резервный вариант, если текущий параметр не применяется.
См. также: “check-reuse-pool”
check-proto <name>
Допустимые контексты: tcp, http
Обязательно требует, чтобы мультиплексер использовал определённый протокол для соединений проверки работоспособности сервера. Он должен быть совместим с типом проверки работоспособности (TCP или HTTP). Он также должен быть применим на стороне бэкенда. Список доступных протоколов приведён в haproxy -vv. Свойства протоколов приведены: режим (TCP/HTTP), сторона (FE/BE), имя мультиплексера и его флаги.
Некоторые протоколы подвержены блокировке на уровне головы потока на стороне сервера (флаг=HOL_RISK). В конечном итоге некоторые протоколы не поддерживают обновления (флаг=NO_UPG). Также отображается совместимость HTX (флаг=HTX).
Здесь приведены протоколы, которые могут быть использованы в качестве аргумента директивы “check-proto” на строке сервера:
Понятие за счёт этого параметра — обойти выбор оптимального протокола мультиплексера для соединений проверки работоспособности, установленных к этому серверу. Если не задано, используется протокол сервера, если задан.
Если настроены параметры ALPN или NPN, указанные протоколы должны быть совместимы с протоколом мультиплексера, чтобы избежать проблем. Например, если задан “proto h1”, то ALPN не должен быть установлен в значение “h2”.
Настройка проверки работоспособности QUIC пока не полностью реализована. Во-первых, проверки QUIC могут выполняться только для серверов QUIC. Во-вторых, если указаны специфические параметры соединения для проверки на сервере QUIC, протокол проверки перейдёт к использованию TCP.
check-sni-auto
Допустимые контексты: tcp, http, log
Этот параметр включает автоматический выбор SNI при проверке работоспособности серверов через SSL, если значение не было задано ранее. Параметр включён по умолчанию, но может быть использован как “server” для сброса любого значения “no-check-sni-auto”, наследуемого из директивы “default-server” как значение по умолчанию. Он также может быть использован как “default-server” для сброса любого предыдущего значения “default-server” “no-check-sni-auto”.
Для HTTPS соединений, заголовок SNI автоматически выбирается, но только в случае отсутствия правила “http-check connect”. В этом случае, выбранный заголовок SNI определяется на основе значения заголовка хоста, указанного через директиву “option httpchk” или правило “http-check send”. Автоматическое выбора для правил “http-check connect” нет. Для других протоколов опция игнорируется.
Если используется автоматическое определение SNI для проверки работоспособности, то значение присваивается имени соединения, если установлено настройка “check-reuse-pool”, за исключением случая, когда оно перекрывается ключевым словом сервера “check-pool-conn-name”.
См. опцию “sni-auto” для включения автоматического выбора SNI для прокси-трафика.
check-sni <sni>
Допустимые контексты: tcp, http, log
Этот параметр позволяет указать SNI, используемый при проверке работоспособности через SSL. Возможна только строка для задания <sni>. Если необходимо задать SNI для проксированных потоков, см. “sni”.
check-ssl
Допустимые контексты: tcp, http, log
Этот параметр обеспечивает шифрование всех проверок работоспособности через SSL, независимо от того, использует ли сервер SSL для обычного трафика. Обычно этот параметр применяется тогда, когда указано явное “port” или “addr”, а проверки работоспособности через SSL не наследуются. Важно понимать, что данный параметр вставляет слой SSL на транспортном уровне ниже проверок, таким образом, простая проверка TCP соединения превращается в проверку SSL соединения, которая заменяет старую проверку ssl-hello-chk. Наиболее распространённый случай — отправка проверок HTTPS путём объединения проверок “httpchk” и SSL. Все настройки SSL распространяются на проверки работоспособности и трафик (например, шифры). См. параметр “ssl” для дополнительной информации и “no-check-ssl” для отключения этого параметра.
check-via-socks4
Допустимые контексты: tcp, http, log
Этот параметр включает исходящие проверки работоспособности с использованием прокси upstream socks4. По умолчанию проверки работоспособности не проходят через туннель socks, даже если такой туннель включен для обычного трафика.
ciphers <ciphers>
Может использоваться в следующих контекстах: tcp, http, log, peers, ring
Этот параметр доступен только тогда, когда встроенная поддержка OpenSSL. Этот параметр задаёт строку, описывающую список алгоритмов шифрования, устанавливаемых во время SSL/TLS-обмена с сервером. Формат строки определён в документации “man 1 ciphers” от OpenSSL. Для дополнительной информации и рекомендаций см. например,
(https://wiki.mozilla.org/Security/Server_Side_TLS
) и
(https://mozilla.github.io/server-side-tls/ssl-config-generator/
). Для настройки шифрования TLSv1.3 см. параметр “ciphersuites”.
ciphersuites <ciphersuites>
Может использоваться в следующих контекстах: tcp, http, log, peers, ring
Этот параметр доступен только при сборке с поддержкой OpenSSL и использовании OpenSSL 1.1.1 или более поздней версии для сборки HAProxy. Этот параметр задаёт строку, описывающую список алгоритмов шифрования, согласуемых во время TLS 1.3 рукопожатия с сервером. Формат строки определён в разделе “ciphersuites” документации OpenSSL, доступной по команде “man 1 ciphers”. Для настройки шифров TLSv1.2 и ранее обратитесь к ключевому слову “ciphers”.
client-sigalgs <sigalgs>
Может использоваться в следующих контекстах: tcp, http, log, peers, ring
Этот параметр доступен только тогда, когда встроенная поддержка OpenSSL. Устанавливает строку, описывающую список алгоритмов подписи, связанных с аутентификацией клиента, которые согласовываются. Формат строки определён в “man 3 SSL_CTX_set1_client_sigalgs” из страниц справки OpenSSL. Не рекомендуется использовать этот параметр, если не определён конкретный сценарий использования.
cookie <value>
Допустимые контексты: http
Параметр “cookie” устанавливает значение куки, присваиваемое серверу, в <value>. Это значение будет проверяться в входящих запросах, и первый рабочий сервер, обладающий таким же значением, будет выбран. В ответ, в режимах вставки или переписывания куки, это значение будет присваиваться куки, отправляемой клиенту. Нет ничего неправильного в том, чтобы несколько серверов делили одно и то же значение куки, и это, в действительности, довольно распространено между обычными и резервными серверами. См. также ключевое слово “cookie” в секции бэкенда.
crl-file <crlfile>
Может использоваться в следующих контекстах: tcp, http, log, peers, ring
Этот параметр доступен только тогда, когда встроенная поддержка OpenSSL. Он обозначает файл PEM из которого загружается список отозванных сертификатов, используемый для проверки сертификата сервера.
crt <cert>
Может использоваться в следующих контекстах: tcp, http, log, peers, ring
Этот параметр доступен только тогда, когда встроенная поддержка OpenSSL. Он указывает на файл PEM из которого необходимо загружать как сертификат, так и соответствующий приватный ключ. Такой файл может быть создан путем конкатенации двух файлов PEM. Данный сертификат будет отправлен, если сервер запрашивает сертификат клиента.
Если файл не содержит приватного ключа, HAProxy попытается загрузить ключ по тому же пути, но с суффиксом “.key” (при условии, что опция “ssl-load-extra-files” установлена соответствующим образом).
curves <curves>
Может использоваться в следующих контекстах: tcp, http, log, одноранговые узлы, ring
Этот параметр доступен только тогда, когда встроенная поддержка OpenSSL. Устанавливает строку, описывающую список алгоритмов эллиптических кривых (“набор кривых”), которые устанавливаются во время SSL/TLS handshake с ECDHE. Формат строки — это список названий кривых, разделённых двоеточием. Пример: “X25519:P-256” (без кавычек)
disabled
Допустимые контексты: tcp, http, log
Ключевое слово “disabled” запускает сервер в состоянии “disabled”. Это означает, что сервер отмечен как выключенный в режиме технического обслуживания, и никакое соединение, кроме тех, которые разрешены режимом persist, не достигнет его. Оно очень хорошо подходит для настройки новых серверов, поскольку обычный трафик никогда не достигнет их, при этом возможно тестирование сервиса с использованием механизма force-persist. См. также настройку “enabled”.
enabled
Допустимые контексты: tcp, http, log
Этот параметр может быть использован как ‘server’ настройка для сброса любой ‘disabled’ настройки, которая была наследована из ‘default-server’ директивы как значение по умолчанию. Он также может быть использован как ‘default-server’ настройка для сброса любой предыдущей ‘default-server’ ‘disabled’ настройки.
error-limit <count>
Допустимые контексты: tcp, http, log
Если включена проверка состояния здоровья, параметр “error-limit” указывает количество последовательных ошибок, которое инициирует событие, выбранное опцией “on-error”. По умолчанию он установлен на 10 последовательных ошибок.
См. также “check”, “error-limit” и “on-error”.
fall <count>
Допустимые контексты: tcp, http, log
Параметр “fall” устанавливает, что сервер считается неисправным после <count> последовательных неудачных проверок работоспособности. Значение по умолчанию для этого параметра равно 3, если параметр не указан. См. также параметры “check”, “inter” и “rise”.
force-sslv3
Может использоваться в следующих контекстах: tcp, http, log, peers, ring
Этот параметр обеспечивает использование только SSLv3 при SSL для связи с сервером. SSLv3 в целом менее затратен, чем соответствующие TLS при высокой интенсивности соединений. Этот параметр также доступен на глобальном утверждении “ssl-default-server-options”. См. также “ssl-min-ver” и ssl-max-ver.
force-tlsv10
Может использоваться в следующих контекстах: tcp, http, log, одноранговые узлы, ring
Этот параметр обеспечивает использование TLSv1.0 только при использовании SSL для связи с сервером. Этот параметр также доступен на глобальном утверждении “ssl-default-server-options”. См. также “ssl-min-ver” и ssl-max-ver.
force-tlsv11
Может использоваться в следующих контекстах: tcp, http, log, одноранговые узлы, ring
Этот параметр обеспечивает использование TLSv1.1 только при использовании SSL для связи с сервером. Этот параметр также доступен на глобальном утверждении “ssl-default-server-options”. См. также “ssl-min-ver” и ssl-max-ver.
force-tlsv12
Может использоваться в следующих контекстах: tcp, http, log, одноранговые узлы, ring
Этот параметр обеспечивает использование TLSv1.2 только при использовании SSL для связи с сервером. Этот параметр также доступен на глобальном утверждении “ssl-default-server-options”. См. также “ssl-min-ver” и ssl-max-ver.
force-tlsv13
Может использоваться в следующих контекстах: tcp, http, log, одноранговые узлы, ring
Этот параметр обеспечивает использование TLSv1.3 только при использовании SSL для связи с сервером. Этот параметр также доступен на глобальном утверждении “ssl-default-server-options”. См. также “ssl-min-ver” и ssl-max-ver.
guid <string>
Допустимые контексты: tcp, http, log
Укажите регистрозависимый уникальный идентификатор для этого сервера. Этот идентификатор должен быть уникальным во всей конфигурации HAProxy на всех типах объектов. См. описание ключевого слова “guid” прокси для получения дополнительной информации о его формате. См. также “shm-stats-file”.
hash-key <key>
Допустимые контексты: tcp, http, log
Укажите, как вычисляются ключи узла “hash-type consistent”
Аргументы:
Опции “addr” и “addr-port” могут быть полезны в сценариях, когда несколько процессов HAProxy распределяют трафик между одним и тем же набором серверов. Если порядок серверов в каждом процессе отличается (например, из-за того, что DNS записи были разрешены в различных порядках), то это позволит независимым процессам HAProxy согласовывать решения по маршрутизации. Примечание: “balance random” также использует “hash-type consistent”, и качество распределения будет зависеть от качества ключей.
healthcheck <name>
Допустимые контексты: tcp, http
Укажите секцию проверки работоспособности для проверки сервера.
Аргумент:
Благодаря этому параметру возможно использовать конфигурацию предварительной проверки работоспособности сервера вместо использования конфигурации прокси. См. также “секция проверки работоспособности”.
id <value>
Допустимые контексты: tcp, http, log
Установите постоянный идентификатор для сервера. Этот идентификатор должен быть положительным числом из 32 бит и уникальным для прокси. Если идентификатор не задан, будет автоматически назначено свободное значение. Первое назначаемое значение будет 1. Этот идентификатор в настоящее время возвращается только в статистике и используется для размещения узлов балансировки нагрузки при использовании алгоритмов консистентного хэша, когда “hash-key” установлен в “id” (по умолчанию). В этом случае используются только 28 наименьших бит значений (то есть (id % 268435356)), поэтому лучше использовать значения, включенные в диапазон от 1 до этого значения, чтобы избежать пересечения.
idle-ping <delay>
Допустимые контексты: tcp, http, log
Определите интервал для периодической проверки живучести на пассивных соединениях бэкенда. Если одноранговый узел не может ответить до следующего запланированного теста, соединение закрывается. Данное ключевое слово относится к бэкенду, поэтому оно полезно для проверки того, что пассивные соединения остаются работоспособными. Примечание: это не предотвратит разрушение соединения при очистке пула пассивных соединений.
Эта функция зависит от поддержки определённого базового протокола. На данный момент реализована только для H2 mux.
Проверка на пустоту игнорируется другими протоколами.
Этот параметр особенно полезен при использовании обратного HTTP. Установка его на строке сервера полезна для однорангового узла, который ожидает входящие соединения и присоединяет их к соответствующему серверу, чтобы позже использовать для пересылки трафика.
init-addr {last | libc | none | <ip>},[...]*
Допустимые контексты: tcp, http, log
Укажите порядок разрешения адреса сервера при запуске, если он использует FQDN.
При попытке разрешения адреса применяются по очереди все методы, перечисленные в списке, разделённом запятыми. Первый метод, который успешно работает, используется. Если конец списка достигнут без нахождения рабочего метода, генерируется ошибка. Метод “last” означает выбор адреса, присутствующего в файле состояния (см. “server-state-file”). Метод “libc” использует внутренний разрешитель libc (gethostbyname() или getaddrinfo() в зависимости от операционной системы и опций сборки). Метод “none” явно указывает на то, что сервер должен запускаться без действительного IP-адреса в состоянии down. Это может быть полезно для игнорирования некоторых DNS проблем при запуске, ожидая, пока ситуация будет исправлена позже. Наконец, может быть указан IP-адрес (IPv4 или IPv6). Он может быть текущим известным адресом сервера (например, заполненным конфигурационным генератором) или адресом виртуального сервера, используемого для перехвата старых сессий и предоставления при этом уместного сообщения об ошибке. При использовании алгоритма балансировки нагрузки “first” такой IP-адрес может указывать на фейковый сервер, используемый для запуска новых экземпляров на лету. Эта опция по умолчанию равна “last,libc”, что означает, что сначала используется предыдущий адрес из файла состояния (если он есть), иначе используется разрешитель libc. Это обеспечивает совместимость с историческим поведением. При использовании внутренних разрешителей рекомендуется либо отключать разрешение на основе libc, либо делать это явно (см. секцию 5.3
для дополнительной информации).
Пример 1:
Пример 2:
inter <delay>
Допустимые контексты: tcp, http, log
Параметр “inter” устанавливает интервал между двумя последовательными проверками работоспособности в <delay> миллисекунд. Если не указан, задержка по умолчанию равна 2000 ms. Также возможно использовать «fastinter» и «downinter» для оптимизации задержек между проверками в зависимости от состояния сервера:
Так же, как и для всех других параметров, зависящих от времени, они могут быть указаны в любой из явных единиц: { us, ms, s, m, h, d }. Параметр “inter” также служит тайм-аутом для проверок работоспособности, отправляемых серверам, если “timeout check” не задан. Чтобы снизить эффект “резонанса” при размещении нескольких серверов на одном оборудовании, запуск агента и проверок работоспособности всех серверов производится с небольшим временным смещением между ними. Также возможно добавить некоторое случайное отклонение в интервалы агента и проверок работоспособности с помощью глобального параметра “spread-checks”. Это имеет смысл, например, когда большое количество бэкендов использует одни и те же серверы. Глобальный параметр “tune.max-checks-per-thread”, если задан с ненулевым значением, ограничивает количество одновременно выполняемых проверок на любом из потоков. Для достижения этого HAProxy помещает в очередь проверки, которые планировались начать на потоке, достигшем этого предела, до тех пор, пока не завершится другая проверка. Это приведёт к увеличению эффективного интервала проверок. В таком случае сокращение параметра “inter” будет иметь очень ограниченное влияние, поскольку не сможет сократить время, затрачиваемое на ожидание в очереди.
init-state { fully-up | up | down | fully-down | none }
Допустимые контексты: tcp, http
Допустимые секции: defaults | frontend | listen | backend нет | нет | да | да
Опция “init-state” устанавливает начальное состояние сервера: - при значении ‘fully-up’ сервер считается немедленно доступным и, если включены проверки работоспособности для этого сервера, он будет переключен в состояние DOWN при неудаче всех проверок работоспособности. - при значении ‘up’ сервер считается немедленно доступным и, если включены проверки работоспособности для этого сервера, он будет немедленно переключен в состояние DOWN при неудаче следующей проверки работоспособности. - при значении ‘down’ сервер считается изначально недоступным и, если включены проверки работоспособности для этого сервера, он может быть переключен в состояние UP при успешной следующей проверке работоспособности. - при значении ‘fully-down’ сервер считается изначально недоступным и, если включены проверки работоспособности для этого сервера, он будет переключен в состояние UP при успешности всех проверок работоспособности. - при значении ’none’ (по умолчанию), управление init-state отключено. Оно может использоваться для восстановления стандартного поведения, когда этот параметр наследовался от директивы ‘default-server’.
Когда HAProxy-экземпляр запускается (перезапускается), обнаруживается новый сервер (например, через открытие сервиса / DNS), динамический сервер включается, сервер выходит из режима технического обслуживания и т.д., используется директива сервера init-state. Эта директива не может использоваться, когда сервер отслеживает другой сервер.
Примеры:
См. также: “option tcp-check”, “option httpchk”
ktls <on|off> [ EXPERIMENTAL ]
Может использоваться в следующих контекстах: tcp, http, log, одноранговые узлы, ring
Включает или отключает ktls для этих сокетов. При включении kTLS будет использоваться, если ядро поддерживает это и шифрование совместимо. Доступно только на Linux 4.17 и выше. Примечание: некоторые сетевые драйверы и/или TLS стеки могут ограничивать использование kTLS только для TLS v1.2. См. также “force-tlsv12”.
log-bufsize <bufsize>
Может быть использован в следующих контекстах: журнал
Ключ “log-bufsize” указывает на кольцо bufsize, которое будет использоваться для скрытого кольца, связанного с сервером журнала в бэкенде журнала. При отсутствии указания значение по умолчанию равно BUFSIZE. Использование большего значения приведёт к увеличению потребления памяти, но может помочь предотвратить потерю сообщений журнала при медленных серверах, поскольку буфер сможет вместить больше ожидающих сообщений. Данный ключ может использоваться только в секциях бэкенда журнала (с “mode log”)
log-proto <logproto>
Может использоваться в следующих контекстах: журнал, кольцо
“log-proto” указывает на протокол, используемый для передачи сообщений об событиях на сервер, настроенный в секции журнала или кольца. Возможные значения — “legacy” и “octet-count”, соответствующие соответственно “Non-transparent-framing” и “Octet counting” в rfc6587. “legacy” является по умолчанию.
maxconn <maxconn>
Допустимые контексты: tcp, http
Параметр “maxconn” указывает на максимальное количество одновременных соединений, которые будут отправлены на этот сервер. Если количество входящих одновременных соединений превышает указанное значение, они будут помещены в очередь и ожидать освобождения слота. Этот параметр очень важен, поскольку может предотвратить выход слабых серверов из строя под экстремальными нагрузками. Если указан параметр “minconn”, ограничение становится динамическим. Значение по умолчанию — “0”, что означает неограниченное количество. См. также параметры “minconn” и “maxqueue”, а также ключевое слово “fullconn” бэкенда.
В режиме HTTP этот параметр ограничивает количество одновременных запросов, а не количество соединений. Множественные запросы могут быть мультиплексированы через одно соединение TCP к серверу. Например, если вы укажете значение maxconn в виде 50, вы можете наблюдать от 1 до 50 фактических соединений с сервером, но не более чем 50 одновременных запросов.
maxqueue <maxqueue>
Допустимые контексты: tcp, http
Параметр “maxqueue” задаёт максимальное количество соединений, которые будут ждать в очереди для этого сервера. Если это ограничение достигнуто, последующие запросы будут перенаправлены на другие серверы вместо бесконечного ожидания обслуживания. Это нарушит сохранение сессии, но может позволить пользователям быстро повторно войти, если сервер, к которому они пытаются подключиться, выходит из строя. Некоторые алгоритмы балансировки нагрузки, такие как leastconn, учитывают это и допускают добавление запросов в очередь сервера до указанного значения, если оно явно установлено в значение, превышающее ноль, что часто позволяет лучше сгладить нагрузку при работе с однозначными значениями maxconn. Значение по умолчанию — “0”, что означает отсутствие ограничения на очередь. См. также параметры “maxconn” и “minconn” и “balance leastconn”.
max-reuse <count>
Может использоваться в следующих контекстах: http, ring
При использовании в контексте http:
Аргумент “max-reuse” указывает процессорам соединений HTTP, что они не должны повторно использовать соединение с сервером более чем указанное количество раз для отправки новых запросов. Разрешённые значения — -1 (по умолчанию), что отключает это ограничение, или любое положительное значение. Значение ноль будет эффективно отключать постоянное соединение. Это используется только для устранения определённых багов на серверах, приводящих к утечке ресурсов со временем. Аргумент не гарантируется нижележащими слоями, так как могут быть технические ограничения, препятствующие его соблюдению. По крайней мере HTTP/2 соединений с серверами будет учитывать это ограничение.
При использовании в контексте ring:
Аргумент “max-reuse” указывает на то, что обработчики соединений TCP должны не использовать соединение с сервером более чем указанное количество раз для отправки сообщений. Это означает, что соединение с сервером будет принудительно разрушено после обработки хотя бы “max-reuse + 1” сообщений на том же соединении. Затем соединение с сервером будет автоматически пересоздано. При работе с большим объёмом сообщений в многопоточной среде это может помочь более равномерно распределять нагрузку по нескольким потокам. Действительно, каждое соединение привязано к одному и тому же потоку CPU на протяжении всего своего срока существования: в отличие от HTTP, нет понятия транзакции syslog, поэтому соединение с сервером может существовать бесконечно, пока сервер не закроет соединение или не произойдёт сеть ошибки. Регулярное разрушение соединений даёт возможность другим потокам обрабатывать сообщения по очереди. Это также может помочь в плавной перезагрузке серверов логов в контекстах, где между HAProxy и серверами логов существует дополнительный слой балансировки нагрузки. Однако следует помнить, что при каждом перезапуске соединения остаётся исходный порт в состоянии TIME_WAIT, который не может быть повторно использован примерно на одну минуту на современных операционных системах, и поэтому необходимо быть осторожными при использовании слишком малых значений, чтобы избежать быстрого истощения исходных портов. Как правило, следует гарантировать, что соединения не разрушаются чаще чем несколько раз в секунду, и, предпочтительно, гораздо реже. Разрешённые значения — -1 (по умолчанию), что отключает это ограничение, или любое положительное значение. В отличие от контекста HTTP, при использовании с серверами-приёмниками “max-reuse” является попыткой: сообщения в кольце группируются, поэтому ограничение проверяется между каждым блоком.
minconn <minconn>
Допустимые контексты: tcp, http
Когда параметр “minconn” установлен, ограничение maxconn становится динамическим и зависит от нагрузки бэкенда. Сервер всегда принимает не менее <minconn> соединений, не более <maxconn>, и ограничение будет находиться в диапазоне между этими значениями при наличии менее чем <fullconn> одновременных соединений. Это позволяет ограничивать нагрузку на сервер во время обычной работы, но увеличивать её при важных нагрузках, не перегружая сервер во время экстремальных нагрузок. См. также параметры “maxconn” и “maxqueue”, а также ключевое слово “fullconn” бэкенда.
namespace <name>
Может использоваться в следующих контекстах: tcp, http, log, peers, ring
В Linux возможно указать, к какому сетевому пространству принадлежит сокет. Эта директива позволяет явно привязать сервер к пространству имен, отличному от стандартного. Для получения дополнительной информации о сетевых пространствах см. документацию операционной системы.
no-agent-check
Допустимые контексты: tcp, http, log
Этот параметр может быть использован как “server” настройка для сброса любой “agent-check” настройки, которая была наследована из “default-server” директивы как значение по умолчанию. Он также может быть использован как “default-server” настройка для сброса любой предыдущей “default-server” “agent-check” настройки.
no-backup
Допустимые контексты: tcp, http, log
Этот параметр может быть использован как “server” настройка для сброса любой “backup” настройки, которая бы была наследована из “default-server” директивы как значение по умолчанию. Он также может быть использован как “default-server” настройка для сброса любой предыдущей “default-server” “backup” настройки.
no-check
Допустимые контексты: tcp, http, log
Этот параметр может быть использован как “server” настройка для сброса любой “check” настройки, которая бы была наследована из “default-server” директивы как значение по умолчанию. Он также может быть использован как “default-server” настройка для сброса любой предыдущей “default-server” “check” настройки.
no-check-reuse-pool
Допустимые контексты: tcp, http
Этот параметр отменяет любые предыдущие “check-reuse-pool”, возможно наследуемые от “default-server”. Любые проверки будут проводиться на его отдельном соединении.
no-check-sni-auto
Допустимые контексты: tcp, http, log
Этот параметр может быть использован как “server” настройка для отключения автоматического выбора SNI для проверок здоровья SSL серверов, которые включены по умолчанию.
См. опцию “no-sni-auto” для отключения автоматического выбора SNI для прокси-трафика.
no-check-ssl
Допустимые контексты: tcp, http, log
Этот параметр может быть использован как “server” настройка для сброса любой “check-ssl” настройки, которая была наследована из “default-server” директивы как значение по умолчанию. Он также может быть использован как “default-server” настройка для сброса любой предыдущей “default-server” “check-ssl” настройки.
no-renegotiate
Допустимые контексты: tcp, http, log
Этот параметр доступен только тогда, когда поддержка OpenSSL была включена. Он отключает механизмы переговоров, будь то устаревший небезопасный механизм или более современный механизм «безопасных переговоров» (RFC 5746 TLS Расширение указания переговоров), для указанного SSL бэкенда. Данный параметр также доступен в глобальном утверждении “ssl-default-server-options”. Переговоры больше не возможны в TLS 1.3. Если ни “renegotiate”, ни “no-renegotiate” не указаны, сохраняется стандартное поведение библиотеки SSL. Примечание: например, библиотека OpenSSL включает безопасные переговоры по умолчанию, в то время как AWS-LC отключает их. См. также “renegotiate”.
no-send-proxy
Допустимые контексты: tcp, http
Этот параметр может быть использован как “server” настройка для сброса любой “send-proxy” настройки, которая бы была наследована из “default-server” директивы как значение по умолчанию. Он также может быть использован как “default-server” настройка для сброса любой предыдущей “default-server” “send-proxy” настройки.
no-send-proxy-v2
Допустимые контексты: tcp, http
Этот параметр может быть использован как “server” настройка для сброса любой “send-proxy-v2” настройки, которая бы была наследована из “default-server” директивы как значение по умолчанию. Он также может быть использован как “default-server” настройка для сброса любой предыдущей “default-server” “send-proxy-v2” настройки.
no-send-proxy-v2-ssl
Допустимые контексты: tcp, http
Этот параметр может быть использован как “server” настройка для сброса любой “send-proxy-v2-ssl” настройки, которая бы была наследована из “default-server” директивы как значение по умолчанию. Он также может быть использован как “default-server” настройка для сброса любой предыдущей “default-server” “send-proxy-v2-ssl” настройки.
no-send-proxy-v2-ssl-cn
Допустимые контексты: tcp, http
Этот параметр может быть использован как “server” настройка для сброса любой “send-proxy-v2-ssl-cn” настройки, которая бы была наследована из “default-server” директивы как значение по умолчанию. Он также может быть использован как “default-server” настройка для сброса любой предыдущей “default-server” “send-proxy-v2-ssl-cn” настройки.
no-sni-auto
Может быть использован в следующих контекстах: tcp, http, log, peers, ring
Этот параметр может быть использован как “server” настройка для отключения автоматического выбора SNI, включенного по умолчанию.
См. параметр “no-check-sni-auto” для отключения автоматического выбора SNI для проверки работоспособности SSL.
no-ssl
Может быть использован в следующих контекстах: tcp, http, log, peers, ring
Этот параметр может быть использован как “server” настройка для сброса любой “ssl” настройки, которая была наследована из “default-server” директивы как значение по умолчанию. Он также может быть использован как “default-server” настройка для сброса любой предыдущей “default-server” “ssl” настройки.
Примечание: использование default-server ssl настройки и no-ssl на сервере инициализирует SSL соединение, поэтому его можно включить позже через runtime API: см. команды set server в документации по управлению.
no-ssl-reuse
Может использоваться в следующих контекстах: tcp, http, log, peers, ring
Этот параметр отключает SSL повторное использование сессий при использовании SSL для связи с сервером. Он будет вынуждать сервер выполнять полную аутентификацию для каждого нового соединения. Вероятно, полезен только для бенчмаркинга, устранения неполадок и для пользователей с повышенной осторожностью.
no-sslv3
Может использоваться в следующих контекстах: tcp, http, log, peers, ring
Этот параметр отключает поддержку SSLv3 при использовании SSL для связи с сервером. Примечание, что
SSLv2 отключён в коде и не может быть включён с помощью любого параметра конфигурации. Используйте
“ssl-min-ver” и “ssl-max-ver” вместо этого.
Доступен в default-server: Нет
no-tls-tickets
Может использоваться в следующих контекстах: tcp, http, log, peers, ring
Этот параметр доступен только тогда, когда встроенная поддержка OpenSSL. Отключает состояние-независимое восстановление сессии (RFC 5077 TLS Ticket extension) и вынуждает использовать состояние-зависимое восстановление сессии. Состояние-независимое восстановление сессии более затратно в CPU использовании на серверах. Этот параметр также доступен в глобальном утверждении “ssl-default-server-options”. Механизм TLS ticket используется только до TLS 1.2. Применение TLS тикетов нарушает безопасность передачи ключей, если ключи тикетов не периодически пересылаются (через перезагрузку или с помощью “tls-ticket-keys”). См. также “tls-tickets”.
no-tlsv10
Может использоваться в следующих контекстах: tcp, http, log, peers, ring
Этот параметр отключает поддержку TLSv1.0 при использовании SSL для связи с сервером. Примечание, что
SSLv2 отключён в коде и не может быть включён с помощью любого параметра конфигурации. TLSv1 дороже, чем SSLv3, поэтому часто имеет смысл отключать его при связи с локальными серверами. Этот параметр также доступен на глобальном утверждении “ssl-default-server-options”. Используйте “ssl-min-ver” и “ssl-max-ver” вместо этого.
Доступен в default-server: Нет
no-tlsv11
Может использоваться в следующих контекстах: tcp, http, log, peers, ring
Этот параметр отключает поддержку TLSv1.1 при использовании SSL для связи с сервером. Примечание, что
SSLv2 отключён в коде и не может быть включён с помощью любого параметра конфигурации. TLSv1 дороже, чем SSLv3, поэтому часто имеет смысл отключать его при связи с локальными серверами. Этот параметр также доступен на глобальном утверждении “ssl-default-server-options”. Используйте “ssl-min-ver” и “ssl-max-ver” вместо этого.
Доступен в default-server: Нет
no-tlsv12
Может использоваться в следующих контекстах: tcp, http, log, peers, ring
Этот параметр отключает поддержку TLSv1.2 при использовании SSL для связи с сервером. Примечание, что
SSLv2 отключён в коде и не может быть включён с помощью любого параметра конфигурации. TLSv1 дороже, чем SSLv3, поэтому часто имеет смысл отключать его при связи с локальными серверами. Этот параметр также доступен на глобальном утверждении “ssl-default-server-options”. Используйте “ssl-min-ver” и “ssl-max-ver” вместо этого.
Доступен в default-server: Нет
no-tlsv13
Может использоваться в следующих контекстах: tcp, http, log, peers, ring
Этот параметр отключает поддержку TLSv1.3 при использовании SSL для связи с сервером. Примечание, что
SSLv2 отключён в коде и не может быть включён с помощью любого параметра конфигурации. TLSv1 дороже, чем SSLv3, поэтому часто имеет смысл отключать его при связи с локальными серверами. Этот параметр также доступен на глобальном утверждении “ssl-default-server-options”. Используйте “ssl-min-ver” и “ssl-max-ver” вместо этого.
Доступен в default-server: Нет
no-verifyhost
Может быть использован в следующих контекстах: tcp, http, log, одноранговые узлы, ring
Этот параметр может быть использован как “server” настройка для сброса любой “verifyhost” настройки, которая была наследована из “default-server” директивы как значение по умолчанию. Он также может быть использован как “default-server” настройка для сброса любой предыдущей “default-server” “verifyhost” настройки.
no-tfo
Может быть использован в следующих контекстах: tcp, http, log, одноранговые узлы, ring
Эта опция может быть использована как “server” настройка для сброса любой “tfo” настройки, которая была наследована из “default-server” директивы как значение по умолчанию. Она также может быть использована как “default-server” настройка для сброса любой предыдущей “default-server” “tfo” настройки.
non-stick
Допустимые контексты: tcp, http
Никогда не добавляйте соединения, присвоенные этому серверу, в stick-table. Это может быть использовано в сочетании с резервной копией для обеспечения отключения сохранения состояния для резервных серверов. stick-table
npn <protocols>
Допустимые контексты: tcp, http
Это включает расширение NPN TLS и объявляет указанный список протоколов как поддерживаемый в дополнение к NPN. Список протоколов состоит из запятой-разделённого списка названий протоколов, например:
“http/1.1,http/1.0” (без кавычек). Требуется, чтобы библиотека SSL была собрана с включённой поддержкой расширений TLS (проверьте с помощью haproxy -vv). Примечание, что расширение NPN было заменено расширением ALPN (см. ключевое слово “alpn”), хотя это расширение доступно только начиная с OpenSSL 1.0.2.
observe <mode>
Допустимые контексты: tcp, http
Этот параметр включает настройку проверки работоспособности на основе наблюдения за коммуникацией с сервером. По умолчанию данная функция отключена и для её включения необходимо также включить проверку работоспособности. Поддерживаются два режима: “layer4” и “layer7”. В режиме “layer4” значимы только успешные и неуспешные TCP-соединения. В режиме “layer7”, который допускается только для HTTP-прокси, проверяются ответы, получаемые от сервера, например, корректные/ошибочные HTTP-коды, непарсимые заголовки, тайм-аут и т.д. Корректные коды состояний включают 100 до 499, 501 и 505.
См. также “check”, “on-error” и “error-limit”.
on-error <mode>
Допустимые контексты: tcp, http, log
Выберите, что должно произойти при обнаружении достаточного количества последовательных ошибок. В настоящее время доступны четыре режима:
- fastinter: принудительно включить fastinter
- fail-check: имитировать неудачную проверку работоспособности, также принудительно включает fastinter (по умолчанию)
- sudden-death: имитировать неудачную проверку работоспособности перед критическим сбоем, один дополнительный неудачный результат проверки помечает сервер как выключенный, принудительно включает fastinter
- mark-down: немедленно помечает сервер как выключенный и принудительно включает fastinter
См. также “check”, “observe” и “error-limit”.
on-marked-down <action>
Допустимые контексты: tcp, http, log
Изменяйте то, что происходит при отмечении сервера как недоступного. В настоящее время доступно одно действие:
- shutdown-sessions: Завершение потоков однорангового узла. При включении этого параметра все соединения с сервером немедленно прекращаются при выходе сервера из строя. Этот параметр может быть использован, если проверка работоспособности выявляет более сложные случаи, чем простое состояние соединения, и длительные тайм-ауты приводят к тому, что сервис остаётся неотвечаемым слишком долго. Например, проверка работоспособности может обнаружить, что база данных застряла, и уже невозможно использовать существующие соединения. Соединения, завершённые таким образом, логируются с кодом завершения ‘D’ (для “Down”).
Действия отключены по умолчанию
on-marked-up <action>
Допустимые контексты: tcp, http, log
Изменяйте то, что происходит при отметке сервера как недоступного. В настоящее время доступно одно действие:
- shutdown-backup-sessions: Завершение потоков на всех серверах резервной копии. Это выполняется только если сервер не находится в состоянии резервной копии и не отключён (его эффективный вес > 0). Такое действие может быть использовано в некоторых случаях для принудительного возврата всех потоков на активный сервер после восстановления при работе с длительными сессиями (например, LDAP, SQL, …). Использование этой функции может привести к большему количеству проблем, чем оно решает (например, незавершённые транзакции), поэтому эта функция должна использоваться с крайней осторожностью. Потоки, завершённые из-за запуска сервера, логируются с кодом завершения ‘U’ (для “Up”).
Действия отключены по умолчанию
pool-conn-name <expr>
Допустимые контексты: http
При установке соединения с бэкендом оценивается это выражение для генерации имени соединения. Это имя является одним из ключевых свойств соединения в пуле пассивных серверов. См. ключевое слово “http-reuse”. При запросе на поиск существующего пассивного соединения оценивается это выражение для соответствия идентичному соединению.
В контексте, где SSL SNI используется для соединения с бэкендом, имя соединения автоматически присваивается результату выражения “sni”. Это соответствует наиболее распространённому использованию. Для более сложных настроек “pool-conn-name” может быть использован для перекрытия этого поведения.
См. также: “http-reuse”, “sni”
pool-low-conn <max>
Допустимые контексты: http
Установите низкий порог количества дежурных соединений для сервера, ниже которого поток не будет пытаться украдывать соединение у другого потока. Это может быть полезно для улучшения CPU в сценариях, включающих много очень быстрых серверов, чтобы обеспечить, чтобы все потоки всегда сохраняли несколько дежурных соединений, а не позволяли им накапливаться в одном потоке и мигрировать между потоками. Типичные значения — двойное количество потоков — показывают очень хорошую производительность уже при ответах в подмиллисекундах. По умолчанию значение ноль, что означает, что любое дежурное соединение может быть использовано в любое время. Это рекомендуемое значение для обычного использования. Это касается только соединений, которые могут быть совмещены по тем же принципам, что и те, которые применяются к “http-reuse”. В случае отключения совместного использования соединений между потоками через “tune.idle-pool.shared”, это настройка может стать очень важной для обеспечения того, чтобы каждый поток всегда имел несколько соединений, иначе коэффициент повторного использования соединений будет снижаться с увеличением количества потоков.
pool-max-conn <max>
Допустимые контексты: http
Установите максимальное количество дежурных соединений для сервера. -1 означает неограниченное количество соединений, 0 означает отсутствие дежурных соединений. По умолчанию — -1. При включении дежурных соединений, орфанные дежурные соединения, которые больше не принадлежат никакой сессии клиента, перемещаются в отдельный пул, чтобы оставаться доступными для будущих клиентов. Это касается только соединений, которые могут быть совместно использованы в соответствии с теми же принципами, что и для “http-reuse”.
pool-purge-delay <delay>
Допустимые контексты: http
Устанавливает задержку начала удаления пассивных соединений. Каждые <delay> интервал, половина пассивных соединений закрывается. 0 означает, что никакие пассивные соединения не сохраняются. По умолчанию — 5s.
port <port>
Допустимые контексты: tcp, http, log
Используя параметр “port”, становится возможным отправлять проверки работоспособности через другой порт или проводить пробы на agent-check. На некоторых серверах может быть желательно выделить порт для конкретного компонента, способного выполнять сложные тесты, более подходящие для проверок работоспособности, чем приложение. Обычно для этого запускают простой скрипт в inetd. Параметр игнорируется, если не задан параметр “check”. См. также параметр “addr”.
proto <name>
Допустимые контексты: tcp, http
Принудительно задаёт протокол мультиплексора, используемый для исходящих соединений с этим сервером. Он должен быть совместим с режимом бэкенда (TCP или HTTP). Должен также быть применим на стороне бэкенда. Список доступных протоколов приведён в свойствах протоколов haproxy -vv.The — указываются режим (TCP/HTTP), сторона (FE/BE), имя мультиплексора и его флаги.
Некоторые протоколы подвержены блокировке на уровне головы потока на стороне сервера (флаг=HOL_RISK). В конечном итоге некоторые протоколы не поддерживают обновления (флаг=NO_UPG). Также отображается совместимость HTX (флаг=HTX).
Здесь приведены протоколы, которые могут быть использованы в качестве аргумента директивы “proto” на строке сервера:
Понятие за счёт этого параметра — обойти выбор наилучшего протокола мультиплексера для всех
соединений, установленных к этому серверу.
Если настроены параметры ALPN или NPN, указанные протоколы должны быть совместимы с
протоколом мультиплексера, чтобы избежать каких-либо проблем. Например, если установлено “proto h1”, то ALPN
не должен быть установлен в значение “h2”.
См. также “ws” для использования альтернативного протокола для потоков WebSocket.
QMux — это подмножество QUIC, работающее над TCP. Оно соответствует следующему черновому протоколу https://www.ietf.org/archive/id/draft-ietf-quic-qmux-01.html . На данный момент считается экспериментальным в HAProxy.
quic-cc-algo { cubic | newreno | bbr | nocc }[(<args,...>)]
Это QUIC специфичное настройка для выбора алгоритма управления перегрузкой для любого соединения, направленного на этот сервер. Они аналогичны тем, что используются в TCP. См. опцию bind с аналогичным названием для полного описания всех вариантов настройки.
Значение по умолчанию: cubic
См. также: “tune.quic.be.tx.pacing” и “tune.quic.be.cc.max-win-size”
redir <prefix>
Допустимые контексты: http
Параметр “redir” включает режим перенаправления для всех запросов GET и HEAD, адресующих данный сервер. Это означает, что вместо того чтобы передавать запрос серверу, HAProxy отправляет ответ «HTTP 302» с заголовком «Location», состоящим из этого префикса, сразу за которым следует запрошенный URI начиная с ведущего ‘/’ компонента пути. Это означает, что после <prefix> не должен использоваться завершающий слэш. Все невалидные запросы будут отклонены, а все не-GET или HEAD запросы будут нормально обрабатываться сервером. Примечание: поскольку ответ полностью синтезирован, в ответе невозможно изменять заголовки или вставлять куки. Однако куки в запросах всё ещё анализируются, что делает это решение полностью применимым для направления пользователей к удалённому месту в случае локальной катастрофы. Основное применение заключается в увеличении пропускной способности статических серверов за счёт прямого подключения клиентов к ним. Примечание: никогда не используйте относительный путь здесь, иначе возникнет цикл между клиентом и HAProxy!
Пример: сервер srv1 192.168.1.1:80 переадресация http://image1.mydomain.com проверка
renegotiate
Допустимые контексты: tcp, http, log
Этот параметр включает механизм безопасного повторного согласования (RFC 5746 TLS Расширение указания повторного согласования) для заданного бэкенда SSL. Это не означает, что клиент SSL будет отправлять запросы на повторное согласование, он лишь разрешает бэкендам проводить повторное согласование при запросе серверов. Требуется, чтобы лежащая в основе библиотека SSL фактически поддерживала повторное согласование. Этот параметр также доступен на глобальном уровне в операторе “ssl-default-server-options”. Повторное согласование больше невозможно в TLS 1.3. Если ни “renegotiate”, ни “no-renegotiate” не указаны, сохраняется поведение по умолчанию библиотеки SSL. Обратите внимание, что, например, библиотека OpenSSL включает безопасное повторное согласование по умолчанию, в то время как AWS-LC отключает его.
rise <count>
Допустимые контексты: tcp, http, log
Параметр “rise” указывает, что сервер будет считаться работоспособным после <count>
успешных последовательных проверок работоспособности. Значение по умолчанию равно 2, если параметр не указан. См. также параметры “check”, “inter” и “fall”.
resolve-opts <option>,<option>,… Может быть использован в следующих контекстах: tcp, http, log
Запятая-separated список опций, которые должны быть применены к DNS разрешению, связанному с этим сервером.
Доступные варианты:
allow-dup-ip По умолчанию HAProxy запрещает дублирование адресов IP в бэкенде при выполнении разрешения DNS в режиме работы. Однако в некоторых случаях оправдано, чтобы два сервера (в одном бэкенде, разрешаемые одним FQDN) имели один и тот же адрес IP. В таком случае включите эту опцию. Это противоположность prevent-dup-ip.
ignore-weight Игнорировать любое значение веса, установленное в записи SRV. Это полезно тогда, когда вы хотите управлять весами с помощью альтернативного метода, например, с помощью “agent-check” или через API времени выполнения.
prevent-dup-ip Обеспечить соблюдение стандартного поведения HAProxy на сервере: предотвратить повторное использование адреса IP, уже присвоенного серверу в одном бэкенде и имеющего одинаковое полное имя домена. Это противоположность allow-dup-ip.
Пример:
С опцией allow-dup-ip:
- если сервер именования возвращает один IP-адрес, тогда оба сервера будут использовать его
- Если сервер именования возвращает 2 IP-адресов, тогда каждый сервер будет использовать разный адрес
По умолчанию: не задано
resolve-prefer <family>
Допустимые контексты: tcp, http, log
Когда включена разрешение DNS для сервера и возвращаются несколько адресов IP из разных семейств, HAProxy будет предпочтительно использовать адрес из семейства, указанного в параметре “resolve-prefer”. См. также глобальный параметр “dns-accept-family” для принудительного использования конкретного семейства. Доступные семейства: “ipv4” и “ipv6”.
Значение по умолчанию: ipv6
Пример:
resolve-net <network>[,<network[,...]]
Допустимые контексты: tcp, http, log
Этот параметр приоритизирует выбор адреса IP, соответствующего сети. Это полезно в облаках для предпочтения локального IP. В некоторых случаях сервис высокой доступности в облаке может быть объявлен с множеством адресов в разных центрах обработки данных. Задержка между центрами обработки данных не является незначительной, поэтому данный параметр позволяет предпочтать локальный центр обработки данных. Если адрес не соответствует настроенной сети, выбирается другой адрес.
Пример:
resolvers <id>
Допустимые контексты: tcp, http, log
Указывает на существующую секцию “resolvers” для разрешения имени хоста текущего сервера. Часто рекомендуется отключать разрешение на основе libc при использовании разрешителей, хотя существуют исключения (см. секцию 5.3.1 ). В любом случае рекомендуется явно указывать “init-addr” при использовании разрешителей, чтобы не упустить этот элемент.
Пример:
См. также секцию 5.3 для деталей реализации и ловушек, на которые следует обратить внимание.
send-proxy
Допустимые контексты: tcp, http
Параметр “send-proxy” обеспечивает использование протокола PROXY при любом соединении, установленном с этим сервером. Протокол PROXY сообщает другой стороне о слоях 3/4 адресов входящего соединения, чтобы она могла узнать адрес клиента или публичный адрес, к которому он подключился, независимо от протокола верхнего уровня. Для соединений, принятых слушателем “accept-proxy” или “accept-netscaler-cip”, будет использоваться объявленный адрес. Поддерживаются только семейства адресов TCPv4 и TCPv6. Другие семейства, такие как Unix-сокеты, будут отображать семейство UNKNOWN. Серверы, использующие этот параметр, могут полностью быть связаны с другим экземпляром HAProxy, настроенным с параметром “accept-proxy”. Этот параметр не должен использоваться, если сервер не осведомлен о протоколе. При отправке проверок работоспособности на сервер, при наличии этого параметра, автоматически используется протокол PROXY, за исключением явного указания директивы “port” или “addr”, в случае чего потребуется также явная директива “check-send-proxy” для использования протокола PROXY. См. также параметр “no-send-proxy” данной секции и параметры “accept-proxy” и “accept-netscaler-cip” ключевого слова “bind”.
send-proxy-v2
Допустимые контексты: tcp, http
Параметр “send-proxy-v2” обеспечивает использование версии протокола PROXY 2 при любом соединении, установленном с этим сервером. Протокол PROXY сообщает другой стороне о слоях 3/4 адресов входящего соединения, чтобы он мог узнать адрес клиента или публичный адрес, к которому он подключился, независимо от протокола верхнего слоя. Он также передаёт ALPN информацию, если был достигнут соглашение по ALPN. Этот параметр не должен использоваться, если сервер не осведомлён об этой версии протокола. См. также опцию “no-send-proxy-v2” этой секции и опцию send-proxy ключевого слова “bind”.
set-proxy-v2-tlv-fmt(<id>) <fmt>
Допустимые контексты: tcp, http
Параметр “set-proxy-v2-tlv-fmt” используется для отправки произвольных TLV-блоков версии протокола PROXY 2. Для типа (<id>) диапазона определённого типа TLV см. секцию 2.2.8 в спецификации протокола прокси. Однако, значение может быть выбрано произвольно, при условии, что оно не превышает максимальную длину 65,535 байт. Его также можно использовать для передачи TLV-блоков, применяя команду fetch “fc_pp_tlv” для извлечения полученного TLV с фронтенда. Его можно использовать как опцию сервера или как опцию прокси default-server. Он должен использоваться в сочетании с send-proxy-v2 таким образом, чтобы на самом деле отправлялись TLV-блоки версии PPv2.
Пример: сервер srv1 192.168.1.1:80 send-proxy-v2 set-proxy-v2-tlv-fmt(0x20) %[fc_pp_tlv(0x20)]
В этом случае мы получаем TLV с типом 0x20 как строку и устанавливаем его в значение нового TLV, который также имеет тип 0x20.
proxy-v2-options <option>[,<option>]*
Допустимые контексты: tcp, http
Параметр “proxy-v2-options” добавляет опции отправки в версии протокола PROXY 2 при использовании “send-proxy-v2”. Доступные опции:
- ssl : См. также “send-proxy-v2-ssl”.
- cert-cn : См. также “send-proxy-v2-ssl-cn”.
- ssl-cipher: Название используемого шифра.
- cert-sig : Алгоритм подписи используемого сертификата.
- cert-key : Алгоритм ключа используемого сертификата
- authority: Значение имени хоста, переданное клиентом (поддерживаются только SNI из соединения TLS).
- crc32c : Хэш-сумма заголовка PROXYv2.
- unique-id: Передача уникального идентификатора, сгенерированного на основе фронтенда “unique-id-format” в заголовке PROXYv2. Уникальный идентификатор в первую очередь предназначен для “mode tcp”. Он может привести к непредвиденным результатам в “mode http”, поскольку сгенерированный уникальный идентификатор также используется для первого запроса HTTP в соединении постоянного соединения.
send-proxy-v2-ssl
Допустимые контексты: tcp, http
Параметр “send-proxy-v2-ssl” обеспечивает использование версии протокола PROXY 2 при любом соединении, установленном с этим сервером. Протокол PROXY сообщает другой стороне о слоях 3/4 адресов входящего соединения, чтобы он мог узнать адрес клиента или публичный адрес, к которому он подключился, независимо от протокола верхнего слоя. Кроме того, в заголовок протокола PROXY добавляется расширение информации SSL протокола PROXY. Данное настройка не должна использоваться, если сервер не осведомлён об этой версии протокола. См. также опцию “no-send-proxy-v2-ssl” этой секции и опцию “send-proxy-v2” ключевого слова “bind”.
send-proxy-v2-ssl-cn
Допустимые контексты: tcp, http
Параметр “send-proxy-v2-ssl” обеспечивает использование версии протокола PROXY 2 при любом соединении, установленном с этим сервером. Протокол PROXY сообщает другой стороне о слоях 3/4 адресов входящего соединения, чтобы он мог узнать адрес клиента или публичный адрес, к которому он обращался, независимо от протокола верхнего слоя. Кроме того, расширение информации SSL протокола PROXY, а также имя общего субъекта из сертификата клиента (если имеется), добавляется в заголовок протокола PROXY. Данное настройка не должна использоваться, если сервер не осведомлён об этой версии протокола. См. также опцию “no-send-proxy-v2-ssl-cn” этой секции и опцию “send-proxy-v2” ключевого слова “bind”.
shard <shard>
Может использоваться в следующих контекстах: одноранговые узлы
Параметр используется только в контексте синхронизации таблиц привязок с одноранговыми узлами. Параметр “shard” идентифицирует одноранговые узлы, которые получают все обновления stick-table по ключам с этим шардом в распределённой хеш-функции. Допустимыми значениями являются значения от 0 до значения параметра “shards”, указанного в секции “peers”. Значение 0 является значением по умолчанию, означающим, что узел получает все обновления по ключам. Значения, превышающие “shards”, будут игнорироваться. Это также относится к любому значению, заданному для локального узла.
Пример:
peers mypeers shards 3 peer A 127.0.0.1:40001 # local peer without shard value (0 internally) peer B 127.0.0.1:40002 shard 1 peer C 127.0.0.1:40003 shard 2 peer D 127.0.0.1:40004 shard 3
sigalgs <sigalgs>
Может использоваться в следующих контекстах: tcp, http, log, одноранговые узлы, ring
Этот параметр доступен только тогда, когда поддержка OpenSSL была включена. Устанавливает строку, описывающую список алгоритмов подписи, согласовываемых во время рукопожатия TLSv1.2 и TLSv1.3. Формат строки определён в “man 3 SSL_CTX_set1_sigalgs” из справочной документации OpenSSL. Не рекомендуется использовать этот параметр, если не требуется совместимость с промежуточным устройством.
slowstart <start_time_in_ms>
Допустимые контексты: tcp, http
Параметр “slowstart” для сервера принимает значение в миллисекундах, указывающее, через какое время сервер, только что вернувшийся в работу, начнёт функционировать на полной скорости. Как и для любого другого параметра, зависящего от времени, его можно указать в любой другой явной единице измерения: { us, ms, s, m, h, d }. Скорость увеличивается линейно от 0 до 100% в течение этого времени. Ограничение применяется к двум параметрам:
maxconn: количество принятых сервером соединений будет расти от 1 до 100% обычного
динамического предела, определенного выражением (minconn,maxconn,fullconn).weight: при использовании бэкендом динамического алгоритма с весом, вес растёт линейно от 1 до
100%. В этом случае вес обновляется при каждом проверке работоспособности. Поэтому важно, чтобы параметр “inter” был меньше чем “slowstart”, чтобы максимизировать количество шагов.
При запуске HAProxy механизм slowstart не применяется, иначе это привело бы к проблемам для работающих серверов. Он применяется только тогда, когда сервер ранее был обнаружен как неисправный.
sni <expression>
Может использоваться в следующих контекстах: tcp, http, log, peers, ring
Параметр “sni” оценивает выражение извлечения образца, преобразует его в строку и использует результат как имя хоста, отправляемое в расширение SNI TLS серверу. Типичный сценарий — передача SNI, полученного от клиента, в сценарии моста TCP/SSL, используя выражение “ssl_fc_sni” для извлечения образца. ЭТО ДОЛЖНО НЕ ИСПОЛЬЗОВАТЬСЯ В СЛУЧАЯХ HTTPS, где следует использовать req.hdr(host), поскольку SNI в HTTPS всегда должна соответствовать полю Host, и клиенты допускают использование разных имен хостов в рамках одного соединения. Если установлено “verify required” (что является рекомендуемым настройкой), то получаемое имя также проверяется на соответствие именам в сертификате сервера. Дополнительные сведения см. в директиве “verify”. Если требуется задать SNI для проверки работоспособности, см. директиву “check-sni”.
По умолчанию, SNI присваивается имени соединения для “http-reuse”, если не переопределено директивой “pool-conn-name” сервера.
sni-auto
Может использоваться в следующих контекстах: tcp, http, log, одноранговые узлы, ring
Параметр “sni-auto” включает автоматический выбор SNI, если значение ранее не было задано. Он устанавливает выражение “sni” в значение “req.hdr(host),field(1,:)”, что означает, что SNI будет содержать имя хоста запроса, отправляемого на сервер, с удалением номера порта. По умолчанию включено, однако данный параметр может использоваться как “server”-настройка для сброса любого “no-sni-auto”-настройки, которая могла быть унаследована от директивы “default-server” как значения по умолчанию. Он также может использоваться как “default-server”-настройка для сброса любой предыдущей “default-server” “no-sni-auto”-настройки.
Для HTTPS соединений выбранный SNI определяется на основе значения заголовка хост запроса, если он присутствует.
В противном случае он остаётся неустановленным. Для других протоколов опция игнорируется.
Если используется автоматическое определение SNI, то значение присваивается имени соединения для “http-reuse”, за исключением случая, когда это перекрывается ключевым словом “pool-conn-name” сервера.
См. опцию “check-sni-auto” для включения автоматического выбора SNI при проверке работоспособности для SSL.
source <addr>[:<pl>[-<ph>]] [usesrc { <addr2>[:<port2>] | client | clientip } ]
Может использоваться в следующих контекстах: tcp, http, log, peers, ring
Параметр “source” устанавливает исходный адрес, который будет использоваться при подключении к серверу. Он следует идентичным параметрам и принципам ключа бэкенда “source”, за исключением того, что он применяется только к серверу, который его ссылается. Для подробной информации см. ключ “source”.
Кроме того, утверждение “source” на строке сервера позволяет указать диапазон исходных портов, задавая нижнюю и верхнюю границы, разделённые дефисом (’-’). Некоторые операционные системы могут требовать действительный IP-адрес при указании диапазона исходных портов. Разрешено указывать один и тот же IP/диапазон для нескольких серверов. Это позволяет обойти ограничение в 64 тыс. одновременных соединений. Ограничение в этом случае достигнет 64 тыс. соединений на каждый сервер.
Поскольку в Linux 4.2/libc 2.23 IP_BIND_ADDRESS_NO_PORT установлено для соединений, указывающих исходный адрес без портов.
ssl
Может использоваться в следующих контекстах: tcp, http, log, peers, ring
Эта опция включает SSL шифрование на исходящих соединениях к серверу. Критически важно проверять сертификаты сервера с помощью “verify” при использовании SSL для подключения к серверам, иначе коммуникация подвергается простым атакам «человека в середине», что делает SSL бесполезной. При использовании этой опции проверки работоспособности автоматически отправляются в SSL, если нет директивы “port” или “addr”, указывающей на то, что проверка должна быть направлена в другое место. См. “no-ssl” для отключения опции “ssl” и опцию “check-ssl” для принудительной отправки проверок работоспособности в SSL.
ssl-max-ver [ SSLv3 | TLSv1.0 | TLSv1.1 | TLSv1.2 | TLSv1.3 ]
Может использоваться в следующих контекстах: tcp, http, log, peers, ring
Этот параметр обеспечивает использование <version> или ниже при использовании SSL для связи с сервером.
Этот параметр также доступен на глобальном утверждении “ssl-default-server-options”. См. также
“ssl-min-ver”.
ssl-min-ver [ SSLv3 | TLSv1.0 | TLSv1.1 | TLSv1.2 | TLSv1.3 ]
Может использоваться в следующих контекстах: tcp, http, log, peers, ring
Этот параметр обеспечивает использование <version> или верхнего уровня при использовании SSL для связи с сервером.
Этот параметр также доступен в глобальном утверждении “ssl-default-server-options”. См. также
“ssl-max-ver”.
ssl-reuse
Может быть использован в следующих контекстах: tcp, http, log, одноранговые узлы, ring
Этот параметр может быть использован как “server” настройка для сброса любой “no-ssl-reuse” настройки, которая бы была наследована из директивы “default-server” как значение по умолчанию. Он также может быть использован как “default-server” настройка для сброса любой предыдущей “default-server” “no-ssl-reuse” настройки.
stick
Допустимые контексты: tcp, http
Этот параметр может быть использован как “server” настройка для сброса любой “non-stick” настройки, которая бы была наследована из “default-server” директивы как значение по умолчанию. Он также может быть использован как “default-server” настройка для сброса любой предыдущей “default-server” “non-stick” настройки.
strict-maxconn
Допустимые контексты: tcp, http
maxconn к серверам — это немного неточное выражение, на самом деле оно настраивает максимальное количество запросов, которые мы отправляем на сервер, но при наличии пассивных соединений у нас может быть больше общего количества соединений к серверу. Если требуется строгий лимит соединений с сервера, то можно использовать строгий maxconn. В этом случае мы никогда не устанавливаем больше соединений с сервером, чем maxconn, и пытаемся переиспользовать или уничтожить соединения при необходимости. Обратите внимание, однако, что это может привести к сбоям запросов в случае, если не удаётся установить новое соединение и нет доступного пассивного соединения. Это может происходить при установлении «приватных» соединений, соединений, связанных только с сессией, поскольку произошла аутентификация.
socks4 <addr>:<port>
Может использоваться в следующих контекстах: tcp, http, log, peers, ring
Этот параметр включает туннели socks4 для исходящих соединений с сервером. Использование данного параметра не будет по умолчанию заставлять проверку работоспособности проходить через socks4. Для включения функции необходимо использовать ключевое слово “check-via-socks4”.
tcp-md5sig <password>
Может быть использован в следующих контекстах: tcp, http, log, peers, ring
Включает подпись TCP MD5 (RFC 2385 Защита BGP Сессий через опцию подписи TCP MD5)
для всех исходящих соединений с этого сервера. Эта опция доступна только на Linux. При включении, строка <password> используется для подписи каждого TCP сегмента с помощью 16-байтового MD5 хэша. Это обеспечивает защиту TCP соединения от фальшивизации. Основное применение этой опции — защита BGP от введения фальшивых TCP сегментов в поток соединения. Однако она может быть полезна для любых очень длительных TCP соединений.
tcp-ut <delay>
Может использоваться в следующих контекстах: tcp, http, log, peers, ring
Устанавливает тайм-аут пользователя TCP для всех исходящих соединений с этим сервером. Данное опция доступно на Linux с версии 2.6.37. Оно позволяет HAProxy настроить тайм-аут для сокетов, содержащих данные, не получающие подтверждения в течение заданного промежутка времени. Это особенно полезно для долговременных соединений с длительными периодами бездействия, таких как удалённые терминалы или пулы соединений с базами данных, где тайм-ауты клиента и сервера должны быть высокими для обеспечения длительного периода бездействия, но при этом важно обнаруживать исчезновение сервера с целью освобождения всех ресурсов, связанных с его соединением (и сессией клиента). Один из типичных сценариев использования — принудительное завершение неактивных соединений сервера при слишком медленных проверках работоспособности или во время мягкого перезагрузки, поскольку при этом проверки работоспособности отключаются. Аргумент — задержка, выраженная в миллисекундах по умолчанию. Работает только для обычных TCP соединений и игнорируется для других протоколов.
tfo
Может использоваться в следующих контекстах: tcp, http, log, peers, ring
Этот параметр включает использование TCP fast open при подключении к серверам на системах, поддерживающих его (настоящим образом — только ядро Linux >= 4.11). Дополнительную информацию о TCP fast open см. в опции “tfo” bind. Обратите внимание, что при использовании tfo необходимо также использовать ключевые слова “conn-failure”, “empty-response” и “response-timeout” для “retry-on”, иначе HAProxy не сможет повторно подключаться при сбое. См. также “no-tfo”.
track [<backend>/]<server>
Допустимые контексты: tcp, http, log
Этот параметр позволяет устанавливать текущее состояние сервера путём отслеживания другого сервера. Возможна отслеживание сервера, который сам отслеживает другой сервер, при условии, что в конце цепочки сервер имеет включённые проверки работоспособности. Если <backend> не указан, используется текущий сервер. Если используется disable-on-404, то этот параметр должен быть включён на обоих прокси.
Пример:
tls-tickets
Может быть использован в следующих контекстах: tcp, http, log, peers, ring
Эта опция может быть использована как “server” настройка для сброса любой “no-tls-tickets” настройки, которая бы была наследована из “default-server” директивы как значение по умолчанию. Механизм билетов TLS используется только до TLS 1.2. Противоречие безопасности при передаче ключей обеспечивается при использовании TLS билетов, если ключи билетов периодически пересылаются (через перезагрузку или с помощью “tls-ticket-keys”). Она также может быть использована как “default-server” настройка для сброса любой предыдущей “default-server” “no-tls-tickets” настройки.
verify [none|required]
Может быть использован в следующих контекстах: tcp, http, log, peers, ring
Этот параметр доступен только тогда, когда встроенная поддержка OpenSSL. Если установлено значение ’none’, сертификат сервера не проверяется. В остальных случаях сертификат, предоставляемый сервером, проверяется с помощью ЦА из ‘ca-file’ и опциональных CRL из ‘crl-file’ после проверки того, чтобы имена, указанные в атрибутах subject и subjectAlternateNames сертификата, совпадали с именем, переданным с помощью директивы “sni”, или в случае отсутствия такого имени — с статическим именем хоста, переданным с помощью директивы “verifyhost”. При отсутствии совпадающего имени имена в сертификате игнорируются. Поэтому, в отсутствие SNI, важно использовать “verifyhost”. При неудаче проверки рукопожатия процесс прерывается. Критически важно проверять сертификаты серверов при подключении к серверам с помощью SSL, иначе коммуникация подвержена атакам типа «человек в середине», что делает SSL полностью бесполезным. Если в секции global отсутствует “ssl_server_verify”, по умолчанию “verify” установлено на “required”.
verifyhost <hostname>
Может использоваться в следующих контекстах: tcp, http, log, peers, ring
Этот параметр доступен только тогда, когда встроенная поддержка OpenSSL, и действует только при наличии ‘verify required’. Данный директивы устанавливает статический именной хост, по которому проверяется сертификат сервера, если при подключении к серверу не использован SNI. Если не используется SNI, это является единственным способом включения проверки имени хоста. Указанное статическое имя хоста также применяется при проверке работоспособности (при проверке работоспособности не предоставляется значение SNI). Если ни одно из имен хостов в сертификате сервера не совпадает с указанным именем, подключение прерывается. Имена хостов в сертификате сервера могут включать шаблоны. См. также опции “verify”, “sni” и “no-verifyhost”.
weight <weight>
Допустимые контексты: tcp, http
Параметр “weight” используется для настройки веса сервера по сравнению с другими серверами. Все серверы получают нагрузку пропорционально их весу относительно суммы всех весов, поэтому чем выше вес, тем выше нагрузка. По умолчанию вес равен 1, а максимальное значение — 256. Значение 0 означает, что сервер не участвует в балансировке нагрузки, но всё же принимает постоянные соединения. Если этот параметр используется для распределения нагрузки в соответствии с возможностями сервера, рекомендуется начинать с значений, которые могут как увеличиваться, так и уменьшаться, например, в диапазоне от 10 до 100, чтобы оставить достаточный запас как сверху, так и снизу для последующих корректировок.
ws { auto | h1 | h2 }
Допустимые контексты: http
Этот параметр позволяет настроить протокол, используемый при пересылке потоков WebSocket. Это особенно полезно при использовании бэкенда HTTP/2 без поддержки WebSocket H2 через RFC8441.
По умолчанию используется режим “auto”. Он будет использовать тот же протокол, что и основной. Единственное отличие — при использовании ALPN. В этом случае может попытаться понизить версию ALPN до «http/1.1» только для потоков WebSocket, если настроенный сервер ALPN содержит такую версию.
Значение “h1” используется для принудительного задания HTTP/1.1 для потоков WebSocket, через ALPN если SSL ALPN включено для сервера. Аналогично, “h2” может быть использован для принудительного задания HTTP/2.0 WebSocket. Используйте это значение с осторожностью: сервер должен поддерживать RFC8441 или при пересылке WebSocket HAProxy выдаст ошибку.
Примечание, что NPN не учитывается, так как его использование было отменено в пользу расширения ALPN
См. также “alpn” и “proto”.
5.3. Определение IP-адреса сервера через DNS
HAProxy позволяет использовать имя хоста в строке сервера для получения его IP-адреса с помощью серверов имен.
По умолчанию HAProxy разрешает имя при парсинге конфигурации, при запуске и кэширует результат на протяжении жизни процесса. В некоторых случаях это недостаточно, например, в Amazon, где IP-адрес сервера может измениться после перезагрузки или ELB виртуальный IP может изменяться в зависимости от текущей нагрузки.
В этом разделе описывается, как можно настроить HAProxy для выполнения разрешения имени сервера в режиме работы.
Независимо от того, включена ли разрешение имени сервера в режиме работы, по умолчанию HAProxy выполняет первое разрешение при запуске во время парсинга конфигурации через libc, если не отключено параметром “init-addr”.
5.3.1. Общий обзор
Как мы видели в введении, разрешение имени в HAProxy происходит на двух разных этапах жизненного цикла процесса:
Несколько других событий могут инициировать разрешение имени в режиме работы:
- при завершении проверки работоспособности сервера с тайм-аутом соединения: это может быть связано с тем, что сервер получил
новый IP-адрес. Следовательно, необходимо инициировать разрешение имени, чтобы узнать новый IP.
При использовании резолверов имя сервера может быть либо именем хоста, либо меткой SRV. HAProxy считает всё, что начинается с подчёркивания, меткой SRV. Если указана метка SRV, то соответствующие записи SRV будут получены с сервера DNS, а указанные имена хостов будут использоваться. Метка SRV будет проверяться периодически, и при добавлении или удалении серверов HAProxy автоматически выполнит аналогичные действия.
Несколько важных моментов, на которые следует обратить внимание:
все серверы именований запросываются в это же время. HAProxy обрабатывает первый валидный ответ.
Решение считается недействительным (NX, тайм-аут, отклонено), когда все серверы возвращают ошибку.
Клиент DNS, реализованный в HAProxy, является очень простым и не сможет понять большое количество опций и сложных настроек, которые может обрабатывать резолвер операционной системы. Следовательно, за исключением действительно простых конфигураций, в которых сервер, известный только по своему FQDN, имеет ровно один IP-адрес в любой момент времени и может периодически обновлять его (например, после перезагрузки), настоятельно рекомендуется избегать смешивания разрешения имён на этапе инициализации, основанного на библиотеке libc, с разрешением во время выполнения, основанным на DNS. Такие конфигурации известны своей склонностью к сбоям при обновлении адресов. В заключение, если вы не уверены в том, что делаете, всегда следует исключать “libc” из “init-addr” при использовании “resolvers” в строке сервера.
5.3.2. Секция resolvers
Эта секция посвящена информации о хостах, связанной с разрешением имен в HAProxy. Могут быть столько секций resolvers, сколько необходимо. Каждая секция может содержать множество серверов разрешения имен.
При запуске HAProxy пытается сгенерировать секцию resolvers, названную “default”, если в конфигурации нет секции с таким названием. Эта секция по умолчанию используется httpclient и использует ключевое слово parse-resolv-conf. Если HAProxy не может автоматически сгенерировать эту секцию, не выдается ни ошибки, ни предупреждения.
Когда в секции resolvers настроено несколько серверов разрешения имен, HAProxy использует первый валидный ответ. В случае невалидных ответов, только последний считается валидным. Цель — обеспечить возможность медленному серверу передать корректный ответ после того, как быстрый, неисправный или устаревший сервер вернул невалидный ответ.
Когда каждый сервер возвращает разный тип ошибки, HAProxy использует только последнюю ошибку. На этой ошибке применяется следующая обработка:
Например, при настройке 2 серверов в секции resolvers, возможны следующие сценарии:
Первый ответ является действительным и применяется немедленно, второй ответ игнорируется
Первый ответ является недействительным, второй — действительным, затем применяется второй ответ
Первый ответ — NX домен, второй — обрезанный ответ, затем HAProxy повторяет запрос с новым типом
Первый ответ — NX домен, второй — тайм-аут, затем HAProxy повторяет запрос с новым типом
Запрос истек по тайм-ауту для обоих серверов, затем HAProxy повторяет запрос с тем же типом запроса
Поскольку DNS сервер может не отвечать на все IP в одном DNS запросе, HAProxy хранит кэш предыдущих ответов, ответ считается устаревшим после <hold obsolete> секунд без возврата IP.
resolvers <resolvers id>
Создаёт новый список серверов имени, помеченный <resolvers id>. Как указано выше, специальный сервер имени “default” всегда существует и будет автоматически создан, если не объявлен явно; это будет тот, на который зависят внутренние службы, такие как httpclient. Объявление записи “default” повлияет на то, как такие службы выполняют разрешение имен.
Секция resolvers принимает следующие параметры:
accepted_payload_size <nb>
Определяет максимальный размер полезной нагрузки, который принимается HAProxy и объявляется всем серверам имен, настроенным в этой секции разрешителей. <nb> измеряется в байтах. Если не задано, HAProxy объявляет 512. (минимальное значение, определённое RFC 6891)
Примечание: максимально допустимое значение — 65535. Рекомендуемое значение для UDP — 4096, и не рекомендуется превышать 8192, за исключением случаев, когда вы уверены, что ваша система и сеть способны справиться с этим (значение, превышающее 65507, не имеет смысла, поскольку это максимальный размер полезной нагрузки UDP). Если вы используете только TCP серверы имен для обработки больших DNS ответов, следует установить это значение на максимум: 65535.
nameserver <name> <address>[:port] [param*]
Используется для настройки сервера имён. <name> сервера имён должен быть уникальным. По умолчанию <address> считается типом датаграммы. Это означает, что при настройке IPv4 или IPv6 без специальных префиксов адресов (параграф 11) будет использоваться протокол UDP. Если используется префикс адреса потокового протокола, сервер имён будет считаться потоковым сервером (TCP, например), и параметры “server”, указанные в параграфе 5.2, которые относятся к разрешению DNS, будут учитываться.
Примечание: в настоящее время в режиме TCP запросы 4 пайплайнятся по одному соединению. Каждые 5 секунд удаляются пакеты неактивных соединений. Параметр “maxconn” можно настроить для ограничения количества одновременных соединений, а параметр TLS также должен быть доступен, если сервер его поддерживает.
parse-resolv-conf
Добавляет все именные серверы, найденные в /etc/resolv.conf, в список именных серверов этого резолвера. Упорядочиваются как если бы каждый именной сервер из /etc/resolv.conf был индивидуально помещён в секцию резолвера на место этой директивы.
hold <status> <period>
При получении ответа DNS <status> определяется, следует ли изменить состояние сервера с UP на DOWN. Для этого проверяется, был ли получен любой действительный статус в течение последних <period>, чтобы противодействовать недавно полученному невалидному статусу.
`<status>`: последний статус разрешения имени.
nx После получения статуса NXDOMAIN проверяется наличие любого действительного статуса в периоде завершения.
refused После получения статуса REFUSED проверяется наличие любого действительного статуса в периоде завершения.
timeout После истечения "timeout retry" проверяется наличие любого действительного статуса в периоде завершения.
other После получения любого другого невалидного статуса проверяется наличие любого действительного статуса в периоде завершения.
valid Применяется только к действиям "http-request do-resolve" и "tcp-request content do-resolve". Определяет период, в течение которого сервер будет сохранять действительный ответ перед запуском нового разрешения. Не влияет на динамическое разрешение серверов.
obsolete Определяет период ожидания до удаления устаревших записей DNS после получения обновлённой записи ответа. Применяется к записям SRV.
`<period>`: количество времени в прошлом, в течение которого должен быть получен действительный ответ. Следует формату времени HAProxy и по умолчанию измеряется в миллисекундах.
Для сервера, который зависит от динамической разрешения DNS для определения своего IP-адреса, получение недопустимого ответа DNS, например, NXDOMAIN, приведёт к изменению состояния сервера с UP на DOWN. Параметры hold определяют, насколько далеко в прошлое искать допустимый ответ. Если допустимый ответ был получен в течение <period>, недавний недопустимый статус будет проигнорирован.
Если в период завершения не был получен допустимый ответ, сервер будет помечен как DOWN. Например, если “hold nx 30s” установлен и последний полученный ответ DNS был NXDOMAIN, сервер будет помечен как DOWN, если в последних 30 секундах не был получен допустимый ответ.
Сервер в состоянии DOWN будет немедленно помечен как UP при получении допустимого статуса от сервера DNS.
Существует отдельное поведение для “hold valid” и “hold obsolete”.
По умолчанию значение для «допустимого» — 10s, для «устаревшего» — 0s и для остальных — 30s.
resolve_retries <nb>
Определяет количество <nb> запросов, которые необходимо отправить для разрешения имени сервера, прежде чем отказаться. Значение по умолчанию: 3
Повторный запрос происходит при тайм-ауте наименования сервера или при завершении полной последовательности переключения при отказе DNS и необходимости перезапуска с типом запроса ANY.
timeout <event> <time>
Определяет тайм-ауты, связанные с разрешением имен <event>: событие, на котором применяется период тайм-аута <time>. Доступные события: - resolve: время, при котором запускается разрешение имен, если не применяется другое время. Значение по умолчанию: 1s - retry : время между двумя DNS запросами, если не получены действительные ответы. Значение по умолчанию: 1s <time>: время, связанное с событием. Оно следует формату времени HAProxy. <time> выражено в миллисекундах.
Пример: