Использовать HTTPS на Varnish не так уж и сложно. Хотя Varnish изначально не предлагает TLS, он облегчает завершение TLS.

В 2015 году вышел Varnish Сцепка, очень мощный прокси TLS, который обрабатывает завершающий TLS и перенаправляет незашифрованный HTTP-трафик в Varnish.

Установка сцепки

Ты можешь скачать исходник с сайта Hitch и скомпилируем на нашем сервере. Если вы хотите использовать пакеты для установки Hitch, вы можете запустить следующую команду на Debian или Ubuntu:

apt-get install -y hitch

Настройка сцепки

После того, как вы установили Hitch, откройте /etc/hitch/hitch.conf и убедитесь, что вы используете следующую конфигурацию:

frontend = {
    host = "*"
    port = "443"
}

backend = "[localhost]:8443"

write-proxy-protocol-v2 = on

pem-file = "/etc/hitch/certs/example.com"

ciphersuites = "TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256"

ciphers = "ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384"

tls-protos = TLSv1.2 TLSv1.3

ecdh-curve = "X25519:prime256v1:secp384r1"

prefer-server-ciphers = false

Пожалуйста, положите свой сертификат /etc/hitch/certs и отрегулируйте pem-file директива в hitch.conf.

Реконфигурация Varnish

Ваша конфигурация времени выполнения Varnish, вероятно, содержит следующую информацию для прослушивания:

varnish -a :80

Это означает, что Varnish прослушивает соединения на порту 80. Чтобы убедиться, что HTTPS работает, мы добавим еще один порт прослушивания, но с определенной конфигурацией:

varnish -a :80 -a :8443,PROXY

Не забудьте перезагрузить Varnish после изменения настроек времени выполнения.

Вы заметите, что порт 8843 теперь также назначен Varnish. Он не используется для стандартного HTTP, но для HTTP с использованием ПРОКСИ протокол. В Hitch также была включена поддержка протокола PROXY.

Это гарантирует, что исходный IP-адрес клиента передается Varnish, независимо от количества дополнительных переходов, которые он должен пройти. Исходный IP-адрес клиента будет автоматически сохранен в X-Forwarded-For заголовок от Varnish.

Тип трафика, который обрабатывается портом. 8443 это HTTP-трафик, исходящий от Hitch и фактически завершенный HTTPS-трафик.

Определение запросов HTTPS

Hitch - это прокси TLS, он не понимает HTTP. Это означает, что он не может установить обычный X-Forwarded-Proto заголовок, чтобы указать, какой тип трафика был прекращен. К счастью, мы можем отследить, какой порт использовался.

Приведенный ниже код VCL обнаруживает запросы HTTP / HTTPS и назначает правильный X-Forwarded-Proto заголовок.

vcl 4.0;
import std;
sub vcl_recv {
    if (std.port(local.ip) == 8443) {
        set req.http.X-Forwarded-Proto = "https";
    } else {
        set req.http.X-Forwarded-Proto = "http";
    }
}

Многие фреймворки и системы CMS используют X-Forwarded-Proto заголовок для автоматического построения правильных схем URL. Тот факт, что мы устанавливаем этот заголовок в VCL, очень помогает.

Варианты кеширования на основе протокола

В кеше хранятся HTTP-ответы, а не HTTP-запросы. Поэтому, когда объект сохраняется в кеше, Varnish не знает, откуда он пришел: по HTTP или HTTPS URL. Если мы начнем кэшировать их без дополнительных мер, вы можете застрять в бесконечный цикл перенаправления если Varnish начинает кэшировать HTTP-версию объекта.

Чтобы этого не произошло, Varnish должен иметь вариант кеша по протоколу. Вы можете легко проинструктировать Varnish сделать это, вернув следующие Заголовок ответа HTTP в вашем бэкэнд-приложении:

Vary: X-Forwarded-Proto

Если по какой-то причине это невозможно, вы также можете продлить vcl_hash логика в вашем коде VCL. В этом случае добавьте следующий фрагмент:

sub vcl_hash {
  hash_data(req.http.X-Forwarded-Proto);
}