Рейтинг:0

Используйте прокси-сервер Nginx (обратный прокси-сервер) для обслуживания сайта, размещенного на Apache, с помощью SSL.

флаг us

Я искал на форумах (и в других местах в Интернете) и нашел связанную, но, казалось бы, не идентичную информацию. Надеюсь, я не дублирую здесь.

У меня есть сайт, работающий на сервере Apache. Он уже имеет SSL-сертификат (через LetsEncrypt) и работает без проблем.

Недавно я установил перед ним машину, на которой работает Nginx. Эта машина обслуживает три домена (с одним сертификатом от LetsEncrypt).

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

Настройка виртуального сервера, которая у меня есть на машине с выходом в сеть Nginx (через маршрутизатор):

сервер {
    слушать domain.pointing.to.apache.com: 443 ssl;
    имя_сервера домен.указывающий.на.apache.com;
    место расположения / {
        корень 192.168.11.14/var/www/html/;
        proxy_set_header X-Forwarded-Host $host:$server_port;
        proxy_set_header X-Forwarded-Server $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_pass домен.указывающий.на.apache.com;
    }
}

Но, конечно, Nginx это не нравится, и он не будет перезагружаться после добавления vs. Любые советы и т. д. будут высоко оценены.

Примечание. Я думаю, это очевидно, но 192.168.11.14 находится за моим маршрутизатором и не доступен напрямую в сети.

Джейсон

Изменить/обновить:

Важная информация отсутствует в моем первоначальном запросе:

  1. Компьютер Nginx, обращенный к сети, который я хочу переключить прокси на Apache, также обслуживает три поддомена моего основного домена, которые я хочу переключить прокси (sub1.mydomain.com, sub2.mydomain.com, sub3.mydomain.com). Все три используют один SSL-сертификат от LetsEncrypt.

  2. Сервер Apache в локальной сети также имел выданный LetsEncrypt сертификат, который обслуживал mydomain.com, пока я не поставил перед ним машину Nginx.

  3. Теперь я удалил сертификаты SSL на машине Apache, удалил виртуальный сервер https и настроил простой виртуальный сервер для порта 80.

  4. Моя настройка Nginx по умолчанию отправляет запросы на http //www.mydomain.com, который пока просто использует очень скучную html-страницу.

  5. Я установил SSL-сертификаты для домена https//www.mydomain.com в поле Nginx и хочу использовать рекомендацию, предоставленную Tero, для обратного прокси-запроса HTTPS на mydomain.com в локальный ящик Apache и обратно. Следующее:

сервер {

    слушать 443 ssl;
    ssl_certificate /etc/letsencrypt/live/www.mydomain.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/www.mydomain.com/privkey.pem;
    
    имя_сервера www.mydomain.com;
    место расположения / {
        proxy_set_header X-Forwarded-Host $host:$server_port;
        proxy_set_header X-Forwarded-Server $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        прокси_пароль https://192.168.11.14;
    }
}

Проблема в том, что я получаю сообщение об ошибке 502 Bad Gateway от машины Nginx... так что я предполагаю, что у меня что-то не так с настройками Nginx... Я приближаюсь, но не совсем там. Кроме того, я заметил, что попытки доступа www.mydomain.com без https больше не обслуживает скучную html-страницу... они переносятся/переписываются на https -> www.mydomain.com и к тому же 502 плохой шлюз.

Рейтинг:2
флаг us

В вашей конфигурации есть четыре ошибки:

  1. Слушать директива принимает только IP-адреса, если вы хотите выполнить привязку к определенному интерфейсу. Однако на практике вы прекрасно привязываетесь ко всем интерфейсам, поэтому слушать 443 SSL достаточно.

  2. корень location указывает путь файловой системы к файлам, которые nginx должен обслуживать напрямую. Поскольку ваш / местоположение должно быть обратно проксировано, указав корень вообще не нужен, так как nginx не обслуживает файлы. Итак, удалите корень директива.

  3. proxy_pass требуется URL-адрес вышестоящего сервера. В этом случае следует прокси_пароль https://192.168.11.4.

  4. Вы не указали сертификат TLS/закрытый ключ, их нужно указать с помощью ssl_certificate и ssl_certificate_key директивы.

Итак, в целом ваша конфигурация должна быть:

сервер {
    слушать 443 ssl;
    ssl_certificate /путь/к/сертификату;
    ssl_certificate_key /путь/к/ключу;
    
    имя_сервера домен.указывающий.на.apache.com;
    место расположения / {
        proxy_set_header X-Forwarded-Host $host:$server_port;
        proxy_set_header X-Forwarded-Server $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        прокси_пароль https://192.168.11.4;
    }
}

