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

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

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

Задачи использования Nginx-прокси

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

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

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

Обратите внимание!

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


Обратите внимание!

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


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

Обратите внимание!

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

На мастер-сервере настраивается веб-сервер Nginx следующим образом:

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

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

  • Для каждого узла кластера при его создании или изменении основного IP-адреса регистрируется рассинхронизация основного IP-адреса, при синхронизации настраивающая на узле кластера его основной IP-адрес. При этом на узле кластера, если он имеет установленный Nginx:
  1. В основном конфигурационном файле веб-сервера Nginx создается виртуальный сервер, по умолчанию обрабатывающий запросы на основном IP-адресе узла кластера (прослушивает порты 80 и 443)
  2. Снимается признак приоритета для всех 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 до версии 5.138.0

Обновление ISPmanager до версии 5.138.0 вносит изменения в работу модуля nginx-прокси:

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

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

При обновлении ISPmanager с настроенным модулем nginx-прокси до версии 5.138.0 или выше, в панели управления создается специальный пользователь proxyuser. Для этого пользователя создается домен, который соответствует настройкам nginx-proxy до обновления панели управления.

Настройка

Включение nginx-проксирования доступно только пользователям с правами администратора и выше. Для этого необходимо открыть форму редактирования веб-домена и включить опцию «Защищенное соединение (SSL)», а затем опцию «Nginx-прокси» и указать «IP-адрес nginx-прокси», с которого будет осуществляться проксирование.

Обратите внимание!

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



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


Отключение

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