Nginx-прокси

Данная статья посвящена описанию механизмов работы модуля проксирования запросов пользовательских приложений (сокращенно Nginx-прокси). Под пользовательскими приложениями понимаются, например, phpMyAdmin, phpPGAdmin, Roundcube и т.д.

Работа модуля

Настройка модуля осуществляется в разделе Домены → WWW-домены, на странице изменения конфигурации домена;
Nginx-прокси может быть подключен к существующему веб-домену с SSL-сертификатом либо к новому на этапе создания;
Модуль может быть подключен к неограниченному количеству веб-доменов;
Изменена директория хранения настроек модуля. Настройки располагаются в файле /etc/nginx/conf.d/masterproxy.d/имя_домена.conf.

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

Перед настройкой Nginx-прокси рекомендуется сначала создать специального пользователя proxyuser, а затем — создать для него домен, который планируется использовать для проксирования.

Работа панели без использования Nginx-прокси

Без использования Nginx-прокси панель управления перенаправляет запросы к пользовательским приложениям на узел кластера, обслуживающий необходимую роль (например, "Почтовый сервер" для Roundcube). При этом дальнейшая работа пользователя с приложением будет производиться уже по адресу узла кластера (по умолчанию используется основной IP-адрес узла кластера, например https://192.0.2.1/roundcude).

Какие задачи решает Nginx-прокси

При предоставлении услуг shared-хостинга может понадобиться настроить доступ к пользовательским приложениям через единую точку входа. В качестве адреса точки входа будет использоваться указанное в настройках доменное имя. Это позволяет решить несколько проблем:

Доступ ко всем пользовательским приложениям и, если необходимо, в панель управления по одному доменному имени
Возможность использовать один SSL-сертификат (полученный на доменное имя) для работы пользовательских приложений, а также доступа в панель управления
Пользователь получает постоянный адрес (URL) пользовательского приложения, который не будет изменяться (например, при перемещении пользователя между узлами кластера)

Включение модуля

Включение Nginx-проксирования доступно только пользователям с правами администратора и выше.

Чтобы включить Nginx-прокси:

Перейдите в раздел Домены → WWW-домены.
Выберите домен и нажмите Изменить параметры сайта.
Включите опцию Защищенное соединение (SSL), а затем — опцию Nginx-прокси.
Укажите в поле IP-адреса nginx-прокси IP-адрес, с которого будет осуществляться проксирование, и нажмите Ok.

Если web-домен Nginx-прокси создан на локальном узле кластера, то применяется IP-адрес, который выбран в поле IP-адреса nginx-прокси. Адреса в поле IP-адрес будут игнорироваться.

Nginx-прокси использует сертификат, подключенный к веб-домену, и обновляет информацию о нем при необходимости. Для проксирования могут быть использованы Let's Encrypt сертификаты.

Выключение модуля

Отключение Nginx-проксирования доступно только пользователям с правами администратора и выше. Для отключения Nginx-прокси необходимо открыть форму редактирования веб-домена и отключить опцию Nginx-прокси.

Основные принципы работы

Проксирование осуществляется через мастер-панель. В списке выбора IP-адресов Nginx-proxy отображаются только общие и не созданные средствами панели IP-адреса.

Для успешного проксирования запросов A-записи домена и псевдонимов на ответственном (authoritative) за зону DNS-сервере должны вести на IP-адрес Nginx-прокси, который был выбран при подключении www-домена к Nginx-прокси. Каждые 30 минут панель проверяет IP-адрес A-записей Nginx-proxy. Если А-записи не ведут на необходимый IP-адрес, панель покажет уведомление о проблеме.

Веб-сервер Nginx позволяет прозрачно проксировать клиентские запросы. С помощью этого механизма решаются описанные выше задачи. Логически схема проксирования выглядит следующим образом:

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

На мастер-сервере настраивается веб-сервер Nginx:

Создается виртуальный сервер (server) для нужного доменного имени на определенном администратором IP-адресе на порту 80 для перенаправления запросов на порт защищенного соединения.
Создается виртуальный сервер (server) для нужного доменного имени на определенном администратором IP-адресе на порту защищенного соединения (443), предоставляющий функциональность проксирования.
Создаются именованные виртуальные директории (location) для каждого узла кластера (location @node1). Они отвечают за проксирование запроса на узел кластера.
Создаются виртуальные директории (location) для каждого пользователя (location /username).
В location пользователя создаются виртуальные директории (location) для каждого пользовательского приложения (location /username/appname). Они определяют, в какой именованный location узла кластера передать запрос для обработки.
Если необходимо проксировать запросы к панели управления, настраивается корневая виртуальная директория location / и проксирующая запросы к панели виртуальная директория location @ispmgr.

Технические подробности

Для каждого узла кластера при его создании или изменении основного IP-адреса регистрируется рассинхронизация основного IP-адреса, при синхронизации настраивающая на узле кластера его основной IP-адрес. При этом на узле кластера, если он имеет установленный Nginx:

В основном конфигурационном файле веб-сервера Nginx создается виртуальный сервер, по умолчанию обрабатывающий запросы на основном IP-адресе узла кластера (прослушивает порты 80 и 443).
Снимается признак приоритета для всех WWW-доменов, которые были приоритетными на новом основном IP-адресе узла кластера. В дальнейшем WWW-домены, созданные на основном IP-адресе узла кластера, нельзя использовать как приоритетные.

Настройки виртуального сервера Nginx-прокси находятся в файле masterproxy.conf директории включаемых конфигурационных файлов Nginx (conf.d);
Виртуальные директории для пользовательских приложений конфигурируются только при определении расположения соответствующей роли пользователя, не ранее.

Пример конфигурационного файла виртуального сервера

 server {
         server_name test.net www.test.net;
         ssl on;
         listen 192.168.40.51:443 ssl;
         add_header Strict-Transport-Security "max-age=31536000;";
         client_max_body_size 0;
         ssl_certificate "/usr/local/mgr5/etc/nginx_certs/masterproxy.crtca";
         ssl_certificate_key "/usr/local/mgr5/etc/nginx_certs/masterproxy.key";
         ssl_ciphers HIGH:!RC4:!aNULL:!eNULL:!MD5:!EXPORT:!EXP:!LOW:!SEED:!CAMELLIA:!IDEA:!PSK:!SRP:!SSLv2;
         ssl_prefer_server_ciphers on;
         ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
         location @node1 {
                 proxy_redirect /$2/ /$1/$2/;
                 proxy_redirect [https://192.168.40.51/$2/|https://192.168.40.51/$2/]  /$1/$2/;
                 proxy_cookie_path /$2/ /$1/$2/;
                 proxy_pass [https://192.168.40.51|https://192.168.40.51] ;
                 proxy_request_buffering off;
                 rewrite ^\/(.*?)\/([^\/?]*)(.*)$ /$2$3 break;
         }
         location @node2 {
                 proxy_redirect /$2/ /$1/$2/;
                 proxy_redirect [https://192.168.40.52/$2/|https://192.168.40.52/$2/]  /$1/$2/;
                 proxy_cookie_path /$2/ /$1/$2/;
                 proxy_pass [https://192.168.40.52|https://192.168.40.52] ;
                 proxy_request_buffering off;
                 rewrite ^\/(.*?)\/([^\/?]*)(.*)$ /$2$3 break;
         }
         location /user1 {
                 location /user1/phpmyadmin {
                         try_files /does_not_exists @node1;
                 }
                 location /user1/roundcube {
                         try_files /does_not_exists @node2;
                 }
         }
         location @ispmgr {
                 proxy_set_header Host $host:$server_port;
                 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                 proxy_set_header X-Forwarded-Proto $scheme;
                 proxy_set_header X-Real-IP $remote_addr;
                 proxy_set_header X-Forwarded-Secret kBBoQd5H6CAcwb5G;
                 proxy_pass [https://192.168.40.51:1500|https://192.168.40.51:1500] ;
                 proxy_request_buffering off;
                 proxy_redirect [https://192.168.40.51:1500|https://192.168.40.51:1500]  /;
         }
         location / {
                 try_files /does_not_exists @ispmgr;
         }
 }

server {
         server_name test.net www.test.net;
         return 301 [https://$host:443$request_uri|https://$host:443$request_uri] ;
         listen 192.168.40.51:80;
 }

В приведенном примере видно, что так как пользовательские роли сервера баз данных MySQL и почтового сервера расположены на разных узлах кластера, запросы к соответствующим приложениям (phpMyAdmin и Roundcube) передаются на обработку разным именованным виртуальным директориям проксирования.

Документация ispmanager 6 business