Требуется пояснение для восходящего SSL на обратном прокси-сервере nginx
Я читал документы nginx относительно обратного прокси и защита ssl-соединений с вышестоящими серверами но я все еще не понимаю, какие сертификаты ssl куда идут. Во многих примерах, которые я нахожу, nginx проксирует localhost, но в моей ситуации конечные точки находятся на разных серверах, портах и физических местах.
Я бы хотел, чтобы на сервере nginx было разрешено несколько доменов. Каждый из этих доменов имеет сертификат ssl на своем текущем сервере для его фактического доменного имени.
Прямо сейчас у меня каждый сервер работает в собственном сетевом и физическом местоположении, но я хотел бы иметь единую точку для управления этими конечными точками.
Мой конечный результат должен выглядеть так
client
|
nginx
https://example1.com
https://example2.com
https://example3.com
x.x.x.x
|
-----------------------------------------
| | |
https://example1.com https://example2.com https://example3.com
a.b.c.d:1234 e.f.g.h:5678 i.j.k.l:9012
Сейчас https://example1.com разрешается в a.b.c.d: 1234, у которого установлен собственный сертификат ssl. Поскольку мне нужно сообщить клиентам, что сервер nginx обслуживает домен example1.com, я думаю, мне нужно, чтобы ssl example1.com был перемещен на внешний сервер nginx, верно? Если я это сделаю, какой сертификат ssl я буду использовать на a.b.c.d: 1234 для поддержания безопасного восходящего соединения?
В документации nginx написано client.crt и server.crt, но центр сертификации использует домен для их регистрации. Что такое клиент и сервер в ситуации обратного прокси? Для меня клиент - это браузер, делающий запрос.
Какие сертификаты ssl отправляются на обратный прокси?
Редактировать:
Я уже знаю, что вы можете выглядеть так, как будто у вас есть безопасное соединение, просто разместив сертификаты на основе URL-адреса на прокси-сервере. Я надеюсь узнать, какие ssl-сертификаты поставить на внутренние серверы. Просто повторно использовать их соответствующие сертификаты? Мог example1.com.crt заходить и на прокси-сервер, и на бэкэнд-сервер?
Сертификат домена должен находиться там, где его «видят» клиенты, поэтому в вашем случае, если вы хотите, чтобы из Интернета был доступен только сервер nginx, все общедоступные сертификаты должны идти на сервер nginx.
Если вы хотите защитить внутренние соединения, вы можете использовать любой сертификат на этих серверах. Вы даже можете использовать самозаверяющие и отключить проверку сертификатов на сервере nginx, но, вероятно, разумнее создать свой собственный ЦС и распространять сертификаты на бэкэнды.
Ваша конфигурация будет выглядеть точно так, как вы нарисовали, за исключением того, что внутренние серверы будут иметь внутренний сертификат, соответствующий их «внутреннему» имени:
client
|
nginx
(https://example1.com)
(https://example1.com)
(https://example1.com)
|
+---------------------------------------+-----------------------------------+
| | |
| | |
https://example1.internal.local/ https://example2.internal.local/ https://example3.internal.local/
a.b.c.d e.f.g.h i.j.k.l
Если внутренние серверы доступны из Интернета, вы можете настроить брандмауэр их портов https, чтобы только сервер nginx мог их подключать.
Что касается вашего вопроса о клиенте и сервере: в сети клиент - это тот, кто инициирует соединение. Итак, в вашей настройке браузеры являются клиентами, а сервер nginx одновременно является клиентом и сервером: это сервер для браузеров, но он является клиентом для внутренних серверов.
Есть довольно много возможностей, вот 2:
Либо ваши клиенты общаются только с вашим обратным прокси-сервером (1), и nginx будет обрабатывать соединения с вышестоящими серверами, либо вы позволите nginx указать своим клиентам подключаться к другим серверам (2), которым нужен общедоступный IP / DNS / сертификаты. тогда их собственные.
Вы можете (и, возможно, должны) также зашифровать трафик между обратным прокси-сервером и вышестоящими серверами с помощью сертификатов, в зависимости от схемы вашей сети. Для этого вам по-прежнему нужен сертификат для каждого вышестоящего сервера, но они также могут быть самозаверяющими (но не должны).
Если вы используете что-то вроде Let's Encrypt, создание сетей SAN на сертификатах в настоящее время довольно просто, поэтому я обычно выбираю вариант 1.