Я пытаюсь пересылать SSL-запросы в зависимости от имени хоста дочерним демонам, работающим на моем компьютере. Чтобы добиться такого поведения, я попытался поэкспериментировать с nginx, который затем будет действовать как обратный прокси / маршрутизатор.
Мой файл конфигурации:
# ...
location / {
proxy_set_header Host $http_host;
if ($host = 'hostname01.example.com') { proxy_pass https://127.0.0.1:8001; }
if ($host = 'hostname02.example.com') { proxy_pass https://127.0.0.1:8002; }
if ($host = 'hostname03.example.com') { proxy_pass https://127.0.0.1:8003; }
if ($host = 'hostname04.example.com') { proxy_pass https://127.0.0.1:8004; }
if ($host = 'hostname01.example1.com') { proxy_pass https://127.0.0.1:8005; }
if ($host = 'hostname01.example2.com') { proxy_pass https://127.0.0.1:8006; }
if ($host = 'hostname01.example3.com') { proxy_pass https://127.0.0.1:8007; }
if ($host = 'hostname01.example4.com') { proxy_pass https://127.0.0.1:8008; }
# ...
}
Однако из-за природы SSL хост также зашифрован. При попытке запросить URL-адрес я получаю OpenSSL: error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol. Разрешение одному из демонов прослушивать порт 443 нормально работает.
Можно ли использовать nginx для такой настройки? Если нет, есть ли инструмент для достижения такого поведения?
Каждая подслужба использует собственный сертификат SSL. Можно было бы использовать уникальные машины для каждой службы и позволить им слушать сам 443, но этого я пытаюсь избежать.
Есть идеи по этому поводу?
Можно ли использовать nginx для такой настройки? Если нет, есть ли инструмент для достижения такого поведения?
Как вы уже отметили, ваш обратный прокси-сервер ничего не знает об URI или заголовках HTTP, поскольку эта информация заключена и зашифрована в протоколе TLS. Виртуальные хосты на основе имен не будут работать с TLS так легко.
Единственное заметное исключение из этого правила - расширение Server Name Indication для TLS, но для этого потребуется поддержка на сервере, а также все потенциальные клиенты. NGNIX поддерживает SNI на стороне сервера, но я полагаю, что для вашего приложения все равно потребуется разорвать TLS-соединения. HAproxy сможет принять решение на основе имени хоста, предоставленного SNI не завершая туннель - может быть, вы захотите разобраться в этом.
Если бы вы могли заполучить единый сертификат, в котором имя хоста * .example * .com´ комбинации как SAN атрибутов, вы можете настроить NGNIX с этим сертификатом для завершения всех туннелей, проверки заголовков и передачи трафика в зависимости от значений в качестве обратного прокси. Такое решение имеет шанс получить поддержку от большего числа потенциальных клиентов, но имеет очевидный недостаток: сертификат нужно перевыпускать каждый раз, когда вам нужно добавить или удалить имя хоста из списка.