SSL-сертификат на балансировщике нагрузки или сервере
У меня есть балансировщик нагрузки, распределяющий трафик между двумя серверами, все общедоступные URL-адреса имеют префикс https.
Я хочу сгенерировать ssl-сертификат с подстановочными знаками, но не уверен, что лучше разместить в балансировщике нагрузки или на двух серверах? какая рекомендация? каковы преимущества и различия.
Спасибо
Очень распространенная практика (я бы не сказал стандарт ) - разместить / настроить сертификат в балансировщике нагрузки, а не на внутренних серверах. Почему? Это позволяет подсистеме балансировки нагрузки обрабатывать накладные расходы на согласование / завершение TLS (, т.е. память / ЦП для сообщений TLS), вместо того, чтобы серверы внутренних приложений использовали свои ЦП для этого шифрования, в в дополнение к обеспечению поведения приложения. Таким образом, обычно "за" наличие завершения TLS перед вашими серверами приложений.
Это также позволяет кэшировать сеанс TLS на одном маршруте к вашим серверам ( т.е. через балансировщик нагрузки) , что означает больше шансов использовать кэшированный сеанс TLS. Если, с другой стороны, вы настроили сертификат на каждом из внутренних серверов, то эти серверы (предположительно) будут иметь свои собственные отдельные кеши сеансов TLS; клиент может (и не может) быть направлен балансировщиком нагрузки на внутренний сервер с его сеансом TLS в кэше.
Краткая версия: настройка сертификата в балансировщике нагрузки - это обычно рекомендуемый подход.
Надеюсь, это поможет!
Если вы не загружаете сертификат в балансировщик нагрузки, вы можете только балансировать нагрузку на соединения TCP / IP, поскольку сам трафик зашифрован.
Загрузив сертификат в балансировщик нагрузки, вы получите возможность делать там более интересные вещи, в зависимости от возможностей вашего балансировщика нагрузки:
- Создавать постоянные / закрепленные сеансы сеанса, чтобы последующие запросы от определенного пользователя всегда будут перенаправлены на одну и ту же обратнуюконечный сервер (например, на основе файла cookie сеанса), который намного надежнее, чем использование исходного IP-адреса в качестве основы для привязки, что является единственным вариантом, когда у вас нет сертификата на LB.
- Направлять разные URL-адреса на разные пулы внутренних серверов, т. Е. Направлять
example.com/app-1на другие серверы приложений, чем те, которые используются дляexample.com/app-2 - и т.д.
Довольно часто вы разрываете соединение TLS / SSL на LB и получаете незашифрованный трафик между LB и внутренними серверами, но ничто не мешает вам установить там второе соединение TLS / SSL, если ваши требования безопасности таковы.
Как упоминал TJ, установите SSL CERTS на балансировщик нагрузки, это может справиться с работой и разгрузить пользователей на внутренних серверах.
В Digital Ocean есть отличный пример / руководство по установке сертификатов Lets Encrypt на прокси-сервере CentOS 7 HA