Если вы хотите использовать сертификаты Letsencrypt на обратном прокси-сервере, вам необходимо /.известный каталог с сервера:

сервер {
    слушать 80;

    расположение /.известный {
        try_files $uri =404;
    }

    место расположения / {
        # Перенаправление http-запросов на https
        вернуть 301 https://domain.pointing.to.apache.com;
    }
}

С этой конфигурацией вы можете запустить Certbot на обратном прокси-сервере, который затем правильно подтвердит право собственности на домен и получит сертификат/ключ.

Однако с этой конфигурацией вы не можете запустить Certbot на сервере, работающем в локальной сети. Если локальная сеть считается безопасной, то я предлагаю использовать http вместо https между обратным прокси-сервером и сервером локальной сети.

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

сервер {
    слушать 80;

    # Попробуйте обслуживать `.well-known` файлы из локальной файловой системы. Если не найдено, отправить на вышестоящий сервер
    расположение /.известный {
        try_files $uri @local;
    }

    местоположение @local {
        прокси_пароль http://192.168.11.4;
    }

    место расположения / {
        вернуть 301 https://domain.pointing.to.apache.com;
    }
}
флаг us
Теро, большое спасибо за помощь. К сожалению, я все еще должен делать что-то неправильно. Я отредактировал настройки, доступные для сайтов, включил и попытался перезагрузить Nginx, но получил следующую ошибку: «недопустимое количество аргументов в директиве ssl_certificate». SSL-сертификат находится на удаленном сервере (в данном примере 192.168.11.4), что не должно быть проблемой... или нет?
флаг us
Вам необходимо иметь сертификат на сервере, где установлен nginx, и прописать путь к файлам сертификата/ключа в соответствующих директивах.
флаг us
Теро, еще раз спасибо. Я боялся, что, наверное, так оно и было. Итак, моя проблема в том, что я не уверен, что понимаю, как установить сертификаты на мою машину, обращенную к сети, для домена, который должен обслуживаться из-за этой машины, обращенной к сети. Когда я запускаю certbot, он проверяет, чтобы убедиться, что я (моя машина и IP) отвечаю на IP (домен), для которого я пытаюсь получить сертификат, но моя сетевая машина не отвечает (я не думаю), потому что она не у вас нет настройки виртуального сервера для прослушивания этого домена.
флаг us
Кроме того, у меня может быть слишком сложная настройка, поскольку мой основной домен — это тот, который будет обслуживаться машиной в моей локальной сети через другую машину (с Nginx), которая обслуживает три поддомена из этого домена. (например, one.mydomain.com, two.mydomain.com и three.mydomain.com находятся на машине, обращенной к сети, а my domain.com находится на машине, расположенной за машиной, обращенной к сети). Почему это так устроено - долгая история... возможно ли вообще то, что я здесь преследую?
флаг us
Я добавил дополнительную информацию о том, как вы можете обрабатывать сертификаты в сети, обращенной к обратному прокси-серверу.
флаг us
Теро, еще раз спасибо за вашу помощь и терпение. Я чувствую, что я почти там. Я удалил сертификаты ssl с сервера локальной сети, переключился на обслуживание сайта по http (80), использовал обновленную информацию, предоставленную вами, плюс мне нужно было добавить server_name для certbot, чтобы идентифицировать домен, для которого я хотел получить сертификат. Все работало хорошо, но теперь я получаю ошибку 502 bad gateway, когда пытаюсь получить доступ к домену. Я обновлю свой запрос для более простого/четкого форматирования, чтобы показать, что у меня есть сейчас.
флаг us
Обратите внимание, что когда вышестоящий сервер находится поверх http, вам необходимо использовать proxy_pass http://192.168.11.4;. В вашей конфигурации есть https://192.168.11.4.
флаг us
Теро - еще раз спасибо. Да, это была проблема. Удаление 's' избавляет меня от ошибки 502, и теперь я получаю сообщение об ошибке "слишком много перенаправлений"... что, я думаю, связано с Apache на локальной машине... Теперь мне нужно поковыряться и посмотреть что я делаю неправильно на той стороне.
флаг us
Теро - Большое спасибо за вашу поддержку и терпение. Ошибка 502 была вызвана некоторыми оставшимися настройками, связанными с https, в моем файле виртуального сервера на машине Apache. Я полностью проглядел их в нижней части файла. Удалил все и работает отлично. :-) Нужно было внести некоторые незначительные коррективы в мое приложение, работающее за обратным прокси-сервером (proxy_client_headers), но как только они были сделаны, все заработало как шарм. В очередной раз благодарим за помощь. :-)

Ответить или комментировать

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