Nginx, с несколькими переадресованными доменами и сертификатом letsencrypt

Question

Nginx, с несколькими переадресованными доменами и сертификатом letsencrypt

Я пытаюсь настроить Nginx в качестве прокси-сервера пересылки для всех серверов dev, которые находятся за моим статическим IP-адресом.

Я читал этот вопрос: давайте зашифруем обратным прокси-сервером nginx

Уже, и это заставляет меня участвовать (то есть, я получаю хорошо известный каталог на одном из виртуальных серверов), но мои настройки достаточно различны, так что есть еще один шаг, который мне нужен, чтобы сделать эту работу, и до сих пор я не был в состоянии сделать этот шаг, любые эксперты Nginx, я уверен, мог бы сделать здесь руку.

Текущая настройка

В общем, в настоящее время у меня есть один статический IP, для целей этого вопроса давайте назовем его

1.2.3.4

В DNS-провайдерах моего хоста у меня есть 2 подстановочных DNS-маршрута (я, кстати, полностью их контролирую, поэтому, если все закончится так, что проще просто изменить записи DNS, чем использовать файл, то это то, что я делаю " я сделаю), 2 маршрута

*.example.com -> 1.2.3.4
*.anotherexample.com -> 1.2.3.4

Таким образом, в основном, независимо от того, что введено для этих двух доменов, они ВСЕГДА заканчиваются тем же статическим IP.

http://example.com/, http://doodah.example.com/, http://biscuits.anotherexample.com/ и т. д. ВСЕ прибывают в 1.2.3.4

Внутри этого IP-адреса через управляемый NAT порт, перенаправленный с 80 на внешнюю сторону до 80 на внутреннюю (я могу открывать другие при необходимости, например: 443), находится сервер, который имеет одну работу и только одну работу.

Этот сервер запускает Nginx на Ubuntu 16.04 LTS, проверяет имя входящего хоста и затем передает это соединение другому серверу.

Так например

http://www.example.com/ будет перенаправлен на сервер, на котором работает этот веб-сайт.

http://application.anotherexample.com/ будет перенаправлять прокси-сервер, на котором когда-либо сервер запускает приложение, связанное с этим именем хоста.

два виртуальных сервера являются особенными, поскольку они настроены на

*.example.com и *.anotherexample.com

Поэтому, если поступит запрос на idonetexist.example.com, он будет обслуживать веб-сайт по умолчанию для example.com, а noserverhere.anotherexample.com будет делать то же самое.

Это означает, что независимо от того, какой хост / поддомен находится на том, что получает этот прокси-сервер, что-то будет доставлено.

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

server {

  listen 80;

  server_name
    example.com
    www.example.com
    *.example.com;

  location /.well-known {
    alias /var/www/html/letsencrypt;
  }

  location / {

    proxy_pass_header Authorization;
    proxy_pass http://address.of-the.internal.example-webserver
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_http_version 1.1;
    proxy_set_header Connection "";
    proxy_buffering off;
    client_max_body_size 0;
    proxy_read_timeout 36000s;
    proxy_redirect off;
    access_log /var/log/nginx/example.com.log;
    error_log /var/log/nginx/example.com.log error;

  }
}

а также

server {

  listen 80;

  server_name
    anotherexample.com
    www.anotherexample.com
    *.anotherexample.com;

  location /.well-known {
    alias /var/www/html/letsencrypt;
  }

  location / {

    proxy_pass_header Authorization;
    proxy_pass http://address.of-the.internal.anotherexample-webserver
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_http_version 1.1;
    proxy_set_header Connection "";
    proxy_buffering off;
    client_max_body_size 0;
    proxy_read_timeout 36000s;
    proxy_redirect off;
    access_log /var/log/nginx/anotherexample.com.log;
    error_log /var/log/nginx/anotherexample.com.log error;

  }
}

Пока что все это работает отлично, и любые запросы от давайте зашифруем для проверки SSL-сертификатов в каталоге ".well-known" все работает, однако в этот момент мой вариант использования начинает отклоняться от исходного вопроса, который я связал на вершина моего вопроса.

Чтобы реализовать другие виртуальные серверы, например, указывающие на приложения, и другие субдомены на любом из двух моих зарегистрированных доменов, у меня есть несколько конфигураций виртуальных серверов, поэтому, например, у меня будут другие конфигурации, которые выглядят как следующий:

server {

  listen 80;

  server_name application1.example.com;

  location / {

    proxy_pass_header Authorization;
    proxy_pass http://internal.address.of-example-app-one
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_http_version 1.1;
    proxy_set_header Connection "";
    proxy_buffering off;
    client_max_body_size 0;
    proxy_read_timeout 36000s;
    proxy_redirect off;
    access_log /var/log/nginx/exampleappone.access.log;
    error_log /var/log/nginx/exampleappone.error.log error;

  }
}

server {

  listen 80;

  server_name application2.example.com;

  location / {

    proxy_pass_header Authorization;
    proxy_pass http://internal.address.of-example-app-two
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_http_version 1.1;
    proxy_set_header Connection "";
    proxy_buffering off;
    client_max_body_size 0;
    proxy_read_timeout 36000s;
    proxy_redirect off;
    access_log /var/log/nginx/exampleapptwo.access.log;
    error_log /var/log/nginx/exampleapptwo.error.log error;

  }
}

а также

server {

  listen 80;

  server_name application1.anotherexample.com;

  location / {

    proxy_pass_header Authorization;
    proxy_pass http://internal.address.of-anotherexample-app-one
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_http_version 1.1;
    proxy_set_header Connection "";
    proxy_buffering off;
    client_max_body_size 0;
    proxy_read_timeout 36000s;
    proxy_redirect off;
    access_log /var/log/nginx/anotherexampleappone.access.log;
    error_log /var/log/nginx/anotherexampleappone.error.log error;

  }
}

Когда новое приложение добавляется на внутренние серверы, создается новый файл конфигурации, основанный на показанных выше, с соответствующими изменениями в, а затем сохраняется в /etc/nginx/sites-available/ вместе со всеми другими файлами конфигурации.

Когда Nginx перезагружается, он выбирает новый файл и активирует его, так что приложение становится доступным.

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

Чего я пытаюсь достичь

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

К сожалению, отдельные конфигурации не покрываются SSL, и, более того, они не покрываются подстановочным SSL-символом.

То, что я хотел бы сделать, это найти способ, которым я могу получить *.example.com и *.anotherexample.com сертификат подстановки от давайте шифровать, все автоматизировано с помощью certbot, с автоматическими обновлениями.

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

На мой взгляд, что-то подсказывает мне, что ключом к этому является фактическое применение SSL к фактическому серверу "по умолчанию", который создает Nginx, но, поскольку я не могу назначить несколько сертификатов этому, я не верю, что буду возможность назначать сертификаты example.com и anotherexample.com на одном виртуальном сервере.

Мне нужно (я думаю) назначить сертификаты каждому из виртуальных серверов, обрабатывающих имя хоста *...., но затем этот сертификат распространяется на любые субдомены этого домена, которые имеют тот же домен верхнего уровня, что и домен по умолчанию (Если это имеет смысл)

Еще одна мысль, с которой я столкнулся (с которой я собираюсь поиграть после того, как я закончу набирать это), состоит в том, чтобы поставить перед собой другой прокси-сервер, единственная ответственность которого заключается в том, чтобы принять соединение, выслать сертификат, а затем передать соединение Nginx, который решает, с какого виртуального сервера отправлять соединение, я думаю, что в этом случае может быть HAProxy или что-то подобное.

В итоге

1) Если бы у меня не было отдельных файлов конфигурации, переопределяющих различные поддомены, оригинальный ответ на оригинальный вопрос работал бы отлично.

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

