Вы всегда можете зашифровать трафик между любыми системами, принадлежащими определенной группе. Транспортный режим IPsec создан специально для этого. Неважно, какие роли берут на себя эти серверы, бэкэнд, фронтэнд и т. д., в данном случае они просто IP-узлы. Рассматривайте это как общее решение, которое делает «да, это возможно» действительным ответом на все вопросы, такие как «возможно ли зашифровать трафик между A и B». Однако иногда это не удобно и поэтому часто есть другие варианты.
Другие варианты зависят от с какой целью вам нужно это шифрование. Не отвечайте «просто для безопасности», нет такой вещи, как «просто безопасность». Существуют модели угроз и модели безопасности, которые справляются с этими определенными угрозами. Например, говоря простыми словами, модель угрозы для HTTP — это человек посередине, который может подслушивать и вводить свои собственные данные, выдавать себя за действительный сервер и/или действительный клиент; HTTPS разработан, чтобы сделать это невозможным, шифруя и подписывая все сообщения. MitM в лучшем случае может либо пропускать весь трафик без возможности прослушивания, либо вообще прерывать связь. И что ты защищаются, каковы ваши угрозы?
Ваша сеть между бэкендами и балансировщиками не является доверенной? Почему? В эти сети должны входить только балансировщики и бэкэнды и ничего больше, какие у вас там ненадежные акторы? Однако IPsec в транспортном режиме в этом случае является приемлемым решением, поскольку он будет шифровать все, что передается по сети.
Вы также можете использовать HTTPS между балансировщиком и бэкендами (и между самими бэкэндами). Все в порядке, ваш балансировщик завершит пользовательский HTTPS, увидит запрос и ответ в виде обычного текста, сможет их манипулировать (добавить/удалить/изменить заголовки), а также сможет выбрать бэкэнд и обработать его, проанализировав содержимое, например, выбрать один бэкенд для статического и другого для динамического контента. Тогда он установит Другая HTTPS-соединение с серверной частью. Единственными HTTPS-клиентами для бэкендов будут балансировщики и другие бэкенды, поэтому для них не важно использовать глобально признанные сертификаты. (Например, Google Frontends не проверяют сертификаты серверных частей HTTPS, расположенных внутри Google Cloud, поэтому даже самоподписанные сертификаты будут работать.) Вы можете создать свой собственный внутренний ЦС, выпустить сертификаты для всех серверных частей и балансировщиков и сделать их доверенными, установив этот сертификат ЦС в хранилище каждой системы. Только у балансировщиков должны быть настроены глобально действительные сертификаты и только на клиентской стороне. Автоматизация Let's Encrypt, скорее всего, также будет обязанностью этих балансировщиков, поскольку на них будут устанавливаться выданные сертификаты.
Вы не доверяете своему балансировщику нагрузки? Прохождение SSL может помочь, но у него есть и свои недостатки. В этой настройке балансировщик является одним из тех людей посередине, против которых был создан HTTPS. Таким образом, он не может получить доступ к деталям HTTP для балансировки запросов, даже зная значение заголовка http Host, чтобы различать vhosts; он не может вводить дополнительные заголовки прокси, такие как «прокси для» и т. д.; соединения защищены от него, как и ожидалось.Все, что он мог сделать, это, надеюсь, отследить соединение и в противном случае слепо пересылать пакеты на какой-то сервер. В этом случае вы не настраиваете на нем никакие сертификаты и даже не настраиваете имена серверов. Просто укажите IP бэкендов. Также в этом случае на всех бэкендах должны быть установлены действующие сертификаты, потому что априори неизвестно, какой бэкенд получит какой запрос.
