Что делает TLS passthrough в HAProxy?
TLS passthrough передаёт зашифрованный TCP-поток backend-серверу без завершения TLS на HAProxy. Сертификат выбирает и показывает сам backend, там же выполняются расшифровка и проверка прикладного протокола. HAProxy видит соединение и часть незашифрованного ClientHello, но не HTTP-заголовки внутри TLS.
Схема полезна, когда несколько TLS-сервисов делят один адрес и порт, а ключи должны оставаться на backend. Она не заменяет TLS termination: без расшифровки нельзя маршрутизировать по URL, добавлять HTTP-заголовки или применять обычные HTTP middleware.
Telegram-flow
Хотите подключить VPN без ручных настроек?
Откройте бота: он покажет trial или тариф, отправит файл подключения и QR-код прямо в Telegram.
Почему frontend и backend должны работать в mode tcp?
Официальная документация HAProxy требует mode tcp в обеих секциях, когда проксируется сырой TCP-поток. На bind не добавляют параметр ssl, иначе HAProxy сам завершит TLS и passthrough исчезнет. Backend получает те же TLS-байты, которые отправил клиент.
Смешение mode http и непрозрачного TLS обычно заканчивается ошибкой протокола: HAProxy ждёт HTTP после расшифровки, а получает ClientHello. Поэтому сначала выбирают архитектуру, затем проверяют, где находится сертификат. Один и тот же frontend не должен случайно одновременно изображать termination и passthrough.
Чем req.ssl_sni отличается от ssl_fc_sni?
req.ssl_sni читает SNI непосредственно из сырого ClientHello в буфере запроса и предназначен для content inspection в TCP-режиме. ssl_fc_sni возвращает имя из TLS-соединения, которое было расшифровано HAProxy. Для passthrough нужен первый вариант, потому что HAProxy не является TLS endpoint.
Ошибка в выборе fetch приводит к пустому значению и постоянному попаданию в default backend. Название ACL может быть любым, но источник данных должен соответствовать архитектуре. Регистр имени обычно сравнивают без учёта регистра, а правила располагают от точных доменов к общему fallback.
Зачем нужен tcp-request inspect-delay?
ClientHello может прийти не одним TCP-сегментом, поэтому HAProxy даёт буферу ограниченное время на получение данных. tcp-request inspect-delay задаёт верхнюю границу ожидания, а условие req.ssl_hello_type 1 позволяет принять содержимое после появления полного клиентского приветствия.
Слишком короткое ожидание увеличивает число ошибочных fallback при медленной сети, а слишком длинное задерживает соединения, в которых нужных данных не будет. Начальное значение проверяют на стенде и сопоставляют с логами. Это лимит ожидания, а не гарантированная задержка для каждого клиента.
Как выглядит безопасный пример маршрутизации по SNI?
На тестовом frontend можно принять TCP на локальном порту 8443, дождаться ClientHello и направить app.example.com в один backend, а api.example.com — в другой. Оба backend используют адреса из тестовой сети и завершают TLS своими сертификатами. Все остальные имена идут в явно заданный default backend.
Такой пример не создаёт открытый прокси: список backend фиксирован, клиент не выбирает произвольный адрес назначения. Перед применением конфигурацию проверяют штатной командой HAProxy, затем запускают на непубличном стенде. Реальные ключи и production-адреса в учебный файл не копируют.
Что произойдёт, если SNI отсутствует или скрыт?
Не каждый TLS-клиент обязан передавать подходящее имя. Старое приложение может не отправить SNI, а технология ECH способна скрыть внутренний ClientHello от промежуточного узла. В таком случае маршрутизация по req.ssl_sni не получает ожидаемый домен и должна использовать безопасный fallback.
Нельзя считать SNI средством строгой аутентификации: клиент сам формирует это поле. Оно подходит для выбора заранее известных backend, но не подтверждает личность пользователя и не заменяет контроль доступа. Отдельно учитывают, что QUIC и HTTP/3 работают поверх UDP и не попадут в TCP frontend.
Как проверить TLS passthrough и как его откатить?
На стенде для каждого имени выполняют TLS-подключение с явным server name и сверяют сертификат, выбранный backend и журнал HAProxy. Дополнительно проверяют неизвестное имя, клиента без SNI и недоступный backend. Успех означает не только открытый порт, но и сертификат ожидаемого сервиса.
Для отката сохраняют прежний frontend и возвращают трафик на один проверенный backend либо предыдущий release конфигурации. После возврата снова проверяют сертификат и доступность. Если passthrough нужен лишь одному сервису, простая схема часто надёжнее сложной таблицы SNI.
Какие короткие ответы важно запомнить?
Может ли HAProxy менять HTTP-заголовки при TLS passthrough?
Нет. HTTP находится внутри зашифрованного потока и становится доступным только после TLS termination. Для изменения заголовков TLS должен завершаться на HAProxy или другом доверенном компоненте.
Где должен храниться сертификат при TLS passthrough?
Сертификат и приватный ключ находятся на backend, который завершает TLS. HAProxy передаёт поток и не нуждается в ключе этого домена для обычного passthrough.
Можно ли тем же frontend направлять HTTP/3 по SNI?
Нет, mode tcp обслуживает TCP, а HTTP/3 использует QUIC поверх UDP. Для него нужна отдельная архитектура с компонентом, который понимает UDP и QUIC.
Telegram-flow
Хотите подключить VPN без ручных настроек?
Откройте бота: он покажет trial или тариф, отправит файл подключения и QR-код прямо в Telegram.