3) Мне нужен SSL для прозрачной работы с *... подстановочным SSL-сертификатом, и я не хочу создавать новый запрос SSL для каждого отдельного субдомена.

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

Обновление (22/08/2018)

Таким образом, используя рекомендации, данные Дрифтером в комментариях, я в конечном итоге придумал следующее для моих "виртуальных серверов с подстановочными символами", IE: серверы, которые будут реагировать на что-либо в домене, если для него нет более конкретной конфигурации субдомена.

server {

  listen 80;

  server_name
    example.com
    www.example.com
    *.example.com;

  location /.well-known {
    alias /var/www/html/letsencrypt;
  }

  location / {

    proxy_pass_header Authorization;
    proxy_pass http://internal-default-web-server-for-wildcard;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_http_version 1.1;
    proxy_set_header Connection "";
    proxy_buffering off;
    client_max_body_size 0;
    proxy_read_timeout 36000s;
    proxy_redirect off;

    access_log /var/log/nginx/example.access.log;
    error_log /var/log/nginx/example.error.log error;

  }
}

server {

  listen 443 ssl;

  server_name
    example.com
    www.example.com
    *.example.com;

  include "example-cert.inc";

  ssl_stapling on;
  ssl_stapling_verify on;

  # maintain the .well-known directory alias for renewals
  location /.well-known {
    alias /var/www/html/letsencrypt;
  }

  location / {

    proxy_pass_header Authorization;
    proxy_pass http://internal-default-web-server-for-wildcard;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_http_version 1.1;
    proxy_set_header Connection "";
    proxy_buffering off;
    client_max_body_size 0;
    proxy_read_timeout 36000s;
    proxy_redirect off;

    access_log /var/log/nginx/example.sslaccess.log;
    error_log /var/log/nginx/example.sslerror.log error;
  }
}

Как вы можете видеть, серверный блок теперь сопровождается серверным блоком, активирующим HTTPS, и вместо имени серверных сертификатов в файле есть

include "example-cert.inc"

В файле "example-cert" есть следующее

ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

Это приводит к загрузке Nginx, который включает эти имена сертификатов, когда он загружает конфигурацию VS, обрабатывающую эти домены подстановки.

Для всех других конфигов для поддоменов, которые имеют свои собственные места назначения, Iv'e сделал аналогичную вещь, главное отличие в том, что маршрут ".well-known" не включен, а также назначения прокси / сервера и имена файлов журнала разные.

Следуя информации в связанном вопросе и указав таким образом связь с сертификатами, поскольку сертификаты являются символами подстановки, я смог использовать один набор сертификатов для одного домена и другой набор сертификатов для другого домена.

Это на самом деле отвечает на мой вопрос, теперь мне просто нужно выяснить, как автоматизировать продление сертификата с помощью Let's encrypt. Поскольку я использую сертификат подстановочного знака, я не могу использовать какой-либо метод проверки, кроме "DNS-01", и это можно сделать только вручную, если только вы не используете службу DNS, предоставленную одним из поддерживаемых облачных провайдеров. с помощью плагина certbot.

Я не являюсь, мой DNS - это просто стандартный DNS, поэтому для каждого обновления мне нужно регенерировать новую запись TXT и изменять мои записи DNS, прежде чем обновление будет работать. Я могу полностью автоматизировать его, используя метод "webroot", но webroot не позволяет запрашивать сертификаты с подстановочными знаками, только фиксированный список из нескольких доменов.

Дрифтер, если ты напишешь свой комментарий как ответ, я дам тебе +10

2

nginx ssl lets-encrypt proxypass wildcard

Источник

shawty 21 авг '18 в 11:33

0 ответов

Другие вопросы по тегам nginx ssl lets-encrypt proxypass wildcard