Назад | Перейти на главную страницу

SSL-сертификат на балансировщике нагрузки или сервере

У меня есть балансировщик нагрузки, распределяющий трафик между двумя серверами, все общедоступные URL-адреса имеют префикс https.

Я хочу сгенерировать ssl-сертификат с подстановочными знаками, но не уверен, лучше ли разместить его в балансировщике нагрузки или на двух серверах? какая рекомендация? в чем преимущества и отличия.

Спасибо

Очень распространенная практика (я бы не сказал стандарт) заключается в размещении / настройке сертификата в балансировщике нагрузки, а не на внутренних серверах. Зачем? Это позволяет подсистеме балансировки нагрузки обрабатывать накладные расходы на подтверждение / завершение TLS (т.е. память / ЦП для сообщений TLS), вместо того, чтобы использовать серверы внутренних приложений их ЦП для этого шифрования, в дополнение к обеспечению поведения приложения. Таким образом, обычно "за" наличие прерывания TLS перед вашими серверами приложений.

Это также позволяет кэшировать сеанс TLS на одном маршруте к вашим серверам (т.е. через балансировщик нагрузки), что означает больше шансов использовать кэшированный сеанс TLS. Если, с другой стороны, вы настроили сертификат на каждом из внутренних серверов, то эти серверы (предположительно) будут иметь свои собственные отдельный Кеши сеансов TLS; клиент может (или не может) быть направлен балансировщиком нагрузки на внутренний сервер с помощью его Сеанс TLS кэширован.

Итак, краткая версия: настройка сертификата в балансировщике нагрузки является обычно рекомендуемым подходом.

Надеюсь это поможет!

Если вы не загружаете сертификат в балансировщик нагрузки, вы можете балансировать только TCP / IP-соединения, поскольку сам трафик зашифрован.

Загрузив сертификат на балансировщик нагрузки, вы получите возможность делать там еще много интересного, в зависимости от его возможностей:

  • Создавайте постоянные сеансы / закрепленные сеансы, чтобы последующие запросы от конкретного пользователя всегда направлялись на один и тот же внутренний сервер (например, на основе файла cookie сеанса), что намного надежнее, чем использование исходного IP-адреса в качестве основы для affinity - это единственный вариант, когда у вас нет сертификата на 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 😃