Я работаю над анализом периодического сбоя балансировки нагрузки в нашем приложении.
Ранее мы использовали AWS Elastic Load Balancer в следующей конфигурации:
HTTP 80 -> HTTP 80
HTTPS 443 -> HTTPS 443, presenting the same certificate as the backend IIS servers are
Теперь мы понимаем, что это немного нелепая установка (и LB, и сервер IIS выполняют одно и то же шифрование ... напрасная работа), и теперь это начало вызывать у нас некоторые проблемы. В частности, мы будем периодически видеть запрос на увеличение задержки ELB, принимать полные 60 секунд (тайм-аут по умолчанию), а затем сообщать об ошибке клиенту. Мы потратили много времени на то, чтобы убедиться, что всплеск задержки не связан с задержкой обработки в приложении.
Как уже упоминалось, теперь мы понимаем, что это странная установка. Например, более естественная конфигурация ELB отлично работает:
HTTP 80 -> HTTP 80
TCP 443 -> TCP 443, straight passthrough, all encryption happening on the IIS backend
На мгновение уменьшив масштаб, нам стало любопытно, сможем ли мы воспроизвести периодический сбой в плохой конфигурации HAProxy. Это означает, что HAProxy выполняет завершение SSL, а затем инициирует еще одно полное SSL-соединение с внутренним сервером. Опять же, мы понимаем, что это глупо, но проводим расследование с целью сравнения черного ящика, то есть ELB и HAProxy.
Вот простая конфигурация, которую я пробовал:
frontend https_frontend
bind *:443 ssl crt /etc/ssl/certs/ourpublicandprivatecert.pem
mode http
default_backend web_server
backend web_server
mode http
server s1 10.0.1.4:443 check
Затем, просматривая хост HAProxy, мы получаем:
504 Gateway Time-out
The server didn't respond in time.
Я предполагаю, что HAProxy волнуется из-за несоответствия в сертификате, но я не могу получить журналы, подтверждающие это. Другая возможность заключается в том, что из-за того, что это такая странная установка (смешивание завершения SSL и сквозной передачи), HAProxy просто не поддерживает ее, вместо этого вынуждая вас использовать более разумные пути сквозного завершения ИЛИ.
У кого-нибудь есть понимание?
Естественно, у вас есть последняя версия HAProxy со встроенной поддержкой OpenSSL.
Кажется, вам нужны дополнительные параметры для использования бэкэнда HTTPS. HAProxy по умолчанию пытается использовать обычное HTTP-соединение, независимо от номера порта.
В ssl параметр обеспечивает SSL-соединение:
server s1 10.0.1.4:443 ssl check check-ssl
Сертификат сервера по умолчанию не проверяется. Если вы хотите проверить это, вам нужно добавить verify required и ca-file <cafile> к серверной строке.
Подробнее о вариантах см. Здесь: http://cbonte.github.io/haproxy-dconv/configuration-1.5.html#5.2
Я думаю, что в вашей конфигурации бэкенда есть ошибка. Вместо этого попробуйте:
frontend https_frontend
bind *:443 ssl crt /etc/ssl/certs/ourpublicandprivatecert.pem
mode http
default_backend web_server
backend web_server
mode http
server s1 10.0.1.4:80 check
Изменяющийся порт! А также убедитесь, что ваш веб-сервер не перенаправляет с 80 на 443 порт, иначе это может запутать ситуацию.
Одно из преимуществ, которое вы получаете при использовании haproxy или ELB для завершения SSL, заключается в том, что он может вставлять заголовки, такие как X-Forwarded-For.
Если вы просто проходите через SSL с помощью опции tcp и не используете SSL на ELB или с HAProxy, нет возможности вставить заголовки, потому что поток зашифрован. Следовательно, у веб-сервера нет возможности сделать что-то разумное с запросом, и все клиентские соединения в журналах веб-сервера будут выглядеть так, как будто они исходят с IP-адреса elb или haproxy-сервера!
Поэтому не делегируйте шифрование бэкэнду, вместо этого делайте все это на ELB или экземпляре HAProxy и используйте X-Forwarded-For.