Nginx-прокси
Данная статья посвящена описанию механизмов работы модуля проксирования запросов пользовательских приложений (сокращенно Nginx-прокси). Под пользовательскими приложениями понимаются например phpMyAdmin, phpPGAdmin, Roundcube и т.д.
Работа панели без использования Nginx-прокси
Без использования Nginx-прокси панель управления перенаправляет запросы к пользовательским приложениям на узел кластера, обслуживающий необходимую роль (например, "Почтовый сервер" для Roundcube). При этом дальнейшая работа пользователя с приложением будет производиться уже по адресу узла кластера (по умолчанию используется основной IP-адрес узла кластера, например https://12.34.56.78/roundcude ).
Задачи использования Nginx-прокси
При предоставлении услуг shared-хостинга может понадобиться настроить доступ к пользовательским приложениям через единую точку входа. В качестве адреса точки входа будет использоваться указанное в настройках доменное имя. Это позволяет решить несколько проблем:
- Доступ ко всем пользовательским приложениям и, если необходимо, в панель управления по одному доменному имени
- Возможность использовать один SSL-сертификат (полученный на доменное имя) для работы пользовательских приложений, а также доступа в панель управления
- Пользователь получает постоянный адрес (URL) пользовательского приложения, который не будет изменяться (например, при перемещении пользователя между узлами кластера)
Основные принципы работы
Веб-сервер 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 до версии 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-прокси», с которого будет осуществляться проксирование.
Nginx-прокси использует сертификат подключенный к веб-домену и обновляет информацию о нем при необходимости. Для проксирования могут быть использованы Let's Encrypt сертификаты.
Отключение
Отключение nginx-проксирования доступно только пользователям с правами администратора и выше. Для отключения nginx-прокси необходимо открыть форму редактирования веб-домена и отключить опцию «Nginx-прокси».