☰

nginx обратный ssl прокси с несколькими поддоменами

tag-icon • tag-icon nginx reverse-proxy ssl-certificate
nginx обратный ssl прокси с несколькими поддоменами

Я пытаюсь найти пример конфигурации высокого уровня для моей текущей ситуации. У нас есть wildcard SSL-сертификат для нескольких поддоменов, которые находятся на нескольких внутренних серверах IIS.

site1.example.com (X.X.X.194) -> IISServer01:8081
site2.example.com (X.X.X.194) -> IISServer01:8082
site3.example.com (X.X.X.194) -> IISServer02:8083

Я ищу способ обработки входящего трафика SSL через одну запись сервера, а затем передать определенный домен внутреннему приложению IIS. Кажется, у меня есть 2 варианта:

  1. Закодируйте раздел местоположения для каждого поддомена (судя по примерам, которые я нашел, это выглядит запутанно)

  2. Перенаправьте незашифрованный трафик обратно на тот же сервер nginx, настроенный с разными записями сервера для каждого имени хоста поддомена. (По крайней мере, это кажется возможным вариантом).

Моя конечная цель — консолидировать большую часть нашего SSL-трафика, чтобы он проходил через nginx, чтобы мы могли использовать HAProxy для балансировки нагрузки серверов.

Будет ли подход №2 работать в nginx, если я правильно настрою записи proxy_set_header?

Я представляю себе что-то вроде этого в моем окончательном конфигурационном файле (используя подход №2):

server {
  listen Y.Y.Y.174:443; #Internally routed IP address
  server_name *.example.com;

  proxy_pass http://Y.Y.Y.174:8081;
}

server {
  listen Y.Y.Y.174:8081;
  server_name site1.example.com;

  -- NORMAL CONFIG ENTRIES --

  proxy_pass http://IISServer01:8081;
}

server {
  listen Y.Y.Y.174:8081;
  server_name site2.example.com;

  -- NORMAL CONFIG ENTRIES --

  proxy_pass http://IISServer01:8082;
}

server {
  listen Y.Y.Y.174:8081;
  server_name site3.example.com;

  -- NORMAL CONFIG ENTRIES --

  proxy_pass http://IISServer02:8083;
}

Это похоже на способ, но я не уверен, что это лучший способ. Я упускаю более простой подход к этому?

решение1

Я бы сделал что-то вроде этого (проверено с nginx 1.4.2, кажется, работает):

server {
  listen 127.0.0.1:443 ssl;
  server_name site1.example.com;

  include common.conf;

  location / {
    proxy_pass http://127.0.0.2:8081;
  }
}

server {
  listen 127.0.0.1:443 ssl;
  server_name site2.example.com;

  include common.conf;

  location / {
    proxy_pass http://127.0.0.2:8082;
  }
}

server {
  listen 127.0.0.1:443 ssl;
  server_name site3.example.com;

  include common.conf;

  location / {
    proxy_pass http://127.0.0.3:8083;
  }
}

По крайней мере, вот это common.conf:

ssl on;
ssl_certificate  /path/to/cert;
ssl_certificate_key  /path/to/key;

решение2

Хотите верьте, хотите нет, но вы можете сделать это:

ssl_session_cache shared:SSL:2m;
ssl_session_timeout 5m;

server {
    listen Y.Y.Y.174:443 default_server ssl;
    server_name _;
    ssl_certificate /etc/pki/tls/certs/server.chained.crt;
    ssl_certificate_key /etc/pki/tls/private/server.key;
}

server {
    listen Y.Y.Y.174:443 ssl;
    server_name site1.example.com;
    [...]
    proxy_pass http://IISServer01:8081;
}

server {
    listen Y.Y.Y.174:443 ssl;
    server_name site2.example.com;
    [...]
    proxy_pass http://IISServer01:8082;
}

server {
    listen Y.Y.Y.174:443 ssl;
    server_name site3.example.com;
    [...]
    proxy_pass http://IISServer02:8083;
}

Никаких включений, сертификат загружается в память только один раз, и сеанс должен оставаться кэшированным даже при переходе пользователя из одного поддомена в другой, что экономит вам массу ресурсов на подтверждение соединения.

Я не могу найти никакой документации, кромеэтот пост о сбое серверачтобы предположить, почему это работает, но я могу вас заверить, что это так.

Связанный контент