Ispmanager 6 business documentation

Nginx-proxy

 

This article describes how to proxy requests of user applications, such as phpMyAdmin, phpPGAdmin, Roundcube, etc.

About the module

  • The module is configured in DomainsWWW-domains, on the Change website parameters form;
  • An Nginx-proxy can be enabled for the existing web-domain with an SSL-certificate or when creating a new one;
  • Any number of web-domains can be connected to the module;
  • The directory with module settings has been changed. The settings are located in the /etc/nginx/conf.d/masterproxy.d/domain_name.conf file.

Please note: when you set up the proxy domain, all traffic will be counted for the owner of that domain.

We recommend that you create a proxyuser user in the control panel, and then add a domain for this user, which will be used as a proxy.

The proxyuser user will be created in the control panel. For this user the system will create a new domain which corresponds to Nginx-proxy before the control panel was updated.

How it all works without Nginx-proxy

If an Nginx-proxy is not configured, the control panel redirects requests to user applications to the cluster node with the appropriate role (e.g. "Mail server" for Roundcube). A user can access an application by the cluster node's URL (by default, by the primary IP address of the cluster node, for example https://192.0.2.1/roundcude).

When you set up Nginx-proxy

If you provide shared-hosting services, you may need to configure a single point of access to user applications. Its IP address is the domain name specified in the configuration form. This will allow you to:

  • Access all applications and the control panel (if needed) by a single domain name.
  • Use one SSL-certificate (for the selected domain name) for user applications and the control panel.
  • A user will have a permanent URL for his application that won't change (for example, when the user is moving between cluster nodes).

Enable Nginx-proxy

Only admins and users with higher privileges can enable an Nginx-proxy.

To enable an Nginx-proxy: 

  1. Navigate to DomainsWWW-domains.
  2. Select a domain and click the   Change website parameters button. 
  3. Check the Secure connection (SSL) box, and then — the Nginx-proxy box.
  4. Enter an IP-address in the Nginx-proxy IP address field and click Ok.
Note
If an nginx-proxy is created on a local node of the cluster, the system will assign the IP address selected in the Nginx-proxy IP address field. The IP addresses from the IP address field will be ignored.

Nginx-proxy uses the SSL-certificate connected for the web-domain and updates information about it when needed. You can use Let's Encrypt certificates as well.

Disable Nginx-proxy

To disable an Nginx-proxy, go to DomainsWWW-domains, open the Change website parameters form and uncheck the Nginx-proxy box.

Proxy workflow

Note
Proxy runs via the master panel. In the list of Nginx-proxy IP-addresses you can see only shared and IP-addresses that were created outside the control panel.
To successful proxy requests, A-records and aliases on the authoritative DNS-server, should point to the Nginx-proxy IP-address which was selected when enabling an Nginx-proxy for a WWW-domain. Every 30 minutes the control panel checks the IP-address of the Nginx-proxy A-records. If the A-records do not point to the IP-address, the panel will show error notifications.

The Nginx-proxy works as follows:

  1. A client request is passed to a web-server.
  2. The system defines a user and application to serve.
  3. The request is passed to the web-server of the corresponding cluster node.
  4. The server’s response is delivered to the client.

Nginx is set up on the master-server as follows:

  1. A virtual server is created for a selected domain name on an IP-address selected by the admin on port 80 to redirect requests to the secure connection port.
  2. A virtual server is created for a selected domain name on an IP-address selected by the admin on secure port 443, which allows for proxy functions.
  3. Virtual directories (locations) are created for each cluster node (location @node1). They are responsible for proxying requests to the cluster node.
  4. Virtual directories (locations) are created for each user (location /username)
  5. In the user location virtual directories (locations) are created for every user application (location /username/appname). They will define the location of the cluster node that the request should be passed to.
  6. If you want to proxy requests to the control panel, the system will configure the location / root virtual directory and the location @ispmgr virtual directory that will proxy requests.

Technical details

  • When creating a cluster node or editing the primary IP address, de-synchronization of the primary IP address is registered. It will set up the primary IP address on the cluster node during synchronization. If Nginx is set up on the cluster nodes:
  1. A virtual server is created in the Nginx configuration file. By default, this server handles requests on the primary IP address of the cluster node (it listens to ports 80 and 443).
  2. The Priority checkbox will be cleared for all WWW-domains that had this option set on the new primary IP address of the cluster node. Then WWW domains created on the primary IP address of the cluster node cannot be used as priority WWW domains.
  • Configuration details of the Nginx-proxy virtual server are located in the masterproxy.conf file of the directories in the Nginx (conf.d) configuration files.
  • Virtual directories for user applications are configured only when defining the location of the corresponding user role.

Example of a virtual server configuration file

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;
 }

In the above example, you can see that because the MysQL database server and mail server user roles are located on different cluster nodes, requests to the corresponding applications (phpMyAdmin and Roundcube) are passed to different virtual proxy directories.